How does Scrum work when you have multiple projects?

Question

I'm fairly well read in the benefits and processes of Scrum. I get the ideas on the backlog, burndown charts, iterations, using user stories, and other various concepts of the Scrum "framework".

With that said... I work for a web development firm that manages multiple projects at one time, with six team members that make up the "production team".

How does Scrum work with having multiple projects? Do you still just schedule an iteration for a single project in a certain amount of time and the entire team works on it, and then you move on to the next project with a new iteration when that iteration is completed? Or is there an "agile" way in managing multiple projects with their own iterations with only one team at the same time?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.