Estimating with Story Points

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• A Step toward Agility: Estimating Size, Not Effort
• Estimating Story Points at Acme Media
• Key Points
• Copyright

A Step toward Agility: Estimating Size, Not Effort

One of the main issues with traditional estimation techniques is the fact that team members really don’t believe their project timeline until they’ve completed detailed analysis of the features. They don’t feel comfortable until they’ve completed functional specifications and correlating technical designs. Then, when they complete this work, they’re often surprised and have to notify stakeholders that they can’t make the timeline without a decrease in scope or other project adjustment.

It’s easy to see why stakeholders want you to estimate a delivery date immediately. The project may have a constraint or deadline that must be met, or the project may require funding that needs to be tied to a duration. You may also need to identify when shared employees are needed so you can reserve them. How can you improve the accuracy of your initial estimate without doing weeks or months of detailed feature analysis? The answer is story points.

Using Story Points for Quick Estimation

Story points are a different way to look at estimating features. They aren’t a measure of the time needed to complete a feature but a measurement of a feature’s size relative to other features. This approach is powerful because you may not have enough information to estimate the time to create a feature, but you can immediately begin to compare the sizes of features to each other to determine a relative size (see Figure 14.2).

Figure 14.2 Similar to features in a project, the buildings in a city have various sizes and attributes. Can you look at the buildings and determine how long it took to build each one? Probably not. But you can compare the sizes of the buildings to each other. This is the main premise of story points.

To demonstrate, let’s pretend you’re making passenger cars instead of software. The cars are listed in Table 14.1. Because you’ve never built cars, you don’t know how long it takes to create one, but you can estimate how large a car is compared to other cars. For example, you know a Mini Cooper is probably the smallest car of all. You know that a Camry is a medium-size car, and you know that a Town Car is probably the largest of them all.

You can convert these size assumptions to numbers by using an estimation scale. A popular scale for estimating feature size is the Fibonacci scale, which sums the previous two numbers to derive the next number in the sequence. The sequence looks like this: 1, 2, 3, 5, 8, …. The main benefit of the Fibonacci scale is that enough separation exists between the numbers to prevent the team from squabbling over slight differences. For example, if the scale was 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, team members might debate whether a feature was a 7 or an 8. It’s easier for team members to reach agreement if the scale jumps from 5 to 8.

When you have a list of cars or software features to compare, Mike Cohn suggests that you first identify an item that is a 2 and then an item that is a 5. By selecting a 2, you still have room to list an item as smaller; if you identify a 5, you have room to estimate another feature as larger, and you also have the ability to compare a list item to two other list items (the 2 and the 5).

In the example in Table 14.1, we quickly identified the Civic as a 2 and the Impala as a 5. You can use these two reference points to relatively compare the other cars and estimate their size.

Now that you have size estimates, you may wonder how you can convert them into work estimates. Initially, you can’t convert them. In relation to the first iteration you perform, the story-point estimates won’t help at all. But after you complete the first iteration, you’ll know how many story points you completed, and you can use this number to estimate your story-point capacity for forthcoming iterations. You’ll measure story-point throughput after every iteration going forward and use those historic numbers to determine the average story-point capacity for forthcoming iterations.

Table 14.1 Comparing the relative size of various automobiles

To follow through with our example, let’s say you’ve identified 10 days as the standard iteration length. In those 10 days, you completed the Camry (3), the Prius (2), the Beetle (2), and the Impala (5). You were able to process 12 story points’ worth of features in an iteration. For now, you’ll assume that you can complete 12 story points in iteration 2, and you’ll assign 12 story points’ worth of cars to iteration 2. In effect, you’re saying that your iteration capacity is 12 story points’ worth of features.

When iteration 2 is complete, you’ll see how many story points you put through that iteration. Average that number with 12 from iteration 1, and use the result as your new capacity estimate for iteration 3. You’ll continue this process forever. Over time, your story-point capacity estimates will become more accurate because they’re based on several real production iterations.

Planning Poker

In planning poker, each team member has index cards with 1, 2, 3, 5, and 8 printed on them. One team member (preferably the customer or product owner) kicks off a discussion of a feature, and the whole team asks questions and normalizes on the scope and breadth of the feature. When the conversation is complete, a vote is taken: all team members hold up an index card with their estimate on it. It’s important for everyone to do it at the same time so they aren’t influenced by their peers. If everyone holds up cards with the same number, the estimate is official, and you record it. If you don’t have consensus, you investigate why. Let’s see this in action with an example from Acme Media.

Estimating Story Points at Acme Media

The first thing the Acme Media team needs to do is establish two reference points for all features. They do this by identifying a feature that is 2 story points in size and a feature that is 5 story points in size. After a review of the features, the Acme team concludes that Search by category is 2 story points and Receive help online is 5 story points; see Table 14.2. Acme Media’s team then reviews all the features against Search by category and Receive help online to determine if the other features are the same size, smaller, or larger. As additional features are estimated, they’re also used as reference points to compare the non-estimated features.

After the Acme Media team completes the planning-poker exercise, they have a prioritized, estimated product backlog. Now the question becomes, how many features can they complete within the project timeline?

Table 14.2 - Story points let you evaluate capacity and throughput without performing detailed task analysis in advance.

Key Points

Key points from this chapter are as follows:

• Software estimates are prone to high error rates when they’re created early in a project. Based on this premise, you should time-box early estimation exercises, realizing that there are diminishing returns after a day or two of estimating.

• Software development is unique, but you can still identify trends that let you estimate your project timeline.

• Many teams limit software estimation to managers, leads, or other experts on the team. The accuracy of your estimates will improve if you involve the whole team in the process. In addition, you’ll increase team buy-in and support of the estimates.

• You can reduce the time needed to obtain initial estimates by using the storypoint estimation technique. You may obtain better estimates by spending weeks analyzing features, but story points allow you to quickly transition to a working iteration and pursue delivery of critical features immediately.

• The story-point technique lets you outline your overall release schedule sooner and update stakeholders on the ability to meet pre-established deadlines.

• Planning poker can add fun to your estimation process while ensuring independent estimating by team members.

Previous article: Agile Estimation Techniques and Process

Continue on to the next article: Release Planning: Envisioning the Overall Schedule

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.