It's not uncommon for an organization to have one group of developers who need to complete multiple projects. In those situations, how should the group be structured, and how should their work be planned and allocated?
When the ratio of developers to projects is relatively high (say, 6-10 developers per project), and the size of the projects and their relative priorities is known, this is commonly addressed by splitting the developers into two or more teams.
On the other hand, if the ratio of developers per project is quite low (1-3 developers per project), and the size of the projects and their relative priorities is less clear or subject to change, it can be difficult to split the developers into teams in a meaningful way.
Gilad Gruber asked for some advice on how to structure a project and team:
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.
Wolfgang Shulze Zachau shared his experience:
We have one team and one product backlog covering a variety of projects. There is one product owner and he is the ultimate decider on priorities, after careful consultation with the customers and other stakeholders. Works well, as long as the [Product Owner (PO)] is left to make his own decisions.
He added, "Of course, you need the right kind of guy to be PO."
Xu Yi-Kaveri disagreed:
I [am] against the idea of having a single product backlog per team. First, product owner is the person who can decide the format of product backlog. And basically I think you do not have a single product owner for different projects.
He raised the concern of how you can prioritize amongst multiple projects, and confusing feature priority and project priority. Instead, he suggested:
You should have your team's capacity estimated, then perhaps you need to negotiate with project managers about capacity division among projects. Then use your project specific capacity to select product backlog items for different projects.
Roy Morien suggested choosing between the approaches using common sense:
But in all of this, common sense must prevail, surely. If it is convenient and efficient to have many teams, each with its own PB, then fine, go for it. Each PB will have to be separately prioritised. If a common backlog that is shared by many teams, then that implies that many teams, of appropriate numbers each (7-9 maximum) share the same PB, and then it just becomes a problem of handling the prioritising of the PB, AND of the orderly selecting of items to go onto the various Sprint Backlogs.
Finally, George Dinwiddie stepped in to share (via mailing list and blog) some of the problems he has experienced with using multiple product backlogs:
As estimates are only estimates, the developers are put in a position of deciding whether to continue working on an unfinished story or switch to something different because they've used up the capacity allotment. Or perhaps they're pressured into working overtime because the POs will blame the developers for anything that goes wrong. A lot of things can happen, but few or none of them are Agile.
I can tell you that that it's not pretty, and it's not good for the business.
Community comments
Developers choosing which projects get their features?
by Deborah (Hartmann) Preuss,
Re: Developers choosing which projects get their features?
by Geoffrey Wiseman,
Re: Developers choosing which projects get their features?
by Kelly Waters,
Re: Developers choosing which projects get their features?
by Geoffrey Wiseman,
Implicit backlog and waste...
by Amr Elssamadisy,
Developers choosing which projects get their features?
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
George's comments resonate for me, I hadn't noticed that before:
> the developers are put in a position of deciding whether
> to continue working on an unfinished story or switch to
> something different because they've used up the capacity
> allotment.
So, even if there is a single PO he or she would need to negotiate in some low-value stories to ensure that their owners wouldn't be disappointed if those stories get cut when the unexpected occurs and it's realised that a story will need to be dropped from an iteration.
If this isn't done, the team effectively ends up deciding resource allocation across different projects. I can see how this would tend to encourage overtime, to avoid getting embroiled in inter-departmental politics. So much for sustainable pace. (And we all know that tired teams make more mistakes).
Re: Developers choosing which projects get their features?
by Geoffrey Wiseman,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes, I've seen that at play. In fact, I've been in that position. I was once assigned on an ongoing basis to a client project in 'operations' mode for 0.5 days a week, but not any specific day, and given very little sense of comparative priority. That meant that at any given moment, I was largely in charge of what happened, and why.
It had uncomfortable moments. For the most part, it worked out. Like any project, if the participants are all reasonable people trying to do the right thing, it will often work, in spite of whatever screwy arrangement has been set up to manage it.
Re: Developers choosing which projects get their features?
by Kelly Waters,
Your message is awaiting moderation. Thank you for participating in the discussion.
Click below to see what I say about how to share an agile development team...
kw-agiledevelopment.blogspot.com/2007/07/how-to...
Kelly Waters
www.allaboutagile.com
Re: Developers choosing which projects get their features?
by Geoffrey Wiseman,
Your message is awaiting moderation. Thank you for participating in the discussion.
One of the things I value about scrum is that the sprint is a goal, and the tasks lead to the goal, so you might drop stories, as long as you believe you can achieve the goal.
That's harder to manage with a split-project-budget as you describe -- making scoping decisions could involve negotiation and careful planning. That's liveable, but it does take away a little from having a self-directed team.
(That is presumably partially true even with one backlog and one product owner -- but in that model, I can imagine the product-owner doing a more cohesive job of the planning and prioritizing.)
Implicit backlog and waste...
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
I know it sounds difficult/problematic to have one PO across multiple projects, but prioritization has to be done by someone.
If there is no single PO (and a single backlog), the development team *acts* as if there is implicitly. The fact that they do things in a particular order imply a priority which probably won't match the customers' priorities.