How big is your backlog?
Is it a very long list of very different items?
Or perhaps a collection of multiple products or even teams?
In my experience the backlog can become an impediment. When the backlog isn’t transient, it can cause headaches, delays, conflicts and possible confusion.
When it is too big, the transparency suffers. And that can have an impact on the quality of your product or your relationship with users and stakeholders.
Take backlog management seriously. If you don’t help your backlog, it certainly will not help you.
I wrote down five principles for keeping your backlog awesome.
Own the thing
First thing to take care of: own it. It is yours. Not your stakeholders.
You, as the Product Owner, are accountable for effective Product Backlog management. From managing (creating, ordering, delegating, etc) PBI’s and clearly communicating the Product Goal, to ensuring transparency of the entire Product Backlog.
This all sounds very serious. And that’s probably one of the reasons why people keep the backlog close to their chest, focussing too much on the content of the items and neglect the visibility.
Be proud of your backlog, you and your team(s) have put a lot of work in.
Just a tool
The backlog is just a tool, nothing more.
Like the hammer is a tool for the carpenter. The hammer helps the carpenter to build a piece of furniture which in turn helps the customer with their interior decoration.
Tools are helpful. Without tools, it becomes very difficult achieving something of value.
Same goes for your backlog. It is just a tool. And you should take care it. If you neglect to nurture them, the tools get dirty, out of balance, blunt and eventually it will be an obstacle in your way to success.
A tool is meant to be used. An unused tool is waste. It is unnecessary. If your backlog contains too many items, the bigger part of the backlog will not be used. It is waste in fact.
Use this tool to aim for the Product Goal. Focus on outcome.
Size
I’ve seen backlogs of enormous proportions.
A big backlog could be a sign of several situations. Wrong stakeholder management, lack of transparency, not living the Scrum values, etc. Consider fixing this.
If the backlog is still out of proportions, it is time to do some calculating.
How many PBI’s are delivered per sprint on average? That’s your Story Count.
Now count the number of items in your backlog. Divide it by the Story Count and you have a number of sprints you still have in prospect.
Does that number scare you? Good, go minimize your backlog. Clean the thing up.
Marie Kondo the hell out of your backlog.
Keep the things that are important, throw away the things you do not need.
Another approach could be something like this:
Let’s say you have a 60 minute refinement session every week.
As an experiment, you could try to go through your entire backlog within that hour. If these 60 minutes are sufficient, the size of your backlog can be considered as good.
Or use a different measurement method, but keep the measurement value as small as possible.
Yes, it is an experiment, but it could be a useful one to consider.
So size matters.
And smaller is better.
Transient
Like the Sprint Backlog, which has a lifespan of two to four weeks, your Product Backlog should be transient as well. Maybe not the existence of the Product Backlog itself, but certainly the content of it.
If the PBI’s are there too long, consider them obsolete. You can try to answer the question: why are they still there? But on the other hand, the evidence speaks for itself.
When new insights and hypotheses arise, add new PBI’s which are relevant for a short period of time. They are transient. Don’t get attached to the PBI’s.
Create your feature, test your assumptions or hypotheses and move on.
Compare it to a waiting room at the doctor. Sometimes there are a number of patients waiting, but they know that it is their turn that day. They are all important and all are seen by the doctor. At the end of the day, the waiting area is empty again.
Transparency
So when your PBI’s are transient and the content of the Product Backlog changes a lot by getting them to Done through sprints or removing them because of their redundancy, transparency becomes even more important. People need to know what’s up next. It comforts them in a way. By making and keeping your backlog transparent, you comply with the important Scrum values, you can better manage your stakeholders, you give in to the transiency and force you to keep only valuable items.
You can use all kinds of handy resources that benefit transparency. I myself often use physical or digital dashboards, interactive sessions and of course the important Sprint Review. But the most important thing is the conversations you have. Communication makes your backlog transparent.
What about having no backlog at all? #nobacklog
Sounds scary, doesn’t it?
But some people actually do this. By using super transient items, based on fast feedback and new insights.
It forces you to act quickly, communicate a lot, share a lot with your stakeholders and users.
To be honest, I’ve always used a backlog myself. There hasn’t been an opportunity to try #nobacklog yet, but who knows in the future.
