Agile Story Sizing

When trying to work with stories, it’s important to keep them small. What do I mean by small? Small. Smaller than that. Even smaller. Now you’re getting it.

(NB: For all mentions of story or work, assume that the value has been correctly identified. This post isn’t about identifying the right work, but about doing the work well.)

Why should stories be small?

Human beings are terrible at estimating things that are going to take longer than about 2 days. We’re honestly not well equipped for it. We’re both too optimistic, and too pessimistic. There’s a lot of research out there that tells us that we’re bad at estimating risk or uncertainty. But if you’re developing software, the odds are good that there’s a significant amount of uncertainty in what you’re doing. Even if you’ve done it before, or done it elsewhere, it’s different this time. Due to context, language, tools, assumptions, teammates, etc. It’s going to be different.

What’s more, when you get your estimates wrong (as you will, because ‘estimate’), they’ll always run long, for 3 reasons:

1. Parkinson’s Law — “work expands so as to fill the time available for its completion.” This means that your estimate is almost never going to be too high. Because if it’s too high, you’ll end up finding more work, or taking more time.

2. We’re optimists. When asked how long something is going to take, we rarely respond with the 99th centile of probability. We’re usually much closer to the 50–70th centile. If pressed, most of us will admit it in the moment, but it rarely changes our initial estimates. That means that the estimates we give are often based on assumptions that everything will go the way we want it to. This often gets derailed by:

3. Inherent uncertainty. Knowledge work is variable. The systems can be volatile, or complicated. Needs change. Unexpected bottlenecks appear. There’s a degree of uncertainty that’s built into almost all knowledge work, that we tend to overlook. The bigger the work, the bigger the amount of inherent uncertainty.

We can reduce the impact of all 3 of these things by reducing the size of the stories we’re working on. The smaller the story, the smaller the variability, the smaller the room for error, and the smaller the impact of being wrong.

If you tell me a piece of work is going to take 2 weeks, I know that you don’t really understand what’s involved, even if you’ve studied it and thought about it fairly extensively. It’s too big. So when I hear an estimate that size, it gets translated into “between 8 days and 8 weeks.” That’s not comforting.

On the other hand, if you tell me a piece of work is going to take 1/2 a day, I hear “between 3 hours and 1.5 days.” The error bars on the work are smaller because by shrinking the work, the inherent uncertainty and hidden complexity have both been reduced.

What does this mean for estimating?

Quite simply, don’t. If the work is smaller than 2 days, don’t bother estimating it. If it’s larger than 2 days, it’s too big. That’s the level of estimating you need to do.

“Estimating tasks will slow you down. Don’t do it. We gave it up over 10 years ago… Best teams have small stories and do no tasking. They move to acceptance TDD.” -Jeff Sutherland

How do I write small stories?

Easy to say, hard to do. A story is the smallest possible amount of work that has value. It might be value to the end user, or someone in the business, or someone in the team. Identifying the value and the story takes time and practice.

Some tips

Use the story format. Understanding what it gives you allows you to understand when it’s a good fit, and when you might want to replace it with something else that provides the same benefits, but in different ways.

• As a…
  - Who benefits from the request? Who is it for?
  - The purpose of this is to frame things so the person doing the work can empathise with the person making the request.

• So that…
  - What’s the value of this work?
  - Why is it being done?
  - Connects the end user and the person doing the work to each other
  - WITHOUT VALUE, THERE IS NO STORY. If you can’t find the value, throw the story away. If it’s important, it’ll come up again.

• I want…
  - Easiest part of the whole thing. What’s the request?
  - This request won’t necessarily be fulfilled. If the value of the story can be satisfied in a different way than this request, that’s OK.

• Acceptance Criteria
  - A (very) short list of how the developer and the author will know the work has been completed.
  - Testable
  - ‘How’ not ‘what’
  - If you’re specifying where on a page something goes, there’s too much detail.

Why write testable acceptance criteria?

The point of the story is to tell someone what needs to be done. That doesn’t stop someone from over-engineering. Testable acceptance criteria do. Especially if the tests are written first (TDD). Writing only enough code to pass the tests is fundamental to one of the agile principles: “Maximise the work not done.” It helps us keep the code simple and small. Smaller code helps us keep our ego out of the code, so we become less attached to it, and more open to getting rid of it when it has served its purpose.

How to get there

It can be difficult to see how to get from where you are to a place where stories are small and valuable. That’s OK. The important thing is to look at where you are, and go from there.

If we accept that stories shouldn’t be longer than 2 days, then the first thing we do is look at our stories and see if they can be made smaller. It’s important when doing this to remember that stories also have to have value. Splitting a story by function (development story, test story, release story) ensures that no value is delivered, and the work becomes more disjointed. Break the stories down so that each one has end-to-end work.

After making stories as small as you know how, start to measure how long they take to complete. Keep track over time. Over a few weeks, or a few months, or a few iterations. If you’ve made your stories as small as possible, and they still take a long time to complete, don’t stress. Use it as a learning opportunity. Stories that take a long time are a red flag. That doesn’t mean the stories are wrong, or bad, it means that there’s something else to investigate. Look at how the work gets done. Maybe things get delayed by external approvals. Maybe things get stuck waiting for a tester to be free. Maybe your stories bunch up waiting for release. Maybe there are lots of bugs. Maybe the code is a mess and it doesn’t pass your review process. Maybe your architecture doesn’t fit the way the team works, or the customer’s need. There can be lots of reasons.

When you reach the point of identifying the issues in how the work is done, remember that making the stories smaller is no longer likely to have much impact. Instead, all the impact will now come from making the process more effective, smoother, faster, and with higher quality. Focus on those areas. You don’t have to stop delivering value to work on those things, either. Each time a story gets stuck, spend time getting it unstuck. Help your testers write automated testing. Automate a manual step in the release process. Sit with your customer to figure out why they’re unhappy with the work that’s been done.

If you tackle the reasons stories get stuck, you’ll find the amount of time it takes to complete a story decreases. And you’ll learn more about the value of the work you’re doing, too. This, in turn, will help you figure out how to shrink stories even further. It becomes a positive loop fairly quickly.

In the end

We work in an agile fashion in order to get rapid feedback from our users that helps us figure out whether we’re doing the right thing, and to change what we’re doing in order to satisfy their needs.

Feedback cycles have to be short to be valuable. The longer they are, the less we learn from them and the less value users get from our work.

If your stories take 2 weeks (read: 8 days to 8 weeks) to complete, then the value is significantly lower than if they take 2 days.

Short stories create happy customers, happy developers, better code, less waste, and closer connections between developers and the people they’re serving. Think of that the next time you’re trying to decide just how big your next story should be.