Managing multiple development projects in Scrum

Question

My organization is currently using Scrum to manage a large development project. Once this is complete we will start to work on several smaller projects (ranging from approx 2 weeks to 2 months work) either simultaneously or by taking each one in turn.

My question is, what is the best way to manage multiple smaller projects in a Scrum environment? Should we work on a single project at a time or could we effectively work on stories from more than one project in a single sprint? The other option I can see is a hybrid of this, where we work on Project A in one sprint and Project B in the next.

Personally, I would like to concentrate on a single project at a time but I am aware that internal business pressures may make this a difficult sell. Any suggestions would be much appreciated.

Answer 1

The Framework Answer

From a framework perspective, each Scrum Team works from a single Product Backlog, and each sprint should have a single unifying Sprint Goal. If you have multiple projects, it seems unlikely that you can meet either of these requirements.

Scrum Teams are Project Teams

While a Scrum Team may work on multiple projects over time, and in some cases a Scrum Master or Product Owner will have more than one project, the team as a whole should be dedicated to a single project. This reduces overhead and lost productivity due to task-switching and loss of momentum.

That isn't to say that a Scrum Team never leverages matrixed resources. However, if you find yourself in a situation where 100% of your "team" is matrixed, or if you have individuals or sub-groups working on different projects concurrently, then you don't really have a team.

Alternatives

• If you're going to be working on tasks that can't be classified as a singular project, but you have a conceptually unified process for your tasks, then you may find Kanban a better fit than Scrum.
• If concurrency is important, you might consider re-partitioning into multiple teams for Scrum or Kanban, keeping each team focused on a specific project or process flow.
• If you are limited to a single team for multiple projects, the business should re-evaluate whether projects can be prioritized to limit overlap and avoid overbooking of resources.

Answer 2

You are right, that setup is something hard to sell, and when you do A,B,C,A,B,C there is a chance that you won't finish anything. What happens if a user story of project B is not finished in its sprint? You have to shift it to the next. In this case you'll have to wait several weeks to continue, which has the risk of forgetting what has happened.

My proposal is to find the minimum set of user stories and sprints in each project (in theory let's say it is 25% of a project), and do the minimum from A, than from B etc. With this approach you'll minimize the risk of not finishing a project, and you'll still have enough room to do something valuable in each project:

A(25%, 2 sprints), B(25%, 3 sprints), C (25%, 1 sprint), A(50%, 1 sprint) etc.