A Jar of Rocks – a Product Backlog Analogy
I was in a meeting with my manager the other day, and he said something that really stuck with me – he said that I needed to make sure that I was thinking of the product backlog as a jar of rocks. He went on to recount the story that we all heard back in 5th grade science class, and reminded me that the order in which you put the rocks into the jar matters! It directly determines how many rocks you will be able to fit into your jar. You have to start with the big rocks, and then pour in the sand to fill up the rest of the jar. If you do it the opposite way, and start with the sand, you’ll never be able to fit all of the big rocks in.
This directly applies to planning items that will be worked in future sprints. Start with the big rocks, and then pour in a little sand each time. The rocks being big feature components, and the sand being the little fixes and small things that can wait.
What’s a product backlog?
For those of you that are not familiar with product management, a backlog is essentially your list of things to do, broken down in digestible chunks of work. If you’re using tools like JIRA then you can then sort the items from top to bottom, with the most important things on top, and the less important items on the bottom. The top / bottom ranking, in my opinion, is very valuable because it forces you to rank items in the order that they will be completed. It sets clear expectations of what and when something will be worked.
How to manage a product backlog?
Managing the items in a product backlog can be really really hard. That’s simply because you usually have waring stakeholders – business people want business things, data people want data things, and your users typically want a completely different list of items. As a product manager, you’ll always have to balance the demand of different stakeholders – and this really comes to light when you’re planning the work on the backlog.
I always start with priority of the items on the backlog first. ‘Blockers’ are the first items that you should complete. A blocker is something that breaks some core functionality of the product, and it typically prevents some user from being able to complete their core task. That could be a serious data error that prevents Business Intelligence from being able to run an analysis, a product user from being able to complete their core function, or something equally as bad. A blocker is NOT something that someone simply wants, but it should instead have some serious implication that can be easily measured or seen by many users. Blockers are typically shipped outside of sprints, in a hot fix release.
After you get past any known blockers, you have to start with the ‘big rocks’ that are in your product backlog. These are the features or items that you know will help improve the product or meet some new business objective. They are typically larger items that will take one engineer most of a sprint. Put these items at the top of the product backlog first, and then start squeezing in the smaller items. Some of those smaller items might be user interface bugs, text change requests, and other small tweaks that will usually take a small amount of time for an engineer to complete.
Sorting out your backlog in this way will really help your team stay focused and complete the items that are core to your product’s value prop. Filling in the remaining free time with smaller fixes will create some little wins along the way, as well.
How to groom a product backlog?
If there’s one constant in product management, it’s change. Anyone that’s ever worked on any software development team knows that change – and they change regularly. This means that your backlog should also change regularly! I suggest that every week you review the backlog with your lead dev, and / or any other essential stakeholder. You can then review the items that are on the backlog, and move them up or down as the team sees fit. Performing a backlog groom regularly will help make sure that the team is focusing on the items that are truly necessary, and will keep the sand from building up. Remember, blockers stay in the number one spot – so if you find your team shuffling it downwards, it’s probably not truly a blocker. If that happens, bump it’s priority downward.
Having your product backlog nicely groomed will make sprint planning with your engineers go even easier, as well. When your team can clearly see what’s going on, and they know exactly what they should be tackling, you will see your velocity increase – which is what every product manager wants!
As the product manager, you’re in charge of the process and the flow of the team. Having a clean and ordered product backlog creates a clear list of objectives and tasks that teams can then easily work their way down. This provides clear insight into what needs to be accomplished to the team, external stakeholders, and yourself. As you’re reviewing the product backlog, make sure that you see plenty of big rocks, with the little stuff squeezed in around the edges.