The following is a guest post by Ilan Goldstein, author of "Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips" which is full of advice on speeding up your adoption of Scrum. It's a great book I can highly recommend. You can read my foreword to it for more of my thoughts. Here are Ilan's thoughts on what to do with a large product backlog.
--Mike
You’re sitting in class, really enjoying your agile training (that you’ve somehow made time to attend between all of the super-urgent tasks that keep popping up on your multitude of lists), when all of a sudden you hear words come out of the trainer’s mouth that seem to make perfect sense yet also sound like crazy talk at the same time…
Those words being: The Product Backlog is a single ordered list of any type work that needs doing (features, bugs, research requirements etc.) and only has:
- ONE top priority item,
- ONE priority two item,
- ONE priority three item
- So on so forth….
“What the? If we do that we’ll have over [800] (insert your own massive number of choice here) items in this Backlog thingy and the chances of uniquely sequencing all of those is somewhere between zero and nil!”.
I hear this type of concern all the time and for those reading this article feeling similarly hesitant, my message to you is to chill, as there is always an option for handling even the most gargantuan of Product Backlog mountains. That option: declare Backlog bankruptcy!
How does it work?
Our Product Owner puts together a short note (be it in email, skywriting or other) that goes a little something like this:
Hi All,
As I’m sure you’re all well aware, the maintenance of our various, never-ending lists is becoming unmanageable. This is creating a major diversion from delivering the highest business value to you in the shortest time. These lists are overwhelming, distracting and frankly, many items on them are out-dated and no longer relevant. As such, we’re taking the somewhat drastic approach of declaring ‘Backlog bankruptcy’.
What this means for you:
- All items on all lists are being archived. Could be worse, at least we’re not shift-deleting them…
- Moving forward, we will be consolidating all requirements, be they features, bugs, research requirements (or other) into a single list that we will be calling our Product Backlog.
- No doubt there will be some items on the now archived lists that should be resurrected and included within our new ‘fresh-start’ Product Backlog so please let me know about these. If an item is a feature or research requirement, please make it clear how it aligns with our Product Vision and if it’s a defect of some kind, please let me know about the potential impact relative to other bugs that have recently been addressed.
- To ensure that we don’t need to declare bankruptcy again, we are going to take out less of a ‘loan’ this time around and limit the Product Backlog to [50] (insert manageable size) items. Once this quota is full, we can only add a new item by removing another or waiting for a space to open up.
Many thanks,
Your faithful Product Owner
Clear benefits
Now this approach has several obvious benefits. Firstly, you are ensuring that the items in the Backlog are current and relevant. Secondly, you ensure that all resurrected (and new) items go through the all-important Product Vision filter. Finally, you will find that this is a very manageable process, as new (or resurrected) items will be drip-fed to you while the various stakeholders take time to compile their cases for inclusion. This will ensure that the prioritizing process is progressive rather than all at once.
Wrapping Up
Humans are natural hoarders (you should check out my computer cable collection!) and that’s why we often find ourselves in Backlog bedlam! That being said, our species also really appreciates the concept of a fresh-start. Backlog bankruptcy offers us that rare opportunity to start afresh, with the knowledge that our old lists are being archived (rather than destroyed) and thus avoiding scaring the natural hoarder in all of us!
