 |
I got inspired to write this after reading one of Mike Cohn’s recent blog posts. Now, before I begin, let’s get one thing straight: I agree with probably everything Mike has ever written about Scrum and Agile and I’ve learned a lot from his book ‘Succeeding with Agile’, which is essential reading for anyone practising Scrum. Did I say I agree with everything? I meant nearly everything ;). Story-point estimation is the point on which I beg to differ. It’s my major bug-bear with Scrum, the one thing that I find ‘not fit for purpose’, broken, not working, kaput.
Mike, in his post, likens the definition of a story-point to the definition of a “yard”, i.e. a standard unit of measurement that can be agreed upon by everyone. The reasoning goes that, if everyone can agree on how long a yard is, then everyone can agree on how long a mile or an inch is and therefore have a standard frame of reference for future estimations. That would be fine and dandy if we had a real chunk of code which represented the true length of King Henry’s arm (say, for instance, Matz’s MRI code(1) ). The thing is, there’s no such thing as a ‘yard’ in software development. There’s no universal measure of how complex or long or time-consuming something is. Take what’s probably the simplest unit of measurement in the coding world: the ‘hello world!’ app. In something like Ruby, Perl, or even JavaScript(2) it’s one simple line of code. In Java it’s three or four and brings into play importing libraries, object-orientation, the main function, even the file system itself. So to a Java developer a ‘yard’ will always be much longer(3) and more complex than to a Ruby/Perl developer.
Moreover, a yard remains ever unchanging and unchangeable, unaffected by the whims of man or nature. Whether you’re tired or beaming with energy, in a good mood or in a bad mood, full of cynical experience or optimistically naive, a yard is a yard is a yard is a yard. The same cannot be said about good ol’ story-points. Something that appears very complex or time-consuming today may well appear simple and quickly-solvable tomorrow. Knowledge is power and if I had a penny for every time I came back a week later and re-adjusted my estimate downwards for a previous story after learning a bit more about the relevant domain, well….I’d probably have enough money to buy myself a pizza. Not just any pizza, I’m talking 16 inch, thick-pan, filled crust here, the works. That’s a lot of pennies right there!
Not only that, but the way we define a ‘yard’ in software changes dependent on the observer’s technical perspective and even psychological or emotional state. Factors like personal and team morale, inter-personal relationships, outside influences, e.t.c. they all affect our ability to tell how time-consuming or complex a story is. On a ‘good’(4) day I feel there’s nothing I can’t achieve and my estimates tend to be overly optimistic, reflecting my psyche. Conversely, when things are gloomy so are my estimates - everything seems like a huge chore to me. My definition of a ‘yard’ keeps changing, victim to a dozen or more fluctuating factors, none of which are taken into account when we come to ‘agree’ on an estimate during our planning poker. In every single planning meeting I’ve attended, ‘consensus’ is always closer to the estimate of the most senior/influential/charismatic person in the room. Trying to give objective estimates during planning poker is a bit like trying to avoid taking drugs at a Grateful Dead gig: peer pressure will prevail in the end. Still, I can envisage an environment where planning poker works fine. The trouble is, that environment consists of closely-knit team-members of similar experience, skill, background and ‘status’(5). Last time I checked there weren’t many dev teams like that!So what are we to do? Well, we can always fall back on Joel’s evidence-based scheduling approach. Or we can get Story-point estimation working right, using more objective measurements and accounting for a number of technical and environmental factors. I have some thoughts on this but they’ll have to come out at a later post as this one’s already getting too long.
Footnotes:
(1) feel free to replace with your chosen bit of legendary coding.
(2) not accounting for the surrounding HTML
(3) I’m not having a go at Java (this time), just making a point about complexity and size.
(4) I don’t have many of these, to be honest.
(5) For want of a better word.