The first artefact that most people come across when learning about Scrum is the Product Backlog and mastering the Product Backlog is one of the key enablers to success with Scrum so what’s involved in this?

What is the Product Backlog?

Ultimately the Product Backlog is a collection of needs, wishes, requirements and hypotheses about what will help our product be successful and valuable. Some of you may be familiar with requirements documents and mastering the Product Backlog will have some similarities with that but there are some significant differences too.

In this blog post I will suggest five tips for mastering the Product Backlog:

1. Embrace it’s incompleteness
2. Mix solutions and goals
3. Keep it focussed
4. Guess a little
5. Balance the short-term with the long-term

Mastering the Product Backlog with Imperfection

Whereas a traditional requirements document is intended to capture the complete set of our user or customer needs in advance of the work, the Product Backlog is intended to be an emergent, evolutionary artefact.

We are expecting it to be incomplete, imprecise and unstable because, in a complex space such as new product development, it is impossible to predict in advance what our users will want. Indeed, it’s often impossible for our users to know what they will need!

This means that mastering the Product Backlog requires us to let go of our desire for perfection and completeness. If we spend too long trying to ensure we have covered everything then we sacrifice our ability to deliver some of the more important Product Backlog items now and learn about some of the unknowns empirically.

Mix Solutions and Goals

Whereas a requirements document will attempt to remove ambiguity by detailing out the solutions to be delivered, mastering the Product Backlog requires a somewhat different approach. Sure, there are some requirements that need to be implemented in a certain way and capturing the specific steps and criteria for a successful delivery in advance will make for a more efficient and successful delivery of those items.

Many situations, however, are not solution-specific and asking for a solution could be detrimental. Take a cup of tea for example. I could ask for a cup of tea and be met with a bunch of questions like:

“What type of tea do you want?”

“Do you take regular milk? Skimmed milk? Oat milk? Almond milk? Soy?”

“Do you take sugar? Sweetener? Honey?”

“How hot do you want it?”

“Do you want it to takeaway or in a china cup?”

and so on.

And yet…that cup of tea that I’m asking for might not be serving my need.

If I were met with the question:

“Why do you want a cup of tea?”

I might have to stop and think…

• Is it because I’m thirsty?
• Is it because I’m cold?
• Or tired?
• Or because I have a habit (or addiction)?

If the real answer is any of those, then a different solution might be the better response. An isotonic drink, a warm sweater, some sleep or a detox for example. But if I ask for a cup of tea then I will likely get a cup of tea.

Mastering the Product Backlog involves specifying where that’s appropriate and allowing room for solution-evolution in other areas. Not only does it lead to greater creativity and innovation but engages the delivery team a lot more too. User Stories can be a good tool for this. Check out this video on splitting your stories.

Mastering the Product Backlog means Keeping it Focussed

An evolutionary and emergent artefact runs the risk of becoming chaotic and out of control. Great Scrum Masters and great Product Owners will use a clear and compelling Product Goal to help keep the Product Backlog focussed. By explicitly stating the vision of the Product and then subsequent Goals of the Product and each Sprint, we can ensure that only items that contribute to those goals are allowed on to the Product Backlog.

We might make use of Backlog Themes to allow us to link, group and cluster Product Backlog items. We might colour code them or indicate linkages in other ways but mastering the Product Backlog definitely involves stopping it from getting out of control.

For more tips on how to keep your Product Backlog small read this.

Guess a Little

This might sound strange but not everything on the Product Backlog is going to be a user need or a customer requirement. Some things our users will be shouting about – whether it’s a bug that they have to workaround or a glitchy user interface – these things are definitely things we know about.

But there will also be things we have a feeling about. Perhaps we’ve got a suspicion that adding this little feature will increase engagement or reduce customer attrition. You don’t have anybody asking for it necessarily but you have a feeling. Well, sometimes we need to follow our instincts and this is where we guess a little. Creating an experiment to test a hypothesis is just as valid as delivering on something that a user has logged as a defect.

In the complex world of product development, sometimes we need to go “off road” and try something. This is very related to the next tip for mastering the Product Backlog.

Balance the Short-Term and the Long-Term

As well as experimenting here and there, mastering the Product Backlog involves trying to get the best of both worlds when it comes to time horizons. We know that we cannot wait very long to deliver, we need to get value to our users and customers quickly, both to get feedback but also revenue. We also know that it we just focus on the here and now then our strategic aims can get waylaid.

So Product Owners and Scrum Masters make sure that for every “quick win” that excites our users right now, there is a “slow burner” that is an investment in the long-term strategy and future-proofing of the product. Perhaps it’s the architecture, the design or the code-base. Perhaps it’s exploring the expansion into new markets or the integration of new technology.

Mastering the Product Backlog takes time to get good at and is something that we coach a lot of Scrum Masters and Product Owners on at Agile Mastery Institute.