Comments on: Combined backlog for multiple projects http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/ Effective software development Mon, 13 Oct 2008 08:51:08 +0000 http://wordpress.org/?v=2.0.6 by: George Dinwiddie http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18544 Wed, 05 Dec 2007 13:28:19 +0000 http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18544 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. 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.

]]> by: Miron Ophir http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18537 Wed, 05 Dec 2007 12:46:45 +0000 http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18537 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? 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?

]]> by: Gilad Gruber http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18536 Wed, 05 Dec 2007 12:38:09 +0000 http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18536 Thanks for the insights. We will be trying this and I will update you BR, Gilad Thanks for the insights. We will be trying this and I will update you

BR,

Gilad

]]> by: Stan James http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18396 Tue, 04 Dec 2007 16:17:15 +0000 http://blog.gdinwiddie.com/2007/12/03/combined-backlog-for-multiple-projects/#comment-18396 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. 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.

]]>