Managing the Product Backlog – Part 2

In the first part of this blog on Managing Product Backlogs, we learned about the importance of blending product discovery and product delivery.

 

Authoring Journeys, Stories, and Tests

The discovery group starts by grabbing that next journey off the backlog. I’m going to use the word “journey” to refer to the backlog item that is larger than a story (you may call them epics or if using SAFe, features. It’s all good).

We grab that next journey, and author it. That means we add a description that answers the questions “who,” “what,” and “why.” Then we add acceptance tests at the journey level. These are cross cutting tests that describe the behavior we expect the journey to deliver. They are written in test language, so they can be verified.

Now, we have a general understanding of what this journey is and what we hope to accomplish. Let’s take on some of the cross-cutting concerns as a discovery team. We may need to create some sketches of the user experience. We may need to understand some architectural pieces. We may have larger constraints to deal with.

Next, we can go back to our story maps and determine what stories we want within this journey. It’s likely that we’re just working with titles at this point. That’s a good thing as we have more learning to do until we author all the story’s details.

Now, we repeat the above for each story in the journey. We author descriptions and define acceptance tests. We may review these stories with the larger team and assign sizes to them. Once authored and sized, they are ready to be worked on within a sprint.

This process is continuous from story to story within a journey and from journey to journey within the product backlog. New stories and journeys will be created, and when product learning happens, you can adjust the product backlog without having wasted a lot of your hard work.

 

How far ahead should we be?

I’m commonly asked the question, “How far ahead should we be?” This means how many sprints ahead should we have stories complete to cover within the product backlog. I was teaching a course at a Fortune 500 financial services corporation when one of the attendees asked this question. Before I could respond, a gentleman in the back of the room who happened to be a Scrum master proudly stood and said, “My team has 14 sprints of ready work in the backlog right now.” That was over six months’ worth of backlog that he said was completely defined.

My jaw dropped, and I had to collect myself, so I could respond constructively. Let’s consider the consequences of having that much product backlog prepared. Imagine the investment that team had made in creating that backlog. That was a ton of work; it was likely person months of work (if not person years). More importantly, the team (and stakeholders) were heavily invested in that product backlog. What happens when something changed? What happens when the market shifts and that team needs to help in a different way? That team wouldn’t want to change that backlog. They are overly invested in it. Any change would introduce waste. Now, we have stifled product learning.

Some of you might be thinking, “Hey, it is a financial services company. They work on longer cycles and need to be methodical to maintain security standards and such.” Yes, true. But what if I told you this was the team developing the company’s mobile app?…

To answer the question, I believe discovery should ideally work about 1-2 sprints ahead, but I would expect lower level of completeness and certainty in the sprints that are further out. This gives us room to adjust later without significant waste.

How far ahead should we be in story authoring?

The image above describes how I liked to work as a Product Owner. I admit that sometimes it wasn’t like this as my colleagues and I were in the chase of trying to come up with enough work for the next sprint. However, if you can get to a picture like this in your backlog then you the Product Owner can take a vacation sometime too.

 

Creating a Culture of Product Learning

We could go into additional tactics about story authoring and will do so in a future webinar. What really matters here, though, isn’t the format of your stories or how awesome your “as a” statement looks. What matters here is that you, your team, and your product management community take an iterative approach to discovery just like you do for delivery. Seek to reorient your efforts and the efforts of your discovery group around these key points.

• Product discovery is iterative and continuous.
• The product backlog is a living thing that is continuously maintained and enhanced, not just refined.
• Discovery feeds delivery, and delivery fuels product learning.
• Product learning tells us when to shift and to adjust. It’s that learning that gives us agility not some methodology.

Watch the webinar to learn more!