I have been following an interesting discussion on the scrumdevelopment group about whether the Product Backlog should be a complete list of every feature that the customer ever wants, or whether it should be cropped to a certain length to prevent wasted effort spent estimating items that will never be high enough priority to get to the top of the list.
It’s especially interesting to me as I’m trying to work with our product owners to construct our first product backlog as we move towards using a more agile approach for a new project, and this was a question that was asked at our organisation.
I’d been of the opinion that the backlog should represent everything our customer would want if they could have it, and that’s currently how I’m approaching it.
Our product owners represent a large number of internal customers. It’s a long term project and the people who are the customers will change over time. The scope of the project is limited, but will expand, as we are building on top of an established system.
Previous experience suggests that many ideas for features are raised by different people time after time, and I believe they should be stored somewhere so that people can see what’s been suggested previously. Reviewing the old ideas helps to refine them, and I want to feel that we are progressing, and not have the same conversations over and over.
I want to be able to show people why the thing they think is important has not made it into the priority list yet, by showing them what is ‘queued’ in front of it. If ideas come up over and over then perhaps we will start to see the ones that need to move higher up in the priorities.
I also believe that all of the items on the wishlist have some value as ideas. Each item represents some level of effort in the thought process or whatever event generated the idea in the first place, and crystallized it to the point where it could be described as a feature.
The discussions on the thread, however, made me question this. On a long term project the value of the “ideas” can decrease over time as the market changes or features become less relevant. Is this “depreciation” really “waste”?
After reading many different opinions, I came to the conclusion that I still want to maintain a product backlog that is a really big wishlist – but ensure our team also recognises some things that could cause us problems.
We will need to take care not to focus too much time and effort on the items further down the list – otherwise they really will start to represent waste – in wasted effort spent estimating or planning things that may not ever happen, or by the time they do will have changed scope.
I was encouraged to hear stories from people who have taken this approach and found it works – that the items at the top are naturally the ones that get the most focus. I hope that by sticking to time-boxed meetings we can also achieve this.
One thing I also intend to do is to ensure that any items that fall out-of-scope, or that we determine really are no longer requirements, are religiously moved off of the product backlog by the product owners.
My one remaining concern is the impact of an ever increasing backlog. Somebody mentioned the “Someday” folder suggested by David Allen in Getting Things Done – the one that tends to grow the fastest with things that never really go anywhere. Yet how many of us are brave enough to just dump it? I’d bet most people are too worried to ever throw away ideas in case they don’t come back when we really need them.
If the backlog continues to increase, it should be an indication that we need more teams – but if it increases too quickly, or if this isn’t an option, what impact on team morale? With everybody having visibility into what we haven’t done, as well as what we have, will this be seen as a negative? This could be a real problem, and it’s one I’ll be watching out for. No doubt there will be many others that I haven’t even considered yet … and I’ll keep the blog updated with progress as we try it out!