Story points are used, typically in Scrum project management, as a way of estimating development effort for features or requirements. Traditional project managers are so used to estimates being time-based that they may have difficulty grasping the concept of story points, or "relative sizing." However, once this concept is mastered, project managers realize the advantages of using story points and know when to use the technique appropriately.
What are story points?
Story points are an arbitrary measure used to indicate the size of something, relative to something similar. In Agile software development, story points are used to measure stories, that is, the features or requirements of the application.
Using story points rather than time to estimate allows development teams to be less precise. They may not know exactly how long a particular feature will take to develop, but they understand that this feature is more complex than others, so as a result assign it more story points. Many teams use the Fibonacci numbering system in assigning story points because the bigger the story gets, the more difficult it becomes to give an accurate estimate. Using a Fibonacci sequence allows teams to recognize the uncertainty that comes with estimating large and complex stories.
What is velocity?
Agile teams determine their velocity by tracking how many story points they are able to complete during each iteration. In the article, "Estimation approaches in Agile development," Chris McMahon explains that, "Over time, these values become quite consistent, and Agile teams using this way of estimating become knowledgeable and reliable as to how many points they can achieve for each iteration."
Once a team has gelled, members become very familiar with using story points to estimate. And over time, they have a clear sense of what they can accomplish during each iteration. Because the stories in the backlog are also assigned story points, product owners can prioritize the features that will give them the best bang for their story point buck.
Some disadvantages of using story points
In Scrum project management, story points can be misleading when used as a measure of productivity. Different teams use story points in different ways. They are a relative measure, which means Team A might assign a story 5 points, while Team B gives it 10 points. In that case, Team B's velocity appears to be twice as fast as Team A's. But in reality, Team B is simply using more story points for the same amount of work. Unless all teams are calibrated, confusion can result.
Once a team has achieved a certain velocity, members may be tempted to cut corners and sacrifice quality in order to maintain that velocity.
Advantages of using story points
Some teams use T-shirt sizes -- small, medium or large -- to estimate the amount of work a story requires.
Though not appropriate for all situations, story points allow for relative rather than absolute sizing of estimates. This is especially helpful when there are unknowns.
When using story points and tracking velocity over a period of time, a team becomes better at predicting the amount of work that it can accomplish.
Some teams use T-shirt sizes -- small, medium or large -- to estimate the amount of work a story requires. Like story points, T-shirt sizes are a relative measure. But I recommend using story points, because teams can apply them to planning purposes and use them to determine velocity.
When to use story points
Expert Mike Cohn, author of Agile Estimating and Planning, advises teams to use story points for estimating the backlog, but not for sprint planning. He believes story points are best used for long-term, rather than short-term, planning.
In his upcoming presentation, "Advanced Discussion of StoryPoints for Project Management," planned for the Scrum Alliance event in Las Vegas in May, Scrum trainer Dan Rawsthorne is expected to teach advanced story points techniques and how project managers can use them for budgeting and metrics.
As project managers become familiar with using story points as a means of estimating, they will also find ways to apply these concepts outside of Scrum development teams.
This was first published in April 2013