Combined backlog for multiple projects

Our teams sometimes have multiple projects. I am wondering what is the best way and what is the SCRUM way of handling this. My feeling is that the best way is to have a single backlog per team (even if this means that in a sprint the team is working on backlog items belonging to multiple projects). I think the purists will recommend splitting the team and having multiple backlogs.

That’s what Gilad Gruber asked on the Scrumdevelopment list. This question reminded me of a client I once had.This client did split the team and used multiple backlogs. It was very convenient for the Product Owners. The could each concentrate on their own piece of the pie and ignore the needs of the business as a whole. Had it worked well, I might never have worked with them. What went wrong?

First, it took a lot of pre-planning by the development manager to allocate developers to the various areas of the business. It’s not easy to guess, a year in advance, how much development capacity each would need. And since the development capacity was split by assigning developers to the business line, the allocation was more-or-less static for the year (unless you wanted to re-do this guessing more than once). But each Product Owner got his or her own piece of the pie–something they could count on having and not worry about sharing. Except when it didn’t work out that way.

Given the number of developers and number of product owners, it was not practical to split the teams into integer numbers. As it was, the developers assigned to any product owner was a small team, from two to five to a team. Some of the developers had skills in short supply, so they might be assigned on a percentage basis to two or three Product Owners. While this made the teams bigger (though still a little small), it also split the attention of the developers. Estimates being estimates, and the work to satisfy a Product Owner being lumpy from time to time, the hours and percentages of developers didn’t always work out easily. It was left up to the developers to make things work. Usually they’d negotiate with the Product Owner whose work was being delayed for another, but not always. In any event, it was the developers who were making the decisions about which work had priority.

I’ve described a situation here where development management is making the large-scale priority decisions balancing between business groups, and developers are making the short-term priority decisions of what gets done first. Wouldn’t it be so much better if the business people could get together and decide business priority instead?

Gilad, I highly commend your suggestion of a single “product” backlog per team, even though it may contain stories from multiple projects. It may even be that stories for multiple projects are picked for a single sprint, just because that’s how the sprint boundaries and priorities fall out. Yes, it’s true that it’s better (more efficient) if the team concentrates on one thing at a time, but that’s a small price and the team will probably work it out OK. It’s much more important to have clear priorities based on business value. And if the business can’t decide what’s most important, they should solve that problem rather than abdicate to development.

9 Replies to “Combined backlog for multiple projects”

  1. I’ve run into this as well. Rather than allocate developers, we pro-rated the number of points each customer could put into the backlog by their contributions to the budget.

    It definitely makes prioritizing harder, and it can lead to silliness like Customer A gold plating the system with resources that Customer B could better use to add real business value.

    Certainly less than ideal, I agree.

  2. What if there are multiple PO for the several projects, but still one team should handle it?
    Would you also go for a unified backlog, and if not what are the alternatives?

  3. Miron, yes, with multiple POs and one team I would still go for a unified backlog. In fact, that’s the situation I’ve commonly seen.

    The POs should come to an agreement amongst themselves about the ordering of the Product Backlog. If they can’t that indicates and organizational problem that won’t be solved by pushing the decisions down to the development level.

    During the sprint planning, it may be advantageous to reorder some of the backlog items to make the work in the sprint less fragmented. This can be discussed by the developers and product owners. If everyone feels they are on One Team with common goals, these things can be worked out easily. If there is distrust and manipulation, it will be visible and cause problems.

  4. In the year since this posting, have you come to any different conclusions and if so what?

    I am facing this situation now. Many PO’s each with several projects, a team of 8 developers plus 2 floaters with constrained skill sets from another group.

  5. Kirk, it sounds like your organization is trying to do too much simultaneously. How is it working for you?

    I suspect that there’s a lot of thrashing, and loss of both focus and energy. Wouldn’t it be better to do one thing until it’s done-done before switching to another?

    Johanna Rothman has written on multi-tasking a lot. You might find her article, Refocusing: Emerging from the Split Focus Schedule Game, of interest. Also, I recommend Tom DeMarco’s book, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

  6. Great description of the multi-project, one team problem. I’m working with a team that has this problem. They’ve been performing without a Product Backlog for some time and producing well for the circumstances. We’re taking on the task of building the Product Backlog now.

    The problem with having one Product Backlog with all the projects thrown together is communication outside the team. The rest of the company sees the projects as separate. This is something that also needs enhanced transparency, which we will create.

    Our current first pass plan is to create a combined Sprint Backlog for one-week sprints. I don’t like this because it perpetuates the false view of separate projects into the rest of the company. However, one must pick how much to change at one time. In this culture, getting Product Backlogs in place is the first necessary step. Pushing transparency up the chain will then be better supported.

  7. We are facing a similar issue. We have multiple projects and multiple teams. Right now projects belong to different POs/product backlog having their own team/sprint backlog.
    We are planning on combining the Product Backlog to a company backlog, where the three teams pick their stories for the sprint.
    My problem is how does a Sprint Plannings I should look like. Do the teams meet in one room working out what they take into their backlog? I imagine such a meeting to be very crowded and therefore no good.
    The option would be to have the POs present the company baclog to their team in different meetings, but then how would they pick the stories without knowing what the other teams picked.

    I hope I described my problem well enough and there is someone outthere who can help 🙂

    1. Wolfgang, it’s always a difficult issue and is very context dependent. If you throw all of your projects into one backlog, and have all of your teams working from that backlog, then you’ve effectively made everyone part of one team. You’re right, it will be very crowded–and the problem isn’t just with the planning meeting.

      Often the best solution is to change the context. From your description, it sounds like you may be trying to work on too many projects at once. This multitasking leads to thrashing and wasted effort. Working on all products at once may give the illusion of progress on all of them, but really just delays the delivery of the first one. The last bit of work gets done at the same time, or later, whether you delay starting it or multitask.

      It’s better to get a shippable increment of one product finished than to be working on several in parallel. You can switch between products after shipping that increment. I recommend Johanna Rothman’s book, Manage Your Project Portfolio, for more strategies on dealing with this problem.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.