This from another recent lunch conversation –

1. Story points are a pure measure of size and complexity>
2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
5. Story points don’t influence behavior (e.g. Parkinson’s Law)
6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.

On a slightly different note –

When you use a geometric series for your story-point scale (say 10, 20, 40, 80, 160) as opposed to, say the fibonacci sequence (1, 2, 3, 5, 8, 13, or multiples thereof), it is a lot easier for your scale to satisfy the closure properties over addition and subtraction. In other words, with a geometric scale, a product owner can say “Hmm… I think this 40 point story is not ready to be played yet”, and you can respond with “How about we swap it with these two 20 pointers?” This could be a bit less intuitive when dealing with the fibonacci scale. All IMHO.

My previous post on estimation sparked off quite a conversation between a colleague and myself. It was a great conversation from which I captured a few points that I wanted to elaborate on.

First of all – what is the psychology behind story points? IMHO, the answer is Parkinson’s law – work expands to fill all available time. This is not a reflection on the ethics or abilities of a developer or anyone else engaged in a software project – but something that, as humans, we’re all susceptible to. Our minds tend to think in terms of reality – and of past experiences. This is why, when asked for an estimate in units of real time, people tend to factor in all kinds of eventualities. It is very difficult not to think in this manner. Keeping the actual timeline outside the scope of the estimation is very helpful – it helps the person doing the estimation think on a somewhat orthogonal dimension – that of complexity alone. This is why thinking in complexity units works so well. You can call them jelly-beans or NUTs (nebulous units of time) or WAG-points if you like.

A related point that I’d like to iterate, if it isn’t already obvious, is that this also helps keeping in check the tendency of folks to buffer estimates. Since the discussion is no longer in terms of real time, people aren’t so much concerned about being able to finish in the amount of time they’re assigning a story is worth or that they’d later have to stick to. Automatically, this helps in keeping buffers out. (Not that buffers are bad – but there should be a method to the buffer madness.)

A side-effect is that teams can quickly agree on complexity estimates. This is especially true when using a simple complexity scale – say Large, Medium, Small. I used this scale and as we gained domain knowledge and experience with the code-base, we added SmallerThanSmall and Tiny. These are worth 200, 100, 50, 20, 8 “points” respectively. I like to use a scale that (almost) doubles as it increases in complexity. Developers with differing levels of experience and domain knowledge can typically agree about where a particular story falls on this scale. This helps taking another subjective factor out of scope for the estimation activity as well – and helps in ensuring all developers can participate.

Finally, from a planning point of view – velocity and simple statistics take care of things. Despite the fact that developers estimate in story points, planning can be done in real units of time after translating the estimates using historical velocity numbers and applying them across the backlog. This part is almost trivial!

Once again, discussions at work have driven me to write this. This time, the topic of debate (or rather, amusement) is that in an agile team, hours (or days) and not story points are a better way to estimate user stories. I disagree.

Developers are, in general, more aware of the potential complexities that they can run into in the process of implementing a story. Despite this cognizance, it is often hard to predict exactly what these complexities might be. Obviously, if a developer knew the exact nature of the issues that he will run into, he can account for those and predict exactly how much time the work might take. Since this knowledge can never be complete, no developer can determine the exact amount of time needed.

Further, depending on the specific process being used in a given team, it is possible that the developer(s) who estimated a given story is not the one who ends up actually doing the implementation. Different developers have different skill levels and differing amounts of domain-knowledge. This also contributes to the variance in the actual time taken for implementation.

Finally, there are things that developers have no control over – the so called external factors – source-control going down or behaving erratically, having to attend meetings, or having to help another team or another developer on something, and so forth. Someone with critical knowledge could be out on vacation or a key developer could fall sick.

Lets represent actual time taken by a developer to complete a story with the following formula ->
A = function(C, U, E, S, K)
where
A = actual time
C = an idea of complexity (how difficult something is, and how many tasks there may be),
U = unpleasant technical surprises,
E = external factors,
S = implementing developer skill level,
K = available domain knowledge

Clearly, the only thing that can be “estimated” here is C – an idea of complexity (also based on the “understanding” of the team – whatever that is, and however it can be quantified). Let’s say that we measure this with complexity points (or story points). If we assume that everything else will get averaged out over the duration of the project (which it usually does), then it all comes together quite nicely. This is why story point estimation works.

On the other hand, trying to estimate using hours is like trying to guess the effect of the other four (and possibly more) factors. Trying to estimate in hours is like trying to estimate both the effort needed due to complexity AND the velocity of the people working on the story.

Finally, if I hear someone say that they have a capacity of 400 real hours, that they’re signing up for 600 hours of work and end up completing 500, then in my mind, the 500 hours of work that got done (which can’t be squeezed into 400 real hours) might as well be 500 story points. In fact, you can up the numbers by a factor of 10 so that the team really had 400 real hours (time doesn’t change), they signed up for 6000 points and got 5000 done, it will not change a thing. Story points are story points. The team can call it “ideal hours” or “estimate hours” or whatever they like. As long as they’re not real hours, they’re just like a rose with another name…