Monday, November 2, 2009

What else is wrong with Story Points as a time unit?

There is one another point against considering a story point as a certain period of time (e.g. half a day). It is difficult to use special planning cards for a planning session because their values are like 1, 2, 3, 5, 8, 13, 20, etc. but the time in other hand is linear. So the problem is what to do if we estimate that something should take 17 days?

4 comments:

Jonas Lindström said...

Probably the item is too large to be worked on or not defined enough.

break it down to smaller pieces and try again :)

Maciej Gudan said...

Story Points are used for tracking a team velocity from the Product Backlog point of view. Most of items in the Product Backlog in their early phases are related to the future features and there is no time, no need, no sense and often even not possible to split them all to so small pieces at the beginning:). They will be split later on, when the time for implementing them comes. There is also a reason why Story Points don't increase in a linear way:).

Hugo said...

Firstly because story points aren't directly related to time.

But more importantly, it's not worth arguing whether something is really 12, 13, 14 or 15. 13 is probably close enough, and far away from 8 and 20.

The point isn't really to get 100% accurate estimates, but for the team members to get a common understanding: if one estimates 20 and the rest 3, someone probably knows something the doesn't, and they can discuss it.

If one estimates 13, another 12, another 14, they probably all have a common understanding.

Maciej Gudan said...

That's true Hugo. In addition if there are no 13, 14, 15 but only 8, 13, 20 it increases awareness that these are only rough estimates which are less and less accurate.