If you don’t know, I’ve got some opinions about Scrum, the Product Owner role, Backlogs, and User Stories. I’ve written a about Product Ownership and I spend a great deal of my time up to my eyeballs in stories and backlogs at various clients.

One of the things that frustrates those clients is that there are very few “prescriptive rules or firm guidance” when it comes writing stories and crafting Product Backlogs; in many ways, it’s more art than science. It’s also a practiced skill that gets better the more you actually do it—of course as a team, which is also true of agile estimation.

Quite often I see Product Owners define a list of “stories” solely by themselves. Sometimes they’re creating them from scratch. Other times, they’re decomposing a traditional requirements specification into small stories. While both of these activities are all right to “seed” a backlog, they miss out on the collaborative part, the team-based discussion and evolution part of the User Story. While story writing is a big part of the Product Owners’ role, I prefer them to do most of it collaboratively. I use the analogy that it “Takes a Village” to create and maintain a healthy Product Backlog and my experience largely supports that mindset.

Another challenge…

Effective story estimation and deciding when you stop decomposing stories is another challenge. Some coaches influence their agile teams to break their stories down into very small chunks, for example, work that can be done by one or more members of the team in a day.

This could result in a sprint being composed of 25-35-more individual, 1-2 point stories. From a decomposition position, this is wonderful. Everything is finely grained and extremely understandable. So on the surface, this “feels right” for many teams. However, I have a problem with it from several perspectives:

• Having finely grained stories inhibits the team’s ability to swarm around the work
• It often leads to very disjoint Sprint Reviews or Demos. Yes, work is being demonstrated, but how it all “fits together” is often impossible to demonstrate or communicate.
• From a release or feature perspective, it’s hard for the customer to understand what the team has just accomplished—relative to the end goal.

Now we could go to the other extreme and have the team work on a 25 point story. That would alleviate some of the above challenges, but now it would introduce too little granularity and higher risk for the team. Clearly not everyone could work on the one story. And what if they underestimated it and it was 50 points?

What I’m alluding to is a “happy medium” between loading a sprint with one great big story and a series of incredibly small stories. It sounds like that might be the best strategy. But how do you “get there”?

That’s where I’m going next.

Boulders – Rocks – Pebbles

At the risk of repeating myself, I published a in 2011 that talked about sizes of User Stories as you’re conducting your backlogs. The reference was to an analogy of story sizes as they were groomed and approached sprint-level execution.  The three levels of story sizes were:

• Boulders – Very Large stories; synonymous with Epic
• Rocks – Medium to large stories; small Epics or larger stories
• Pebbles – Small stories; ready for execution

I’ve found the analogy useful when describing the pattern of “breaking down” or decomposing User Stories during Backlog Grooming sessions with the team. And that’s useful, but I want to introduce you to another view to help you with prioritizing your Product Backlog by considering story sizes and themes.

Anchoring your Backlog Prioritization

I’ll start with a real-world example:

While I was working as a coach at my old company, iContact, we noticed several things in our grooming, estimation, and Sprint Planning. Let me share some of them in a discrete way:

1. Our Sprints were 2-weeks in length; our team sizes surrounded the classic 7 +/- 2 of Scrum
2. We implemented a Release Train of 4, 2-week Sprints and then a single “Hardening” week before we would push to Production; so roughly a quarterly production release tempo
3. We used story points for estimation; the classic modified Fibonacci sequence were the units
4. We noticed that a 13 point story “would fit” into a 2-week Sprint. A 20 point story would not. We started using the term: executable story for any User Story from 1 – 13 points, in that it would “fit” into a Sprint.
5. We also noticed that 2-13 point stories were never successfully delivered from a Sprint, even if the teams velocity math supported it
6. Our velocity was on average 25 across 10 teams. Lowest being 22 and highest being 29.

Our Product Owners started managing their Product Backlogs with these patterns and characteristics in mind.

For example, they came to the conclusion that each sprint could sustain a leading story of significant size—for example, an 8 or 13 point story. They considered this the anchor story for the Sprint.  The next thing they would consider was finding support stories for the anchor story. Clearly size came into play in both of these cases, so as the team was grooming, breaking down, and estimating stories, they looked for anchor and support stories in clusters.

Anchor stories would drive the major theme for each Sprint and connect to the Sprint Goal and the Sprint Demo. Once they found a cluster of them (anchor and support stories) that would fit into a Sprint, they would look for other stories to “surround them” to fill the teams average remaining velocity. A typical example of this might look like the following:

• 13 point Anchor Story
• 8 point supporting Story
• 3 point filler Story
• 1-2 points infrastructure Stories

for a team with ~ 26 points of capacity. Before we’d started doing this, it was common for our stories to be much more finely grained and to be disconnected from each other. Finding clusters that would have demonstrable customer value was difficult. And we felt that we were stuck in the minutia and not seeing the big picture.

If you extrapolate this a bit, each team would be grooming 4-6 stories for each Sprint or 16-24 stories for each release. From a grooming point of view, this made it much easier for the team and the Product Owner to get their “brains wrapped around” a release. It contained a relatively small set of stories focused on Minimal Viable Features (the Anchors) and a supporting cast of stories.

Each Product Owner approached their Backlogs with the notion that a release could contain (at most) 4 anchor stories with an appropriate supporting cast. These “must haves” helped laser focus each release. It also helped stop teams’ from over-committing to too much work.

Wrapping Up

As I often say, this approach really helps the team in staying “at the right level” when they’re writing and grooming their User Stories. In the next part of this discussion, we’ll wrap things up by discussing the implications to release planning and generally keeping a healthy balance in your Product Backlogs. Until then…

Stay agile my friends,

Bob.