Planning the features to be developed is an important part of software development, particularly software product development, and most methods/processes have some way of managing and planning those features such that the business and developers can get an understanding of "what's next". In Scrum, the list of features desired but not yet implemented is typically called the backlog (or product backlog). This is meant to be lightweight, but can it still be wasteful?
In a stereotypical waterfall development process, this can rapidly move from being a list of desired features into a long set of fleshed-out use cases, high-level and low-level specifications, and so on: an endless stream of documents whose weight is only surpassed by its outdatedness.
Keen to emphasize delivering working software over comprehensive documentation, most agile processes try and reduce the amount of effort put into documenting features up-front, particularly when the nature and priority of those features has a tendency to shift. However, even if a product backlog is lighter-weight than a functional specification, can it still be wasteful? When waste-averse lean software developers cross-pollenate with scrum afficionados, this question is bound to arise: Is a Backlog Wasteful?
Simply put by Alan Shalloway, backlog could be seen as inventory:
Work put into the product backlog is inventory. It is wasteful. But it may be necessary work to mitigate/manage risk. This is not inconsistent with agile methods. We analyze those stories that are about to get built. The rest of the backlog should be analyzed as little as possible so there is as little waste as possible.
Mary Poppendieck suggests some mitigation strategies:
I recommend that a LIMITED backlog equivalent to a couple or three cycles of work is adequate for making sure there is always something to do and it is the current highest priority work. One way to discover the appropriate length of this queue is to relentlessly remove the work that has an age older than the average age of work that is getting through the queue. Those items have fallen to the bottom of the queue and will very likely never get done. Another way to discover how short a queue can be is to keep on shortening it relentlessly until it is clear that it can't be any shorter.
The way to determine here if your backlog has gotten too long or too detailed too soon is to determine what % of so-called "requirements" are changed from the time they are specified until the system is implemented. This is often called requirements "churn". If this churn is greater than -— say — 10%, then the detailed specifications are being done too soon.
David Starr itemizes a few other ways to reduce backlog waste:
- Set a sight horizon to trim the backlog and remove items beyond that horizon.
- Use a FDD based backlog where features are defined at a higer level than button clicks. Use cases work well for this.
- Enforce a estimation process for the teams that does NOT ALLOW large amounts of time spent sizing backlog items.
- Use the higher numbers in Poker Planning ( 20, 40, 100, 300, whatever). This is usually the area of the backlog where teams waste time. BL owners want high level sizing and engineers like to break it down into smaller and smaller bits. Move on.
Paul Oldfield adds to that list:
break down the 'higher number' features into smaller ones just before they go into an iteration / sprint, so you can estimate better and so you only do the higher value aspects of the feature at this time
Alan further suggests there may be another danger to a lengthy backlog — a mindset shift that implies everything in the backlog should be completed:
What has happened now is that we've slipped into project thinking instead of product thinking. We are not looking to see if we actually need to continue on with the backlog. This is a subtle danger as it tends to make projects longer than they need to be. It impedes management of the products being developed/enhanced from looking to see if there is a better thing for the team to be working on.
Have you seen other forms of waste in managing a product backlog? How do you balance the need to plan with the waste of investing too much effort into an ever-changing backlog? Read more about this and other agile topics here at InfoQ.