Story Points
Story points are units used to estimate software cost with relative units of size. These units are a measurement of complexity or size of a requirement compared to the duration to complete a requirement. The actual units of time can be assigned afterwards.
Description
No project can go very long before someone starts asking "When will you be done?" The best approach for estimating stories would be one that:
- allows us to change our mind whenever we have new information about a story
- works for both epics and smaller stories
- doesn't take a lot of time
- provides useful information about our progress and the work remaining
- is tolerant of imprecision in the estimates
- can be used to plan releases
An approach that satisfies each of these goals is to estimate in story points. A nice feature of story points is that each team defines them as they see fit. One team may decide to define a story point as an ideal day of work (that is, a day without any interruptions whatsoever—no meetings, no email, no phone calls, and so on). Another team may define a story point as an ideal week of work.
The technique is similar to fuzzy logic, but there are some interesting and useful variations that make story points worth discussing separately.
Since story estimates are owned by the team it is important to have a reasonable portion of the team involved in coming up with the estimates. If the team is large (perhaps seven or more), not every developer needs to be involved, but generally the more developers involved the better. The customer participates while the programmers estimate, but she isn't allowed to contribute her personal estimates or editorialize when she hears an estimate she disapproves of. The goal is for the estimators to converge on a single estimate that can be used for the story. It rarely takes more than three rounds, but continue the process as long as estimates are moving closer together.
It is important to notice that:
- Estimate stories in story points, which are relative estimates of the complexity, effort or duration of a story.
- Estimating stories needs to be done by the team, and the estimates are owned by the team rather than individuals.
- Triangulate an estimate by comparing it to other estimates.
- Whether or not a team programs in pairs has no impact on story point estimates. Pair programming affects the team's velocity, not their estimates.
How To
When using story points, the team reviews the list of stories (or requirements or features) it is considering building\cite{McConnel_BlackArt05}. When the story cards are finished, gather together the customer and the developers who will participate in creating the estimates. Bring along the prepared story cards and a stack of additional blank note cards. Distribute a handful of blank cards to each participant. The customer selects a story at random from the collection and reads it to the developers. The developers ask as many questions as they need and the customer answers them to the best of her ability. If she doesn't know the answer, she takes a guess or asks the team to defer estimating that story.When there are no more questions about the story, each developer writes an estimate on a card.At this stage of their use, the story points are not terribly useful because they are a unitless measure—they don't translate into any specific number of lines of code, number of staff days, or calendar time. The critical idea behind story points is that the team has estimated all the stories at the same time, using the same scale, and in a way that is substantially free from bias.
Stories are normally assigned to a numeric value from one of the scales shown in the following table.
| Story Point Scale | Specific Points on the Scale |
|---|---|
| Power of 2 | 1, 2, 4, 8, 16 |
| Fibonacci sequence | 1, 2, 3, 5, 8, 13 |
When everyone has finished writing an estimate, the estimators turn over their cards or hold them up so everyone can see them. It is very likely at this point that the estimates will differ significantly. This is actually good news. If estimates differ, the high and low estimators explain their estimates.Other estimators will undoubtedly have opinions on whatever reasons the high and low estimators were at the extremes. The customer clarifies issues as they come up. A note or two may be jotted on the story card. Perhaps a new story or two is written.
After the group has discussed the story, the developers again write their estimates on cards. When everyone has written a revised estimate, the cards are again displayed. In many cases the estimates will already converge by the second round. But, if they have not, repeat the process of having the high and low estimators explain the thinking behind their estimates. The goal is for the estimators to converge on a single estimate that can be used for the story.
After the first few estimates have been made, it becomes possible (and necessary) to triangulate the estimates. Triangulating an estimate refers to estimating a story based on its relationship to one or more other stories.\cite{Cohn_Agile04}
After the iteration has been completed, the team will be in a position to have some real estimation capability. The team can look at how many story points it delivered, how much effort it expended, and how much calendar time elapsed, and it can then make a preliminary calibration of how story points translate to effort and calendar time. This is often called velocity.