Zen of Scrum: When Estimating, Size Matters

“Time is what we want most, but what we use worst.” –William Penn.

Never is it more true than when it comes to estimating.

Indeed, to most people estimating effort is tightly coupled to time. How long will it take? When will it be ready?

This is futile: time is a moving target and calendar time, in particular, next to impossible to predict.

A better approach is to estimate the size, or complexity, of work, and to derive duration based on velocity.

Agile Estimating

There are three keys to agile estimating:

• Items are estimated relative to each other, rather than absolutely.
• Duration is derived rather than estimated directly.
• Estimating is an ongoing activity, not an isolated task at the beginning of the project.

These points are described in the sections below.

Relative Estimations

Think about painting a house.

If asked “How long does it take to paint this house?” you might start by looking at one room and say “This room will take about one hour to paint.” Then you move on to the next room “…and this one will probably take two hours.” And so on.

When you start to work, it turns out the paint is not as easy to apply as first thought. It will take much longer, and you are forced to do a new estimation for each room.

Now, if you would have started by estimating size instead, comparing the rooms to each other, it might have sounded something like this:

“Let’s say this room is a three.”

“This room is a little bit smaller, let’s say two.”

“Now, this is twice the size of the first room. Let’s call it a five.”

And so on.

You haven’t said anything about how long it will take to paint the house.

Now, when you start to paint and finish the first room in X hours, you can easily derive how long it will take to paint the whole house: simply add up the sizes of all the rooms and multiply by the time it took to paint one unit.

Project Velocity

In a similar fashion as the example above, you can calculate the project velocity by looking at how much work the teams can finish each iteration.

Using the velocity you can predict when all the estimated work will be done.

Estimate What You Know

In traditional project models you estimate all the work upfront, in the planning phase. This might work in a well known and predictable environment. Alas, software projects rarely fit that description.

In fact, the beginning of the project is when you know the least, and as a consequence, the accuracy of the estimations are poor. This is expressed in the cone of uncertainty.

Agile methods acknowledge the difficulty of doing accurate estimations upfront.

While work in the near future is estimated in detail, work further away is only estimated roughly.

User Stories and Epics

In the previous post, I wrote about user stories as one possible type of backlog item. User stories are often estimated using story points. However, other backlog items can also be estimated using story points.

Story points can be pretty much anything. Many people use the Fibonacci series (0, 1, 2, 3, 5, 8, 13, …) while others multiply numbers by two (0, 1, 2, 4, 8, 16).

You can also use T-shirt sizes or something else.

It should be a predefined set, though, and you shouldn’t depart from it.

It’s a good idea to have larger gaps between the numbers as they grow, as it’s more difficult – and less meaningful – to make accurate estimations of larger items.

Planning Poker

Planning poker is one way to quickly estimate backlog items accurately.

When playing planning poker, many teams start with long discussions about the stories.

I don’t think that’s the best approach.

Instead, start by giving a first estimate right off the bat: don’t discuss the story at all. If everyone’s estimate converge the story is probably pretty well understood, and you don’t have to discuss it further there and then.

Remember, once you’ve done the task breakdown (that typically follows estimating stories during sprint planning) you can always go back to the Product Owner and re-negotiate any commitment.

You will find, though, that you seldom have to.

Another benefit of this approach is that team members do a first estimate without being affected by others.

Story Splitting

Sometimes it is necessary to split stories into more manageable sizes. Epics, for example, typically need to be broken down as they are about to be implemented.

Stories can be split in many different ways, but don’t forget about the INVEST mnemonic from the previous post. Some ways to split stories are:

• Across boundaries, for example operational, data and interface boundaries
• By removing cross-cutting concerns such as logging and exception handling
• Into functional and non-functional aspects

When unsure of a technical implementation or when you feel further analysis is needed to correctly estimate a story, consider a spike.

Next time I’ll write about the sprint planning.