Estimating in Scrum uses a unit of measurement referred to as the Story Point. But why use Story Points instead of hours or days or any other well-known unit of time? Are we deliberately trying to obfuscate? In this article I look at the pros and cons of using Story Points and come to a surprising conclusion.
Reader Interactions
Comments
Trackbacks
-
[…] For a more in-depth look at estimating, I recommend the book Agile Estimating and Planning by Mike Cohn. Alternatively, if you want to explore the topic just a little further, I wrote another article on estimating and story points […]
-
[…] of Product Backlog items, each of which contains a Size, Order and Description […]
-
[…] of Product Backlog items, each of which contains a Size, Order and Description […]
-
[…] of Product Backlog items, each of which contains a Size, Order and Description […]
-
[…] of Product Backlog objects, every of which accommodates a Measurement, Order and Description […]
Assume, we arrive at a stable velocity of 110 story points per 22 working days sprint for a development team of 5 members. That maps to 1 story point per man-day on average. At this level of team maturity, what is the advantage of keeping estimating PB items in story points, while the rest of the organization uses man-days as an universal measure of effort?
I encourage you to read the article again to understand why there is no direct mapping between story points and standard units of time.
The problem with Scrum and Agile is its propensity to develop jargon, in most areas of industry, managers talk about ‘productivity’.
I’ve been involved in software and application development on and off for 30years and I still find it disappointing that professional, imaginative, hardworking and intelligent people ruin their credibility with this obfuscation.
The bottom line is you don’t want the team to be estimating hours, because this causes them to “pad” the number. The ambiguity of the story point in conjunction with sprint velocity enables a more accurate estimate and should therefore cause greater productivity for the team. If I’m asked how many hours something will take I’m going to provide more hours than required. If everyone estimate story points relative to other stories, this should be sufficient for any manager in conjunction with sprint velocity to identify how long a project may take, but reduce or eliminate the “padding”.
This is why story points with planning poker should continue to be used and never mistaken for time estimations.