KiteFrame LogoKiteFrame
Published on

A note on estimation

By Tim Mortimer

I have been part of a lot of teams that estimate the size of the stories on their backlog.

Every Sprint, the team dedicates time to refining the backlog. Beyond debating and negotiating the acceptance criteria, the team rightfully ask whether the story in question could be broken down into a smaller story.

Then they size it. Some teams use Fibonacci numbers to do this. Others like to use T-shirt sizing. Your milage may vary. Nonetheless, time is spent debating its size and coming to a conclusion.

At the beginning of the next iteration, the Sprint Planning meeting comes about. More time is spent deciding whether the Sprint is full enough. Some teams will review past Sprints to assess how much they've done previously. Someone points out that the last Sprint was different to the upcoming one because of some unplanned work popped up out of nowhere.

Then comes the daily stand up. With it only being day 2 of the Sprint, most of the stories lie in the 'Not Started' column. They mentally weed out the stories they've not started so that they can talk about the progress on the couple they have.

Next, one of three things happen:

  1. The team completes all the work in the Sprint, and decide to pull in more work, not after giving themselves a little metaphorical pat on the back for beating their prediction of course.
  2. The team complete the Sprint having completed all the work and nothing more. They must be really good at estimation you tell yourself. It's a shame that this is the first time they've got it bang on in the last two months.
  3. The team fails to get all the stories done in the Sprint. The next retrospective is spent debating what went wrong, and what they can do to estimate better next time. Sad panda emoji are aplenty.

This is a lot of work that could have been avoided. The goal of an agile team isn't to judge themselves on their ability to estimate work. The real goal is to provide value to the business as quickly and cheaply as possible, running small and cheap experiments to learn whether or not they're heading in the right direction.

What would happen if we just stopped all this estimation?

There is still a tonne of value in assessing stories to see if they could be broken down. Smaller stories allow you to learn more quickly and at a lower cost. I wholly recommend checking out Fifty Quick Ideas To Improve Your User Stories by Gojko Adzic and David Evans for help with this.

Furthermore, if you are maintaining a backlog, you should also make sure that stories are prioritised. This helps you to make sure you're always working on the backlog items are the most likely to provide the best learning opportunities.

But is estimating the size of each individual story really necessary? What are you getting out of it?

I would encourage you to experiment with working without estimations for a little while. See how it goes. Does your throughput increase? Do you commit to less work and spend less time context switching day-to-day? Give it a try and let me know how you get on.