Articles and Posts Tagged “story-points”

The Problems with Estimating Business Value

I occasionally see teams that want to put an estimate of "business value" on each user story. They usually do this for either or both of two reasons:

  1. to be able to measure the amount of "business value" delivered to the organization, usually graphing this sprint by sprint
  2. to be able to prioritize user stories by comparing the business value of each story to its cost…

    Continue Reading

How Do Story Points Relate to Hours?

I'm often asked about the relationship between story points and hours. People who ask are usually looking for me to say something like "one story point = 8.3 hours." Well, that just isn't the case (especially since I made up 8.3 hours). Let's see what the real relationship is between the agile point system vs. hours system. Suppose for some reason you have tracked how long…

Continue Reading

Is It a Good Idea to Establish a Common Baseline for Story Points?

In a previous post, I wrote about how to establish a common baseline for story points across relatively large teams (a few hundred developers). In this post I want to consider whether doing so is a good idea. The need for a common baseline to story points usually arises from the reasonable desire to know how big the entire project is. To know that, we must know the size of…

Continue Reading

Establishing a Common Baseline for Story Points

A common criticism of story points is that the meaning of a story point will differ among teams. In this post I want to describe how can we establish a common definition of a story point across multiple teams within an organization.

The best way I've found to do this is to bring a broad group of individuals representing various teams together and have them estimate a dozen…

Continue Reading

Should Companies Measure Productivity in Story Points / Ideal Days?

Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point--when trying to decide between calling something “two points” or “three points” it is clear they will round up if they are being evaluated on productivity as measured by the number of story points (or ideal days) finished per…

Continue Reading

Why I Don’t Use Story Points for Sprint Planning

As described in Agile Estimating and Planning, I'm a huge fan of using story points for estimating the product backlog. However, I also recommend estimating the sprint backlog in hours rather than in points. Why this seeming contradiction? I've previously blogged on the reasons why I recommend using different estimation units (points and hours) for the different backlogs.…

Continue Reading

To Re-estimate or not; that is the question

Should a team that is estimating in story points ever re-estimate? This is a question I'm commonly asked and would like to address here. Most people have a natural feeling that re-estimating is somehow wrong but they can't quite say why. I'll encourage those individuals to stick to their hunches, and hopefully I can provide of the reasoning that supports your natural…

Continue Reading

Sprint and release planning should be in different units

A common source of confusion on agile teams occurs when the sprint ("iteration") backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units. In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out. In…

Continue Reading