Not All User Stories are Created Equal

If you don’t know, I’ve got some opinions about Scrum, the Product Owner role, Backlogs, and User Stories. I’ve written a book 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 blog post 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.

Improved Contingency Discussions

One advantage of this approach was that it simplified our discussions and trade-offs when we ran into trouble within a Sprint. Our options to jettison Sprint scope ran from the filler and infrastructure stories first. Then we would tradeoff supporting stories if we had to. The goal was always to hold the anchor stories “dear” and deliver them whenever possible.

Since there were only 4-6 stories totally “in play” it provided quite a bit of clarity around our options. That wasn’t the case when we had more finely grained stories in play.

Advantages

When we applied this approach, we recognized some distinct improvements in our story writing, backlog grooming, sprint, and release planning. Not that we were doing them poorly. In fact, we were fairly mature. But it helped us get to the “right level of abstraction” when dealing with our backlog workflows. Here are some of my observations on the advantages:

  1. It streamlined our Backlog Grooming. Once we found appropriate anchor and supporting stories, as long as they were “executable”, we stopped breaking them down. It not only cut the number of stories “in play”, but increased the quality of our discussions surrounding the stories for each Sprint.
  2. It better aligned the teams work to their Sprint Goal and it better aligned the teams work to their Sprint Demo. In addition, it drove more meaningful and impactful demo’s—making it incredibly easy to “connect the dots” from the Sprint Goal to the Demo.
  3. It allowed for more swarming around the anchor and supporting stories; it’s really, really hard for a team to “swarm” around a set of 25-1 point stories within a Sprint. In our case, our anchor and supporting stories were places where the team could really swarm / pair / collaborate around the work.
  4. It allowed for more look-ahead; a team would only have to look at ~ 25 stories to get a grip on a quarterly release. So we found ourselves grooming ahead to detect necessary story spikes and dependencies that needed to be managed. In fact, we were largely groomed for the next release by the third sprint of the previous release.
  5. It helped us better deal with “complexity”. Typically, complexity was in our anchor stories. Quite often the team would need a Research Spike to clarify the anchor. We felt this was time well spent from a design and quality perspective.
  6. Sprint Planning, in a word, was incredibly smooth. The sprints we composed of a small number of stories. The goal was clearly linked to the anchor story. And we always planned for the demonstration as part of Sprint Planning. In fact, we always knew the relationship of work from one sprint to the other as well.
  7. By definition, this approach is goal-oriented and keeps the Product Owner focused on a Minimal Viable Feature for each Sprint, and a Minimal Viable Product increment for each release.

Wrapping Up

Nowadays, I often see teams dealing with far too many stories at a time. I was coaching a team not that long ago where their story mix was on the order of 1-2-3-5 points at most. In fact, most of their stories were in the 2-3 point range. Their average sprint velocity was around 30-35 points; so that meant they were dealing with 10-15 stories within each sprint. Their release train was undefined, so a teams’ release might encompass 80+ stories.

Their sprints were sort of “all over the place”. The teams lost their focus. Their story boards were incredibly complex and busy. It was hard for them to keep a view to prioritized business value. Sprint planning meetings were long, arduous, and often drove too far in the weeds. Complexity and technical risk was distributed across stories—so hard to determine. They rarely saw the opportunity for a story spike to gain a sense of understanding.

I introduced them to this notion and met a lot of resistance. They mentioned that their previous agile coach had told them to break their stories down into fine detail. They felt this was the right granularity for them—so their efforts could be tracked and reported on a near daily basis. I tried hard to “unwind” them from this perspective with limited success. I told them that they were breaking things down in advance of the sprint and that the sizes gave them a false sense of security.

But there’s a balancing act to be struck.

Sometimes large stories are just fine as-is. They are more understandable and estimatable. They also drive spikes when appropriate and allow for a team to swarm around the story. Most importantly, they allow the details to emerge just-in-time within the sprint, rather than trying to sort through everything in advance without working on code.

At the very least, I was looking for them to simply try this approach and see for themselves if it would be helpful. That’s where I’ll leave it to you. If you find yourselves writing, planning, and executing your stories at a fine level of granularity, consider stepping up a level. It might anchor you to better execution and delivery performance.

Stay agile my friends,

Bob.

1 Comment