Estimating User Stories in Story Points

Story Points are a numeric value used to estimate the effort required to complete each User Story. So, why not just estimate in hours?

A lumberjack needs to cut a tree down (with an axe). His supervisor asks him for an estimate in hours of how long it will take to complete.

The lumberjack needs time to answer this question. The diameter of the tree is 24 inches, which is an area of 452 square inches. The lumberjack believes he can cut 20 square inches per hour, and every 100 square inches he needs to sharpen the axe, which takes 30 minutes.

Adding all of this up, he comes to 24.5 hours. The lumberjack works eight hour shifts, but knows that he has to stop periodically to hydrate and other non-work tasks, so thinks he actually chops trees 7 hours per day.

Thus, he gives his supervisor an estimate of 3.5 days.

Unfortunately, estimates are actually commitments to supervisors. So, when the supervisor comes back 3.5 days later and the tree is only halfway cut, he’s unhappy with the lumberjack.

So what happened?

Well, the lumberjack hadn’t actually seen the tree when he gave the estimate. He’s been chopping down Pine trees, but it turns out that this tree is an Oak. The wood is far harder – 3x harder, in fact. Had the lumberjack known, he would have based an estimate 10 square inches per hour, and a need to sharpen the axe every 30 square inches.

The actual time to bring the tree down? The lumberjack would need 46 hours or 6.6 days.

The result is that the business is behind schedule, the lumberjack feels like he failed, and the supervisor is frustrated. Nobody wins.

The Story Point is an arbitrary numeric value used to size the effort to complete chop the tree down, or complete a User Story in the case of software. Instead of having to spend time breaking each User Story down into subtasks and trying to guess how much time each will take, developers and testers size each User Story based on past experience. This method of estimation is comparative.

By eliminating the need to estimate in time, individuals feel far less pressure to be accurate for the simple reason that the relationship between a Story Point and time is abstract. Although there’s typically a correlation, that correlation is not exact. The reduction in pressure to be accurate also results in estimation happening far faster than with time-based estimates. If a team has 10 User Stories planned for a sprint, estimating in time could take a half day. Estimating in Story Points takes minutes.

Story Points estimates are also created by the team, not individuals. There are virtually no User Stories – at least not at CodeStringers – that can be completed by a single person or job function. At a minimum, one software developer and one quality assurance engineer would work on the User Story. Thus, no one individual feels responsible for the accuracy – or inaccuracy – of the estimate.

Comparative estimation is exactly what it sounds like. The person (or people) estimating simply compare what they need to do to similar things they’ve done in the past.

Continuing the tree cutting analogy, the lumberjack might ask the supervisor for some clarification prior to estimating. For instance, an experienced lumberjack would know to ask what type of tree he’s being asked to cut down. And if he doesn’t know how hard that tree is, he would look it up on the Janka scale (a numeric value of the hardness of wood species).

So, let’s say that the tree that the lumberjack needs to cut down is a Dogwood and has a diameter of one foot. Dogwood’s Janka hardness is 2,150 pounds. The lumberjack has a ton of experience chopping down Pine trees, specifically Eastern White Pine, which has a Janka hardness of 380 pounds.

That makes the Dogwood 566 percent harder than Pine. The lumberjack considers his history and thinks that he can cut down 50 Pine trees with a one foot diameter in five days (the length of the Sprint for this project). So, he assigns a Story Point value of 1 to the task of cutting down a one-foot diameter Pine tree and his velocity is 50 Story Points. He knows that cutting down Dogwoods is going to take nearly 6 times the effort.

Like most… lumbering companies… they use Fibonacci numbers for Story Point values.

Since the Pine tree is one Story Point, the Dogwood is going to be either five or eight Story Points. He communicates the range to the supervisor (the Scrum Master in Scrum vernacular), but they agree on eight Story Points to be conservative.

Since the lumberjack’s (development team’s) velocity is 50 Story Points, he and the supervisor (Scrum Master) believe they can cut down a minimum of six Dogwood trees in one week (Sprint) and a maximum of 10. The agree to load the next Sprint Backlog with nine Dogwood trees (User Stories), which they also agree is a stretch goal.

But Sprints should be planned with stretch goals. That’s why they aren’t called “Jogs”.

Through this process of estimation, neither the lumberjack (the Team) or the supervisor (Scrum Master) feel anxiety or a sense of personal vulnerability. And they worked together – they collaborated – versus negotiating a contract between each other. And the organization has predictability.

Even if the lumberjack only chops down six trees in the next sprint, missing the goal by a third, he and the supervisor learn together so they can improve future estimates. And they learned quickly… in one week they honed estimation to be more accurate.

If they know that the entire project means chopping down 200 Dog Wood trees, they can roughly estimate that completing the project will take a maximum of 34 sprints (200 trees / 6 trees per sprint). And if they’re successful in increasing velocity – and virtually every development team does over the first five to 10 sprints in a new project – they could complete as fast as 20 sprints.

And with each sprint they complete, they can re-calculate using the same math equation as above to narrow down the project completion date to provide an accurate date to the company and to its customers.

In software it’s both more complicated and easier than it is for the lumberjack. Although software teams usually have a few inexperienced people, they also have experienced people – software developers and quality assurance engineers. Experienced people have built a lot of features in the past, both with their current team and previous teams.

Per the illustration above, the process simply invoves the team comparing the difficulty and effort to build each User Story in the Sprint Backlog to features built in the past. If they believe a given planned User Story is larger than a completed User Story that was three Story Points and smaller than one that was eight Story Points, the estimate for this User Story is five Story Points.

Move onto the next User Story to estimate.

Velocity is the measurement of the average number of Story Points a development team has completed in prior Sprints. It’s that simple.

New development projects typically see Velocity increase significantly over the first five to 10 Sprints. On the MasterControl “RapidOnboarder” project, the CodeStringers development team completed 56 Story Points in the first Sprint of the first release/version, but by Sprint 10, the Velocity was greater than 350 Story Points.

Planning each sprint is a matter of selecting the highest priority User Stories from the Product Backlog and ensuring that the cumulative Story Points in the Sprint Backlog meets or exceeds the project Velocity. Ideally, each Sprint is “loaded” with slightly more than the Velocity, creating stretch goals for the team and encouraging them to “Sprint” rather than “Jog”.