Agile basics: estimating the unknown

One of the most powerful concepts that the agile and scrum methodologists brought to software development is relative estimation.

In a non-agile world, development teams are asked how long a given piece of work will take to do. For anything more involved than a simple fix, the team will basically have to guess how many hours or days they need for that work.

I’m not using the word “guess” lightly here. If programmers were bricklayers, and every project was to build a wall of certain dimensions, it would be easy enough to estimate the amount of time needed. The bricklayers have made plenty of walls before; they’ll have a very accurate sense of how long this next wall will take.

build-your-wall

In the world of software, however, one project will vary widely from another. In a very real sense, the team can’t know with precision how long the project will take, because they’ve never worked on this particular project before.

Here’s where agile comes to the rescue. Instead of making absolute estimates (“This feature will take 3.5 days”), the team makes relative estimates (“This feature looks like it’s twice as difficult as that feature”).

Ken Rubin of Innolution has a great analogy to illustrate this point. Say you’re on a boat coming into a bay, and you can see in the distance various islands in front of you. The captain asks you how close the nearest one is. What do you say?

Bay_of_Islands_Aerial_View_to_Cape_Brett

The captain is asking you for an absolute estimate. He wants an answer like “One mile away.” Now, when we make absolute estimates of distances, we tend to do a bad job of it. But if the captain asks you whether this island over here or that one over there is closer to us, we’re much more likely to be able to answer that question with confidence. After all, “[m]ost people are quite comfortable expressing distances as a function of other distances.”

Agile recognizes this truth of human cognition, and embraces it by asking teams to compare the “stories” (i.e. items) on a product backlog to each other, and identify which ones are the easiest, which ones are moderately difficult, and so on, up to the hardest ones.

measuring-tape

If we then assign “points” to these different complexities, we can start making longer-term estimates. For example:

Let’s say that for our first two-week “sprint” (i.e. development cycle), the team agrees to do three easy stories of one point each, three moderate stories of three points each, and three hard stories of eight points each. That gives us a total of 36 points.

Now let’s say that after two weeks, the team has finished all of their stories, except for one of the hard ones. We’ve therefore earned 36 – 8 = 24 points. This gives us our first real datapoint about the team: in this first sprint, they achieved 24 points in two weeks. We now have an initial velocity (24 points per sprint).

The more sprints we execute, the more datapoints we get. And the more datapoints we get, the more we’ll see a pattern or trend emerge. Perhaps we’ll find that the team’s velocity, on average, is 26.5 points per sprint. That, in turn, will allow us to figure out how many more sprints they need to finish what’s on our backlog.

Of course, before we can get this estimate, the team first needs to do its “backlog-grooming” and assign relative point estimates to each of the remaining stories.

Let’s say that our team has groomed the backlog and assigned a grand total of 158 points to the remaining stories. At an average of 26.5 points per sprint, this simply means we’ll need another 159 / 26.5 = 5.9 sprints — call it 6 sprints. And since our sprints are two weeks long, we still need 12 weeks.

Thanks to our collecting real data about the team’s performance through these relative point estimates, we have a much more reliable estimate than if we’d just made absolute time estimates for all the stories on the backlog and then summed them all up.

bulls-eye

A few closing caveats:

1) Bootstrapping is required. Until the team finishes its first sprint, you won’t be able to project their velocity with any accuracy. As Sherlock Holmes said: “Data, data, data!”

2) Stability is required. As much as possible, the team’s composition needs to stay the same. Estimating and working on stories are a team effort. The team will develop its own norms for what it considers to be a hard story or an easy one. But the more the team changes, with people coming and going, the more it becomes an apples-to-oranges exercise to compare how this sprint’s team did compared to last sprint’s.

Granted, people do have to leave the team for any number of reasons: promotion, sick leave, a request for a transfer, you name it. These things can’t be helped. All the same, we have to keep in mind that if the team has different people on it now, it’s effectively a different team, and so the team’s previous velocities will only be a rough guide at best to how fast this new team will go. We effectively have to collect new data about this new team.

3) Points are not slang for “hours”. It’s natural for newcomers to agile to think there’s some kind of game going on here, and that for some unknown reason we’ve decided to rename hours as “points”. Therefore, if something takes three hours, you should give it three points. Or six. Or whatever.

That is not how you should think about points! It’s OK to say something like “point values less than 3 mean ‘easy'”, but it’s not OK to say “point values less than 3 mean ‘this will take only half a day'”. The whole purpose of point estimates is not to make guesses at how much time is required for a story, but how hard it is compared to the other stories. Agile recognizes that we as humans are bad at estimating timelines. Therefore, in agile, we deliberately remove time from the estimation exercise, and focus on complexity instead.

Leave a Reply

Your email address will not be published.