#NoEstimates and Story Sizing

In [my last post about #noestimates] (https://smallerinfinity.com/posts/my-approach-to-noestimates/), I touched briefly on story sizing. This prompted a couple of questions from a thoughtful reviewer.

• What made you pick 5 days as the right size?
• Are you just comparing the stories to previous ones to say - yep, this feels like 5 days compared to the last x number of stories that we have sized in the past?

Let’s dig into this some more.

How Small Should a Story Be?

The short answer is “as small as you can reasonably make it, and no smaller”.

A story should always deliver value that a customer would recognize. User story language helps ensure this. This sometimes makes it harder to think of smaller stories, just be creative.

In my last post, I said I try to size stories so that “5 days is more than enough” to get them done. That’s true, but it isn’t my starting position. It’s just a “reality check” that allows me to notice when I am off track. Often, I ended up splitting stories that I think will take a developer 0.5-2 days to implement, and those are fine. Sometimes, the story turns out bigger than I thought, and that’s not the end of the world either.

I like to focus on the value proposition of the story, and deliver the smallest increment of value possible. A question I ask a lot is “what’s the most valuable part of this feature?” The answer to that question can be the focus of one story, instead of the whole feature. When agile thought leaders talk about splitting stories vertically, this is what I think of.

A great resource on splitting stories is this great flowchart and the related posts. I had been using some of these ideas without formalism for years when I discovered this, but learned more when I found it.

Why Small Stories?

My motivation is (always) to better serve my stakeholders.

An important stakeholder here is my team. My goal for them with small stories is to encourage frequent accomplishment of small goals. Whenever I’ve been on a winning team, a feeling of progress and a determination to get shit done have been a common theme. These attitudes correlate strongly with small stories, and have a negative correlation with stories that drag out.

(Another goal for the team is that estimation and the baggage that goes with it sucks, and is demoralizing. More on that some other time, perhaps.)

The other important stakeholder is the needs of the business. The business gets fine-grain decision making, predictability, and a clear way to understand progress towards coarse-grained goals from this system.

Fine-grain decision making is an obvious benefit. The smaller the stories are, the more detailed prioritization can happen. This enables the business to ensure that however far engineering gets through the backlog, the best case scenario of features exists in the software for that point.

Predictability happens for two reasons. First, because smaller stories have a smaller magnitude of variance. So the variation in speed through the backlog decreases, and predictions are easier. The second reason happens as time goes on. The small stories mean that meaningful stats on the performance of the team can be gathered sooner.

Finally, progress is easier to understand because it changes in a clear and measurable way more often. We’ve all spent time working with big stories that stay open for weeks or even months. The best possible visibility into progress on these large stories is some hand-waving about percent done from someone working on it. If stories are small, business stakeholders never need to peer inside a story to understand progress.

Summary

Small stories were the practice that enabled my implementation of #noestimates to work and deliver value to both the team and the business. That said, these are valuable for the same reasons in a context where you have to provide esitimates.