当你有多个项目时 Scrum 是如何工作的？

Scrum really doesn't dictate that you have to be working on the one self-contained product. It simply states that there is a bunch of stuff that needs to be done (the product backlog), there is a certain amount of development time available in the next iteration (worked out from the project velocity) and there are items selected by the client/business as having most priority from this pool of issues/tasks that will be done in the next iteration (the sprint backlog).

There is no reason that the product backlog and sprint backlog have to be from the one project - even in a single project there will be discrete units of work that are like separate projects - the UI, the business layer, the database schema, etc. Enterprise software development in particular is like this, where you have a number of code bases that all have to be progressing. The Scrum process - meetings, questions, burn down chart, etc - all work whether it is one project or multiple.

Having said that, in practice it is often good for each iteration to have a major theme - "do the reporting module" or "interface with XYZ system's API" - so that a lot of the issues come from one project or area and at the end of the iteration you can point to a large body of work and place a tick against it.

I think the answer depends on "who will be prioritizing the backlog items" (i.e. decide what needs to be done first). If this is a single person, then this person is the Product Owner for your projects, and you can have a single backlog will all items for all projects - or a backlog per project - and you select the backlog items from all projects when you plan a Sprint. In this case, Scrum "works" fine.

If every project has its responsible, then you're likely to encounter some troubles where each responsible will - more or less consciously - try to favor its project(s). IMHO, you'll need to have one Product Owner only with the authority to settle the priorities by arbitration.

One rule that shall be followed in such a context is to never change the Sprint content during the Sprint. If necessary, you can shorten the iteration to two or three weeks to lower the risk of having to add an urgent item in the current Sprint.

I would suggest running one Sprint for each Project and have 1 daily standup meeting to handle all active Springs/projects.

I have been in this precise situation.

If you have one product owner across the projects then Phillipe is absolutely correct; One sprint with one team should work just fine.

If you have more than one product owner, then ideally the business side needs to choose a single 'prioritizer' who is given the responsibility for scheduling the work. This is definitely the best solution.

