The Story of Stories: Managing the Product Backlog

The Story of Stories: Managing the Product Backlog – Part 1

 

In previous installments in this series, There’s a Gap in Your Agile Methodology No One Talks About and Creating the Product Backlog – Part 1, we’ve been highlighting potential gaps in your agile methodology and, the glaring gap that is product discovery. In the last 2 blogs, Creating the Product Backlog – Part 1 and Creating the Product Backlog Part 2, we explored how we go about creating product roadmaps and backlogs. At this point, we have this loose definition for our product initiative of what we want to do, who we want to do it for, and why we are doing it. We have an ordered and sized list of ways we can add value.

 

It may seem the hard work is over now, right? Not so fast, the truth is the real work has only just begun. We need to continue and create, curate, and maintain the backlog. Agile methodologies frequently refer to it as “grooming the backlog” or “refining the backlog.” According to the all-knowing Google dictionary, grooming means to “look after the coat of a horse, dog, or other animal by brushing and cleaning it.” In that example we take something that already exists, is static, more or less perfect in its own right, and simply clean or comb it. Friends, that is not what we are doing at all with our product backlogs. Here’s yet another place where we as an industry trivialize the work of the product people; yep, we are just over here grooming the backlog while you’re all are doing the real work on the team.

 

Let’s review what managing the backlog really consists of and highlight some strategies for doing it in a matter that enables your team to work at its highest potential and fuels continuous product learning.

 

Blending Product Discovery and Product Delivery

 

One of the reasons terms like “refining” suck is because it implies that the product backlog is known upfront and then just needs some ongoing tweaks. A lot of teams work this way, but product development reality is very different.

 

The product backlog (and the product roadmap too) is a living thing that is continuously changing. “Why is it changing,” you may ask. “Hey, we just did that whole early discovery thing to create it. Were we that wrong?” Yes, we were wrong, but the cool thing is that by starting somewhere and by building something, we were able to figure that out a heck of a lot faster than if we waited until we were “100% sure” to begin the actual implementation

 

Admittedly, “managing the product backlog” may not be the best term either. When I say, “managing the backlog,” please consider that to be blending product discovery with product delivery. Once we have a sized and ordered list of journeys, our team can begin and work in two cadences: discovery and delivery.

 

The goal of the discovery cadence is to answer the questions: what are we building, who are we building it for, why are we building it, and in what order should we build it. We formalize the answers to those questions in backlog artifacts like journeys and stories. Simply put, the discovery cadence is responsible for iteratively creating enough backlog so the delivery cadence can execute upon it. The delivery cadence is responsible for answering the questions: how do we build the thing? And how much can we build? The delivery cadence is always responsible for doing the actual building (you know, the real work) and building it in the right way.

 

Discovery feeds delivery. As team members working in the discovery cadence, we are responsible for defining the next best problems to solve as well as for breaking the work down into meaningful increments that allow us to learn while still delivering value to our customers. Tactically, you can imagine that sprint by sprint, discovery is working ahead of delivery.

Discovery Feeds Delivery Within the Sprint Cadence

 

Delivery feeds learning. By taking a small thing and building it, we can now test its viability. We will most certainly learn merely by building the thing. Complexity is revealed; dependencies are identified, and implementation patterns are created. Additional learning comes when we put that thing in the hands of users. The sooner we do this the sooner we can react and adjust.

 

Learning, in turn, fuels discovery, and now friends, we are in a cycle of goodness that allows us to discover, deliver, learn, and adjust. This is a blended discovery and delivery cadence.

Discovery & Delivery Cadences: Who’s Involved?

 

Let’s dig into the discovery cadence for a bit and talk about what happens there and who is involved. The pages of our agile methodology likely dictate that the product owner does that discovery stuff, so we don’t really need to worry about that.

 

I would agree that it is the responsibility of the product owner(s) to lead the discovery cadence. I don’t think the PO can or should do that alone. We want a group of people on the team that work together within the discovery cadence. This group should be able to collectively speak to what is usable, what is valuable, and what is feasible. This means we need people who understand the business, the users, and the technology working together. Often this group consists of the product owner, a user experience person, and one or more technical leads.

 

Okay, we’ve got our group together now, so how do we go about doing this discovery work? Find out in our upcoming blog.