There’s a Gap in Your Agile Methodology Part 2 – Creating the Product Backlog

In the previous blog, we addressed the fact that every agile methodology has a gap in defining the “product piece”, i.e. the secret sauce of figuring out where to invest, what to build, and how to discover, deliver, and learn incrementally by validating product in the market. In this blog, we explore some of the ways to arrive at the product backlog in practical terms.

Where do stories come from?

Most current agile methodologies have this idea of a user story: an independent, testable, valuable thing that can be fully implemented, tested, and ideally, deployed during the duration of a single sprint. Stories are at the core of both iterative development as well as design-thinking and other user-centered practices. Stories are pretty cool!

When first introduced to the concept of stories, most of us were taught the definition stated above. But when it comes to writing stories, we are usually told that one simply brainstorms them, typically on note cards. Meanwhile, product managers have their roadmaps that are often organized by features or buckets of features that helped to progress towards product vision and goals. The correlation between roadmap items and stories is typically loose.

I spent some years wrestling with how to get from one of those roadmap items (an idea) to stories that could fit nicely into a sprint. I wanted to do this without losing the larger product vision or the customer problems that we are seeking to solve. I also wanted to do it in a way that wasn’t too heavy, forcing us back into a big-bag requirements and design kind of deal. Brainstorming on note cards never proved to be an effective method.

Years later after meeting and learning from David Hussman, I saw the first workable answer to a user-centered way to get from ideas to stories. The brand of that we teach today is what I’ll share below. It certainly isn’t the only answer, but it is an answer that I’ve seen work many times for many different types of work.

Early Discovery – From Idea to Product Backlog

We can think of early discovery as a lightweight conversation where we bring people together from the product team (ideally the whole product team) that can speak to the perspectives of what is valuable, usable, and feasible.

The goals of the early discovery conversation are to gain a common understanding of what we are building, why we are building it, and who we are building it for (notice we didn’t say how to build it), and the output of the session is a sized and ordered list of candidate user journeys (think epic if Scrum and feature if SAFe). This conversation is something that should play out over hours or days not weeks or months.

The best part about early discovery is that it provides an opportunity to make product choices. A huge outcome of the conversation is to agree on a place to start. This agreement allows us to focus and to experiment versus trying to figure out everything associated with the roadmap item before product development can begin.

So now we’ve got the product discovery team in the room and we’re ready to have this conversation: what does this process look like?

Framing the Idea

Framing is a discussion that looks a lot like a traditional project kickoff on the surface. Teams collaborate on a value statement, goals and success measures, a timeframe, strengths, constraints, design targets, and market conditions. This discussion leads to a common understanding of what we are building, why we are building it, and who we are building it for, often at a 10,000-foot level view.

However, there are two big ways this differs from a traditional kickoff. First, in the traditional world, the artifact itself was the important part (often a kickoff PowerPoint deck). In this case, the conversation is the most important part.

Second, framing is an opportunity to choose a place to start by making product choices. In the traditional kickoff, there was no selecting, no narrowing, and no focusing. By choosing a place to start (or in other words, a place to focus) early on, we can bust the team out of analysis quicksand and more rapidly validate our product approach.

 

Understanding the User

During framing we talked about design targets – the people or groups of people that we wish to impact. Now, it’s time to dig a bit more into understanding our targets as personas. Members of the UX community who have done persona development know this can be an intensive research process. No need to get that intense here. Again, the main goal in early discovery is doing just enough to gain a common understanding.

We’ll consider 3-5 primary personas, describe them, and talk about their values, struggles, and goals with respect to the use of our product. We’ll likely make some assumptions about our personas during this conversation, but don’t worry, those can be validated or refined by follow-up research.

So now that we have our initial building blocks for developing our Product Backlog, we can start to look ahead and start diving into visualizing the product story and identifying journeys through the product story. Make sure to tune back soon for the next installment of the blog.