I give a shit on story points

You can see story point more and more famous as a kind of estimation (and scheduling technique). It intends to simplify estimation and scheduling but in practice it makes life more and more difficult.

What is the story point?

Let’s see some definitions:

“Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.” – agilefaq

“A story point is to program code what a kilogram is to sand or a kilometer is to distance: An arbitrary unit of measure which describes how heavy, far, big or complex something is.” – Explaining Story Points to Management (Otto: Soooo bad…., see later, mixing up SP and velocity and their relationship…)

” The number of use case points in a project is a function of the following:

  • the number and complexity of the use cases in the system
  • the number and complexity of the actors on the system
  • various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases
  • the environment in which the project will be developed (such as the language, the team’s motivation, and so on) “ – Estimating With Use Case Points (Otto: Quite a lot of not so related aspect of development…)

And many many more….

It has a huge literature. One of the always quoted reference is Mike Cohn’s Agile estimating and planning. It is not only about story point but it is clear that Cohn preferes story point more. (On the other hand the book itself is great, a must read.) (De facto “main reference point” about story points.)

In out “everyday” it come up in the context of Scrum I have participated in several Scrum introduction and I have indirect (but close enough to be reliable) information from other. Without any exception it introduced the usage of story points.

BUT: Scrum is not about story points. Not at all. What is more! Not even talking about estimation. Nothing. When I am saying Scrum I am talking about the Scrum as it is. Of course when you are talking about Scrum it is always the original Scrum PLUS many-many additional tools and techniques (including story points).

Once I had a talk with some manager using Scrum in his organization. He told me that one of their current challenge (using Scrum for many years and still having this problem. hmmm…. - on the other hand they have introduced a very agile process which is great) is to make business people understanding the concept of story points. I think it is a mistake to explain it to a businessman who is interested in time and schedule…

In one of his presentation Dan North highlighted why story point is insane (around 24:40 - not exact transcript):

  • (businessman) How much will it cost and when can I have it?
  • (agile guy) We don’t know. We are agile.
  • What?… How much will it cost and when can I have it? These are not hard questions.
  • OK. We have done some work and we think that it gonna be 295 stories..
  • What?…
  • And about 1000 story points.
  • What is the story point?
  • We don’t know yet.
  • You are absolutely kidding me.
  • We gonna run for few weeks and we gonna burn up and burn down and the velocity and hablalal…
  • Stop! Stop right now and get out of my building.

(Humorous with lots of truth!)

As I see (and it cause me many problem when dealing with story points). It tries to mix up many unrelated estimation characteristics into one single number:

As these risks are so independent from each other you have to use different strategies and techniques to manage them. But if you are hiding these aspect behind a single figure you do not even have a chance.

Plus it has so many other weakness:

So if story points has so many issues why are we using it?

Instead of story points

Instead of story points you should use calendar based estimates with proper risk management and (semi-)automatic estimation adjustment.

But how? It is a subject of another article (later).

Management stack
Nov 25, 2014
comments powered by Disqus