Share via

Motley says: “Story points? Is that the new name for sports highlights?”

  • Article

Summary

 

Motley: Story points provide no value over using plain units of time for estimates. Who would want to use an abstract unitless measurement for estimates anyway? Makes no sense.

 

Maven: Story points are a unitless measure for the relative amount of work involved in completing a work item. Story points are an abstract concept that allows you to determine iteration velocity without being biased by time measurements.

______________________________

 

[Context: Motley has been asked to provide estimates for his team's work items using a new type of "unit" that he is not familiar. He is confused by the request, as he is used to providing estimates in units of time, like hours.]

 

Motley: With this new project coming up, I was asked by the management team to provide estimates in something called "story points". Is that a new name for sports highlights?

 

Maven: Presumably you have never used "story points" for estimates?

 

Motley: No. What ever happened to good old fashioned "hours"? The team wants to be agile, so they are using this new thing. From what I understand, it boils down to 1 story point = 1 day of work anyway.

 

Maven: If that's the case, then why bother with story points? You may as well just use "days" as the unit of your estimates.

 

Motley: Thanks, Mave! It's nice to have you agree with me for a change!

 

Maven: But let's get back to story points. What the team is mandating is a complete misuse of story points. The idea comes from agile software development and is used by teams that are often inaccurate with their estimates. A story point is a unitless measure that represents the amount of effort to implement a work item, which is typically used with the agile concept of a "user story". We can talk about "user stories" later.

 

Motley: I'll push your question back to you - why bother? Why not deal in something with units that is more concrete?

 

Maven: It helps get you out of the mind frame that estimates need to be in units of time. Other valid ways to estimate are by complexity, effort (the classical way) or size, how much risk or unknown project variance there is, or some other means that is pertinent to your team. By getting away from time, it allows you to quit thinking about buffers and time effort and instead combine other types of measures. Approaching estimates from different axes can yield more accurate results.

 

Motley: Weird. So if I say that a task is a "5", what the heck does that mean?

 

Maven: Perhaps the biggest problem with story points is getting started. Until you have some development iterations under your belt using story points, it's difficult to predict exactly how many points a task will take. The important thing to remember is that story points convey relative measurements and not absolute.

 

Motley: Relative vs. absolute - what are you talking about, Mave?

 

Maven: With hours, you give an estimate in absolute terms. The number is, for example, the number of ideal hours it will take to complete the work item. That is an absolute number that can be assigned mutually exclusive of all other work items. Of course, for scheduling you typically have to apply some "fudge factors" like accounting for distractions, such as meetings and working with other teams on unrelated tasks, which can get more complicated. In the end, you may come up with calendar time representing the length of the task.

 

Motley: But you digress - back to story points please.

 

Maven: Ah, yes. Story points are generally more relative. One technique is to list off the work items you want to achieve in a given iteration (say, 2 weeks). Then, using whatever metric you want, such as complexity, assign a number to each work item relative to the others. For example, if I have work items A, B, and C, and C is larger and more complex than A and B and as a result will take longer, then I might assign values of A=3, B=3, and C=8.

 

Motley: What good does that do? Those numbers are meaningless!

 

Maven: At the outset they may seem meaningless, but after a couple of iterations, you'll start to get an idea of how many story points worth of work you can accomplish in a given timeframe, and you'll get much better at predicting how much work you can get done, which is the point of all this estimation stuff in the first place.

 

Motley: Any guidance on what kinds of numbers should be used? Why did you pick 3's and 8's, for example?

 

Maven: The numbers are somewhat arbitrary, but if you fold in an estimation technique like Planning Poker, you end up with a series like 1, 2, 4, 8, … or the Fibonacci sequence like 1, 2, 3, 5, 8, 13, … You could also use general decimal numbers, but the estimates are rarely that granular. Using a sequence like this plays well with Planning Poker.

 

Motley: Still seems kind of ridiculous, but we could give it a go. How do we get started? How do we determine how many story points we can deliver in an iteration? I know - we could look at Marvin's team and see what they delivered and use that as our basis. I think they started using story points for estimates last iteration.

 

Maven: I would not recommend looking at Marvin's results. Story points are an arbitrary measure whose exact definition is up to the team. By being consistent with estimation within the team, you can get a consistent idea from iteration to iteration how much work you can deliver. Marvin's team, however, would have their own definition and just because they deliver 40 story point does not mean your team will. You may deliver 90, but still get the same amount of work done. The idea is to measure your team's velocity and get an idea of how much you can deliver per iteration given your story point definition.

 

Motley: Still not sure I like this. What really is the benefit over hours?

 

Maven: Story points get you to think more abstractly than just how many hours work items take. Remember: it is okay to use hours if you decide to do that in the end, but don't call them story points. They are different. You can use hours to compute a load factor and make your estimates better per our Scrum conversations and that is fine. Just pick a model and go with it.

 

Motley: Ok, we'll give it a shot. Sounds tough to get started but we can try it.

 

Maven: It IS tough to get started because you don't have a definition for the points yet. Just stack rank the work items and mark a fairly well-understood work item of mid-size/mid-complexity/mid-effort/etc. work item as something like 5, and then compare all other work items to that one assigning higher or lower.

______________________________

 

Maven's Pointer: Sometimes the abstraction of story points is just not worth the pain it will cause a team, particularly when they are just getting started with Scrum. Stick with hours in that case, but don't fool yourself in calling them story points with a direct mapping back to hours or days. That is even more abstract. If you do use hours, remember that no one is 100% on task every work day (e.g. in an 8 hour day, you will likely get 4-6 hours of on-task work done). Compute a load factor to create realistic calendar time. With story points this "buffer" is basically built in, with the assumption that you generally have similar distractions from iteration to iteration.

 

Maven's Resources: