In our attempt to adopt Scrum in our organization, we found out that it was very challenging for us to maintain a unique Product Backlog. Not only are we working on a couple of projects simultaneously, but we are also responsible for maintaining the application. Imagine the headache for our Product Owner to prioritize a single Product Backlog containing all stories for all of our projects, bugs and smaller feature requests!

It’s only after several Sprints (and a flash of common sense) that we managed to solve this by having a Product Backlog for each running project. A picture is a worth a thousand words – so here is how things look like:

As you see, each project (A, B and C) has its own backlog. What does this mean concretely?

1. Each project has its own burndown and velocity.
2. The Product Owner can decide in the Sprint Planning on which project the accent should be put in the next Sprint, depending on changing priorities (Project A, Project B, urgent bug fixes on production sites etc.).
3. We go through each of the projects in order of priority during the Sprint Review.

There are definitely risks related to working on several projects during a Sprint: no common goal for the team, spreading resources puts projects in danger, breaking team cohesion etc. Being aware of these risks is important so you can act accordingly. I must say that so far, it has worked really well for us.