Continuing from our last post, I want to discuss some of the advantages of taking this “anchor-based” approach in your Product Backlogs.

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.

Here’s a tabular view example of how we approached planning a release. Once we filled in the table, it would then drive the prioritized list of stories on the Product Backlog for each team. In essence, there would be 4-clusters of Anchors, Supporting, and Filler/Infrastructure stories from each team for every release.

Figure 1, Example Release Plan – Backlog using Anchor Stories

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.

Thanks for listening,

Bob.