Agility and large Backlogs
January 11th, 2009
Backlog is used for prioritizing, tracking and communicating the work (work items) to be done in the future Iterations/Sprints.
There may be multiple teams working from one backlog, but if there are more than 3-5 sprints worth of work items for all teams working on that backlog, then I consider that to be huge. I have noticed that if the product owner is not careful, the backlog can grow and become really huge.
This is not good for several reasons:
- It is depressing for the everyone on the team. This may lead to a belief among team members that this is a case of a large product with not enough resources.
- Priorities change - It is a waste of effort for the product owners to endlessly sort through the work items in the backlog every Sprint to come up with a list of stories for a Sprint.
- Some of the items in the backlog are never worked upon even after months/years. In that case why spend effort prioritizing them?
- It is hard to react to change in the market conditions, when the teams are so focussed on possibly “stale” requirements in a backlog.
So, what are the possible causes for this?
- Lack of clarity of product vision.
- Disagreements between the product management and marketing about the importance of features. So, the “unimportant” ones (mostly due to disagreements) find the bottom of the backlog.
- Product owners unable to decide on the “business value” and ROI on requirements in the backlog. This may be due to the lack of authority (to do so) or communication breakdown or just the organization culture itself.
- Sometimes, for various reasons, a suite of products might have one product owner per product who do not necessarily agree on everything especially when it comes to the cross-product requirements.
- Inadequate resources, unstable team, attritions, shuffled team members, not-so-well-performing teams, etc.
- Treating defects as backlog items. Sometimes, a lot of medium defects are tossed in to the backlog.
- Poor/Complex Technical Architecture - This means that the features get done much slower than estimated.
February 4th, 2009 at 8:56 am
Greatings,
Not enought information
Thanks
Nadine