The Product Backlog is an essential artifact in Scrum. The description of the Product Backlog on Scrumguides.org currently says: ”The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.” Many organizations have taken these words literally, and have hundreds of items in their product backlogs. Time is spent ”backlog grooming”, where items are re-estimated and re-ordered. To me it’s pointless to keep track of such a long list of things to do. You only need a shorter list, with what you should do next. I think it’s time for this to be changed.
Sources of inspiration
I have been thinking about this for some time and the following sources of information have inspired me:
- ”Backlogs Are Not Waste” – Jurgen Appelo made a great blog post that really made me think. In it he separates wish lists (”A wish list is a list of Could-Haves”) from checklists (”A checklist is a list of Must-Haves”). Even if you don’t buy everything from your children’s wish list you can still make them happy at Christmas (if you buy the things that delivers most value to them). If you forget something from your checklist while shopping food for a dinner, you can end up with a Chili con carne without beef (making it a Chili sin carne). On a wish list you need to dome some things, while for a checklist you need to complete all of them. I think that many people think of a product backlog more like a checklist, not a wish list.
- #NoEstimates semantic discussion – I have been following the vivid #NoEstimates debate on Twitter for some time. A few months ago the focus was on semantics. The term #NoEstimates was attacked because is says ”no estimates”, while the founders of the movement more are meaning ”to seek alternative ways to reduce the need of estimation”. The debate was that it should be called #LessEstimates, #BeyondEstimates or #EstimateFree. My conclusion is that you should call things for what they really are. Backlog sounds to me something that goes ”back in time”, meaning things that you should have done already, giving a feeling that you are late from the start.
- ”The backlog” – Ron Jeffries recently published a very thoughtful blog post about backlogs. Here he presents other ways ”around” using a backlog with Index Cards, Product Vision, Product Increment and Regular Live Product Review. He thinks that the backlog notion should be eliminated, but leaves it up to other persons to actually do so.
Ron Jeffries is a ”big fish” and I assume he can’t come up with new definitions without the risk of annoying a large number of people. Since I don’t have that problem, I hereby introduce the futurelog!
”A futurelog contains items that may or may not be included in your product in the future. A futurelog is best kept short and visualized.”
Some more explanation may be in place:
- A futurelog is per definition a wish list.
- A futurelog focus on value.
- A futurelog is best kept short only showing the items that are ”next in line” with some reasonable buffer.
- A futurelog should be visualized (see next section for some ideas on that).
- The futurelog needs to be revised on regular basis.
- A futurelog is never ”complete” or ”done”, it shall live as long as your product live.
Other than that you can think of and use the futurelog just as a regular product backlog.
How to visualize the futurelog
Since I’m a big fan of visualization I have some ideas on how it could be done:
- ”Priority pyramid” – The simplest way to visualize your futurelog is to use the ”Priority pyramid”. You need to replace priority with value.
- ”The Arrow” – If you have one product and one team working on it, I recommend that you visualize your futurelog using ”The Arrow”. As for the ”Priority pyramid” you need to replace priority with value.
- ”Product radar” – One other elegant way to visualize this is to use the ”Product radar”. Things closest to the center have highest value.
I hope you like the idea of a futurelog to replace the product backlog. As usual, if you have feedback and comments let me know! Finally, you can now say ”I see into the future” whenever you look inside your futurelog :).
All the best,
Tomas from TheAgileist