If (as is probably the case) the business don't want to change how they want to prioritise things (that would be far too convenient) then you can split the team., and run two concurrent sprints. However with a team of six, I wouldn't split it into a more than 3 teams (I wouldn't want to split it at all, but I think 2-3 teams would be workable). Splitting any further as Kenny suggests, and having teams of a single person seems to me somewhat pointless, as then you no longer have a team, just individual programmers.

If you are splitting the team, I haven't found much value in amalgamating the stand-ups, unless you have separate sprints working on very much of the same codebase, but then that may be an argument to amalgamate those teams for the purpose of the sprint.

As @Chris said, a normal project has sub projects inside. You only have one backlog though.

Think in a backlog with all your projects. First problem: are you assigning priorities to tasks or projects? I do prefer a backlog per project. At least to have clear the priorities that the product owner has.

Having different product owners, and due to the fact that those product owners are not going to agree on how much time they should give to each project. "Someone" will have to absorve the decision on how to manage interproject priorities. Note: developers shouldn't do it.

Here it comes our project"S" manager that will balance the resources product owners need and the time members of the team can give. Product owner A paid for one month of work, but product owner B is always updating his project (and paying you well too). There some how you'll balance your team for A to have his one month (developer time), and do not stop B from filling your pockets.

In the case of internal software (one company, a thousand projects). The different product owners should agree on the time given to them. They do not live isolated, but in the same boat as you (project"S" manager). They will make your life easier being able to postpone some tasks, but at the same time you should never forget their needs.

Well, I'm still trying to figure out the best way to do this. But this is what we're pushing right now. I hope it helps.

I have to disagree. I think it is key to the process to have a team focused on a single project during a sprint. If you have some specialists that can't contribute to the entire development process (content authors, graphics people, business process analysts, etc.) I would shuffle them off the team when they can no longer contribute. Or better yet, get them trained up on some different tasks so they can contribute to things like testing.

Another thing to keep in mind is that running projects in parallel kills your schedule. Consider this: for simplicities sake, lets say we have 5 projects using the same team and starting on the same date. Each project needs 3 one months of effort, In the best case scenario running parallel, you will finish them all at once and it will take 15 months. Your velocity will get creamed because you can only fit 1/5 of a month of effort in a single sprint. You'll also be doing 5 demo meetings all at the same time. So best case scenario, you deliver your 5 projects in 15 months and your competition will be claiming they could do the same work in 3. Your teams estimating maturity will suffer because they will only be able to consider 20% of their available labor. You may find that you actually are unable to perform some tasks in a single sprint. If you have to change the number of projects being worked from 5, your team will have to adjust their estimating habits which will damage the teams efficiency. Additionally, your team will find it difficult to self-organize when a simple task reassignment may require spinning up a new dev environment before work can begin.

If you were to run the same 5 projects serially, you'd deliver the 5th project in the same 15 months, but you would have educated your client that your team is in such demand that you have a 12 month backlog and that you can use that time to refine your project goals. Or if you have a constant backlog, you know it's time to start hiring another team. Your best project, however, is finished in 3 months with a client that has seen rapid improvements during the active period. You're able to finish that project a year earlier and can put it on your resume. Your sprint velocity will stabilize over that period of time and you may find that hits its stride after a project or two and are able to accomplish more in a given sprint.

I think running projects serially is one of the biggest hurdles an organization attempting to adopt scrum faces. It's a major cultural change associated with deconstructing the project manager role, but the benefits to the scrum process are huge.

Keep in mind that EVERYBODY does not need to be a full team member. They can be engaging your client in the waiting room, preparing for the development process. I keep my business analysts, network architects and graphics design people as domain experts and only attach them to a team as needed. Let them run with sprint 0. You'd be surprised how engaging working on look-and-feel and workflow is. It's also good to prepare your client with the understanding that when development begins in earnest, their level of participation may actually go up and that it is important for them to be available. Let them know the schedule so they have plenty of time to deal with things like vacations and holidays well in advance.

Team members can split their time between scrum projects, but it’s much more productive to have team members fully dedicated. Team members can also change from one sprint to the next, but that also reduces the productivity of the team. Projects with larger teams are organized as multiple scrums, each focused on a different aspect of the product development, with close coordination of their efforts.

There is another opinion I have been reading about lately, namely that in an Agile environment the concept of Project might be counterproductive and could be eliminated. According to this line of thinking, the organization should be focusing on Releases instead. This is because Projects are artificial boxes of work that produce no value until they are finished. They are contrary to Agile's goal of frequently delivering shippable value. A Release is more in line with Agile because it is oriented towards delivering value and because its scope can be reduced or expanded based on what teams can deliver before the next Release.

There is a potential middle ground, in which what was formerly called a Project in your company is now repackaged as the common Agile Theme or Feature. The benefit of this approach is that the Theme or Feature can now be implemented in pieces of value, as the product owner sees fit.

There is still the question of one team working on multiple Products, and it is a question because of legitimate concerns about domain knowledge and possible technical skills. But Products built with Agile, even multiple Products built by a single team, are constantly accumulating Release-able value. In contrast, Projects are worth nothing until they finish (and many do not).

Something to think about...

I think anopres was right: the best way is to avoid multiple projects at the same time with scrum. Do everything to convience that running too much in parallel is not efficient.

Let us assume 5 projects each about 3 months for team with 5 people.

Approach 1: each person works on single project in team

• 1/5 speed of delivery per project gives 15 months of delivery for all projects
• Every single person is expert but only in own project
• No team spirit

Approach 2: 1 sprint per project, switching projects

• Every 6th sprint work on project
• Too long time between project work - not regular incremental value for project (for product backlog yes), easy to forget, effort needed to restore context,
• First project delivered after about 12-13 months (assuming 2 weeks sprint)

Approach 3: 5 projects in single sprint

• Requires too much detailed split of tasks just to fit into sprint
• Very little incremental build per project
• Delivery of first project after about 12-15 months

Approach 4: recommended - Serialized work

• Team works on single project after project
• First project started and delivered after 3 months
• Second project started after 3rd month,delivered after 6th month
• ...
• 5th project started after 12th month, delivered after 15th month
• Team highly focused on project, intensive research and collaboration with customer
• Whole team has general good knowledge about all projects
• No waste time on context switching
• Require good team cooperation (conflicts can slow down delivery).

As you see, solution 4 is generally better because projects are deliveried much faster, team works together and efficient. Other approaches includes waste time from context switching, no full team collaboration, very long total delivery time of all projects etc.

And what about backlog grooming? If team works on single project at once that is simple - everybody will join. If there are multiple projects we may need to delegate single people to separate grooming sessions (not full team is involved).

It is important to convience customers that starting 2nd project after 3 months will still result in faster delivery (after 6th month) rather than if we start it immediatelly with all others. It is an illusion that managers see - we start 5 projects at once, we work hard and deliver little by little. In the end this is not efficient however.

That is why I do not belive that scrum is efficient for multiple projects in parallel, it is very tricky to match it into framework and work according to scrum rules. Sometimes it may be good having 2 projects to keep all people occupied, but the more projects we add the less efficient scrum will be. Maybe kanban is an alternative just to see the progress and team work (not so strong like in Scrum team)?

Regards, Adam

I'd like to contribute. This is the way I do it:

• There is one product owner and one product backlog per team. The product owner doesn't have to be one single person, but this product owner "entity" is in charge of the product backlog.
• The product backlog has the user stories of every project (all the projects here). Each user story has an effort/story points (team responsibility) and a business value (product owner responsibility).
• We have a "product backlog grooming" meeting every sprint. Before this meeting the product owner has updated the business values of the stories (if they need some change for whatever business reason- that we don't and shouldn't care-) and include some new stories. In this meeting the new stories are explained and the efforts are updated as well. This meeting lasts about one hour (except the first time, about 4 hours).
• When we are going to plan a new sprint we open the product backlog, order the stories by ROI (this is business value / effort) and plan stories until the time has gone.

And that's it. I can say this works pretty fine. We use a couple of google spreadsheet (the product backlog and the sprint backlog ones, both with charts and stuff) for doing this, and redmine (with a specific semantic) for an online organisation every day: time, task progress, etc

The problem with this approach is that I have duplicate the tasks in the sprint backlog spreadsheet and redmine. But I don't find any online tool for doing this completely online. I miss a product backlog in redmine (no other semantic works for me), a single board in jira, more stories in taiga, etcetera