Agile Estimation: a quick overview
Guest blog by Leon Tranter
Estimation is a popular and controversial topic in the field of Agile software development. There are some strong opinions on how it should be done, and whether it should be done at all! This article will explain the options and techniques for estimation in Agile.
Story point estimation
This is the most popular method of estimation in the Agile community. The idea is that a team gets together before some user stories go into a sprint and come up with estimates on each story, in the form of story points.
It might seem weird, but story points are a relative description of a story’s size. So a two point story is twice the size of a one point story. There is no other objective standard that you can relate a story point against (you can’t really turn them into people or hours or days, though sometimes people try).
Story points are usually assigned on a Fibonacci Sequence scale (1,2,3,5,8,13,21).
The estimation itself is usually done by a technique called Planning Poker. Each participant has a set of cards where each one is a Fibonacci number. The team discusses a user story in the backlog, then each person secretly chooses a planning poker card. When everyone has chosen, all players reveal their cards simultaneously. This prevents a person’s choices from affecting other people’s choices. If there is a difference in estimates, the team discusses until they reach a consensus.
Putting estimates on all the stories in a backlog can give you a precise view of the remaining scope and when certain features can be delivered. But it can be time-consuming and wasteful, especially for backlogs with many stories that won’t get built for a while (or ever).
This is a simpler and more informal system than story point estimation. Some teams simply apply a “t-shirt size” estimate – Small, Medium, Large or Extra-Large. Because of the reduced granularity of the sizes, this is often done at a feature rather than story level. The t-shirt sizes are often mapped back to sprint lengths. So the team might decide on some baselines – a small is a feature that might take half a sprint, a Medium is a one sprint feature, a Large is two sprints and an extra large is three or more. Rather than planning poker, the estimation for this method is usually more casual, and just involves a conversation by the team.
Some people combine T-shirt sizing with story point estimates: they estimate features with t-shirt sizing, and then break the features into stories and do point estimation on them. I actually think t-shirt sizing is quite effective, especially since it is very quick (compared to planning poker, which can take hours).
This is a recent radical movement that attempts to get away with estimates altogether. It was started by Woody Zuill and Vasco Duarte. This movement believes that estimation is a form of waste (does not add value to customers), that estimates are frequently wrong, and that we should therefore stop doing it. This doesn’t mean getting rid of forecasting altogether. Teams can use techniques such as story mapping and cost flattening (cutting up stories into the same or similar size) to do release planning. If a team knows they can deliver on average six stories per sprint, and they have a backlog of 30 stories, they can predict that it will take them five sprints to deliver those stories. And that number can be determined without any actual estimation. This philosophy has some quite passionate advocates both for and against (search on twitter for the #noestimates hashtag and you’ll see what I mean!).
- Visit the author’s website Extreme Uncertainty
- Share your comments in the Comments section below
- Or if you liked this piece, kindly share it on your favorite social platform