This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: Bliki: StoryPoint
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
Story points are a common name for sizing stories in agile
projects. Combined with XpVelocity they provide a
technique to aid planning by providing a forecast of when stories
can be completed.
When estimating work, a common approach is to estimate in terms
staff-hours, such as a programmer saying "this will take me two days
to do". Many people in the early days of agile, especially those in
the ExtremeProgramming community, found that teams struggled to
come up with useful estimates using this approach, even when they
applied an approach of IdealTime. We found the
most effective way to estimate was to size stories relative to each
other, and then use past experience to determine how much could be
done in an iteration. [1]
To determine the points for a story, we compare rough relative
sizes. If we are estimating the "fibble the foobar" story, we look
for a story of similar size that we've already estimated. We sense
it's about the same size as "flipping the synergy bit". Then we look
at the story point score for "flipping the synergy bit" and
score the "fibble the foobar" the same amount.
A team using story points uses a small range of story points to
work with. Common examples might be 1,2,4,8 or 1,2,3,5,8 [2].
Often the top number in the series represents "too big" and should
be broken down further. [3]
Allocating story points should be rapid activity. Discussion
should only break out when people have contrasting views on the
estimate, in which case its useful to have a discussion as it
usually means that something about the story isn't clear. Using a
ThrownEstimate is a good technique to move things along
quickly.
Some teams don't like using story points, preferring instead to
use StoryCounting. I don't have a preference between the
two - both seem to work equally well so it's up to the team to try
out and go with whichever suits them best.
Further Reading
The ThoughtWorks ebook on estimation provides includes a good
Q&A on story points. Kent and I discussed them in more depth
in the tasteful green book. Most
books that talk about planning and estimation in an agile context
discuss story points in more detail.
Notes
1:
"Story Points" is the most common name that I hear these days,
but various terms have been used over the years, often with
whimsical names that emphasized their arbitrary nature. I
particularly like Joseph Pelrine's gummi bears and
Josh Kerievsky's: NUTs (Nebulous Units of Time).
2:
This is a Fibonacci sequence
3:
Using the top number as too big is saying that a story
sized at '8' really means '8 or more'. If you do this beware of
using this top number when making forecasts of things like
completion time, since '8' can turn into all sorts of numbers when
it finally gets broken down. It's usually better to explicitly say
its too big to be estimated rather than use a false marker number.
Previous Topic
