George Dinwiddie’s blog

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.