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!