What's the best explanation of what Story Points are?

Question

We're starting to use Story Points here for our Agile development but I find it hard to explain and also can't find any definitive answer to what they are. The best thing I can do is point to other sites (like this one) and give some vague generalization of what they are. I'm looking for a good explanation with some examples of use that would be helpful for others to use. Are there any good resources for explaining story points?

Answer 1

This may help as a starter: Mike Cohn on story points. But this one is far better: Agile Development Teams: Scope and Scale with Mike Cohn

Mike's solution to software estimation metrics is simple and effective. Biological facts:

• Human brain is just unable to estimate in time correctly. Especially if more than few hours.
• This is greatly amplified by the amount of uncertainties in software developer, psychological pressures from management (when you estimate, you commit...) and difference in skills in the team.
• However, we are pretty good at comparing stuff. We are quite accurate there.

The idea is to take one reference user story, then give it an arbitrary number of (story) points, then other stories will get points related to that reference.

If your reference story is 100 points, and another story is three times bigger, then it will be 300 points.

To convert story points into time for your planning, you have to know your velocity.

To get an accurate velocity, you must do few iterations and calculate how much points your team completed in a given amount of time.

It works.

Answer 2

I agree with everything @Pierre 303: said above: (apart from the 100 reference point).

The only thing I would like to add (emphasis) is that we are not good at estimating tasks. We can estimate tasks relative to other tasks as long as they are roughly of the same size. The larger the difference between the tasks the worse we get.

Thus I disagree with using a starting point of 100.

Its not as if you will estimate the next task as 42% of the reference task. It is either the same half the work double the work triple the work etc.

Our team uses Planing Poker: In this we have a reference task of 2 story points. We then use the Fibonacci series to estimate tasks: 1,2,3,5,8,13,21,Huge,? relative to the reference task (Rather than the Fibonacci I have seen other teams use powers of 2. 1,2,4,8,16,32,Huge,?) I have seen other teams use (small(1), medium(2), large(3), XLarge(4) when they computed velocity it still worked.).

The point is that as the size of the task increases relative to the reference task we become less able to accurately estimate its cost. So there is no point in trying. This is reflected by the larger gradient at the end of the estimation trail.

So if your reference task is 2SP. Then making an estimate of 1/2/3/5 is relatively easy as the task are of similar size. Once you get past 3 times as big as the reference task (5SP) the estimation becomes harder(Is 8/9/10SP does it matter) All you can say is its bigger than 5SP and smaller than 13SP then 8SP fits the bill.

Anything with a SP value of 13/21/Huge is too big for the sprint backlog. These are estimates for things you are not ready to actually work on yet (and thus have not broken down into smaller tasks (don't break them up until you need too)). But they do give you an estimate for the size of a task in the product backlog (which allows some future planning). By the time you get to the point where you are going to work on them you should have enough knowledge to break them up-into smaller tasks for the sprint backlog and re-estimate them individually (Note: Its a common misconception that the sum of the parts equal the original).

• Anything you estimate as Huge needs to be broken down into smaller tasks.
• Anything that is estimated as ? means it is not well enough defined to estimate
  You need to add a task specifically to go and define the task
  (i.e. write some documentation or presentation).

Answer 3

They are a waste of time.

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Interesting that this opinion now comes from the guy who wrote Scrum and XP from the Trenches and whose company name (Crisp) can be found on so many decks of planning poker cards used by so many teams around the world.

The last sentence of the OP: "Are there any good resources for explaining story points?" Yes, this book is a good resource. Food for thought.

Answer 4

Story points are a relative measurement of how difficult a task is. This is because humans are actually better at relative estimates than precise measurements.

The way you use story points is you take about two tasks on the project and assign them two different story point values. Then you estimate the other tasks using those two story point approximations as a basis for your estimate. I.e. Task C is not much harder than task A but incredibly easier than task B so it's only about 2 story points more work than task A.

When you are done estimating all of the requirements you have so far, you then estimate how many you can get done in a sprint. Over the next few sprints, you estimate how many you have completed. A requirement's story points are only counted as completed if the requirement is fulfilled. There is no "80% complete" in Scrum. This is because humans are actually bad at estimating completeness. After a few sprints, you should have an idea of how many story points you can do per sprint.

How do you estimate? You can use planning poker to determine how much work your developers feel a requirement will take relative to your basis requirements.

I would also recommend reading The Agile Samurai. It does a good job explaining these and other Agile concepts in my opinion.

Here's a link with more on story points.

Here's another link.

Answer 5

The easiest explanation I can come up with is using an object which is tangible and can provide a concrete example.

Take a mobile home. If I were in the mobile home business I would know that building a single wide typically takes 5 (points, frogs, widgets...the measurement form is arbitrary) and therefore building a double wide should take about double the effort or 10 (points, frogs, widgets).

The programmers mindset will at this point kick in and talk about a streamlined approach; it not taking twice as long due to the infrastructure consuming the largest portion of time and other similar examples. This is inevitable. Harp on the fact that this is an estimation in (points, frogs, widgets) since we can NEVER accurately estimate in time and thus estimating in (points, frogs, widgets) removes the belief that we can.

To know how long something will take to build we will make use of our trends over time; thus over time getting more and more accurate in our estimates.

Don't forget planning poker when the team is ready to go.

Answer 6

As others have mentioned story points are a relative measurement of complexity for a user story. The true benefit of story points are realized when

1. The points are measured by the unit responsible for implementation (either an individual or the team).
2. Metrics are kept for how many aggregate points are completed by the same unit within a constant duration (velocity).

After a few iterations of measuring in story points and tracking velocity, you should be able to accurately estimate how many story points can fit within a given timeblock (iteration or sprint if using scrum). Note that applying this technique to a group and trying to use those metrics for a different team will not work well. That is if team a can complete 120 story points in a two week sprint, expecting team b to have the same results is unrealistic.

As someone else mentioned, planning poker is a great aid when using this method because it will help identify stories that need further refinement (if there is a discrepancy between votes, it means there is uncertainty in the requirements).