It takes 3-5 sprints for a team to establish stable velocity. And then we're supposed to use this velocity to forecast future effort, i.e. amount of effort we can put into future sprints. Now, this works fine if nothing changes. For velocity to work, it is assumed that the same people will be working on the same kind of problems, using the same technology, with the same productivity and motivation every day for the duration of the project!
If you're one of the lucky few where nothing ever changes in your team and your project then congratulations, velocity as a forecasting tool will work well for you! If, however, you're one of the unlucky 99.999% where life gets in the way and causes pesky changes in your team or project then tough luck! Each and every time a team member falls ill or simply becomes unhappy, or you have to use a different tool, or the sprint duration changes or simply a previous assumption about your project is invalidated then Bang! Velocity blows up in your face. Welcome to another few sprints until you establish stable velocity again - enjoy it while it lasts because in a few more sprints it's going to blow up again.
Velocity is a placebo. Is one of those things that gives us the illusion that we're in control of something and makes us feel better for it, while it has very little practical effect.
The way to deal with change in not to assume that it won't happen and -when it does- start all over again. The way to deal with change is to be prepared and -when it comes- make sure we can assess it, measure it and manage it. We need a method that breaks down change, weighs its effects and allows us to quantify it and adjust to it.
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.
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(6).
(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.
(6) I'm such a tease!