What is Story Point? Are they Necessary?

Posted by Mark Levison on Mar 05, 2010

Sections

Process & Practices

Topics

Agile Techniques ,

Agile

Tags

Planning

Michael de la Maza asks the question what exactly is a Story Point? He went looking for an answer and found many: “Story points represent nebulous units of time.” or “Story point is a random measure used by Scrum teams. This is used to measure the effort required to implement a story.” or “...a story point estimate is an amalgamation of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on.” [Mike Cohn, Agile Estimation and Planning].

Michael goes on to document how they’re used: “Truth be told velocity really is a productivity
measure...” vs. “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...”

With all this confusion Michael wonders what are story points? How do you introduce to people new to Agile and Scrum.

Dan Rawsthorne, replies:

1.  A Team usually WANTS Velocity to be a productivity metric in order to
   talk to the outside world about "how fast" it is.
2. Velocity is only a meaningful metric if Story Points remain constant over the life of a project. To do that the team must use one or two standard stories that remain the same over the life of the project.
3. If “the baseline story is not only consistent within a Team, but across Teams, then Velocity not only measures productivity, but can also be meaningfully compared across
   Teams, and is additive within an organization” BTW this reporter strongly argues against this practice: “Misuse of Velocity in Agile Projects”
4. Once the team has stable Story Points then they can be used in future release planning sessions to get a rough estimate of the work they will successfully complete.

Ron Jeffries, replies: “Story points are a relative measure of the time needed to implement a story, borrowed from XP (as is the notion of story). They are intended to be a way of estimating difficulty without committing to a specific time duration, so that variances in team size or time on task do not affect them” and “Yes, they measure size and complexity. The terms "size" and "complexity" are used to mean "how hard is this in terms of how long it'll take us to do it".”. Finally Ron notes that he (and other experts) no longer see story points as necessary.

Previously on InfoQ: Story Points vs Hours

1. Back to top

   I don't think it was ever intended to be a productivity metric...

   by Ronald Miura

   ... but for some reason, people always try to turn anything represented by a number into metrics.
   
   Wasn't it just an estimation of how many story points a team can accomplish in an iteration? Not to measure productivity, but to help the product owner to know how many stories she can pick for the iteration?
   
   1. Teams that WANT it to be a productivity metric to brag about it just don't get it.
   
   2. If the team have to try so hard to make 'Story Points [to] remain constant over the life of a project', it will lose its subjective, experience-based nature, and its reason to exist. <sarcasm>If you want a 'stable' metric, just use Function Points (which is full of rules about how to measure things).</sarcasm>
   
   3. Again, to get this consistency, one must dictate strict rules to 'level' teams' estimations. <sarcasm>Just use Function Points instead.</sarcasm>
   
   4. Well... yes.
   
   People, stop this metrics fetish, please!

   Reply

2. Back to top

   Couple things...

   by James Brechtel

   Why are these contradictory?
   
   “Truth be told velocity really is a productivity
   measure...” vs. “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...”
   
   These can both be true. Story points measure work. Velocity is how much work you get done in a certain amount of time. The two quotes aren't opposing.
   
   Also, in reply to #2, ideally story points would remain constant for the life of the project but in practice this is difficult because we all have different perceptions. Consensus based estimation techniques allow the team to come to a mutual understanding and allow the notion of a point to stabilize over time. One reason is that when your estimate is an outlier you're often asked to justify your position. This helps others to see it from your perspective and you from theirs (via rebuttals).

   Reply

3. Back to top

   What is a reference story??

   by J Nasstrom

   It is suggested that one or two standard stories are to be used as a reference to fix the "size" of a story point.
   
   This is questionable. As the story becomes familiar and solutions are learned, the story should use less points. Just like doing the same job a second time could be done in about half the time, thanks to learning and experience.
   
   Also, two teams with different skills profiles would also judge the standard stories differently. A team with front-end experts can deliver front-end related stories faster that a team with back-end experts, and the other way around. It would be difficult to tell which team is most efficient.

   Reply

4. Back to top

   Why bother estimating?

   by Assaf Stone

   Beyond that, I believe that estimation is a futile exercise except when needed to bill a customer. If work is done by priority, and as soon as possible, then estimation only gets in the way of getting the work done. It boils down to trust that the team is doing what it should be doing.

   Reply

5. Back to top

   Why use reference stories?

   by Assaf Stone

   If the first story is the reference story, and the second is uses the first as a reference, then the third story may use either story as a reference, due to associative relationships. This remains true all the way, doesn't it?

   Reply

• Older >