Last week Kelly Waters was at the Guardian and we compared development approaches. Of all that was different in the way we did things, two things in particular intrigued me. Both concerned estimation, but more importantly both were about glossing over details to get a good outcome.

1. Wonky estimation

At the Guardian we’ve tended to fret when individual story cards start running over their estimated times. During the R2 project we even instituted a rule that any story going over 25% of its estimate got escalated.

By contrast Kelly said his experience was that teams would routinely misestimate stories, while consistently making their target velocity and meeting their delivery promises. In other words, there was consistency in poor estimation, but also underestimates would consistently balance out overestimates.

It seems contradictory that failure in the details should allow for success in the outcome, but that’s what happens. Kelly put this down to the magic of Fibonacci numbers.

2. Ignoring estimation by role

Meanwhile, we have generally broken estimates down by role: a card might be estimated as 3 Java days, 1 client-side day, and 2 testing days. This follows from iterations being similarly described as having a certain number Java days, client-side days, and testing days.

Kelly’s approach does away with that: the team is a whole team, estimates are one number, and this follows from the iteration having a known capacity which is also one number. The emphasis is on team members acting together and helping each other out, and he didn’t seem particularly vexed by the idea of one team member — a back-end developer, say — running out of work in an iteration because the workload that fortnight was particular front-end-heavy.

The approach I’d used in the past suddenly had echoes of old waterfall-style project management: trying to squeeze the most out of each individual by trying to fit everyone’s time together like a jigsaw.

As an aside, I’d say the “different roles, different estimates” approach has the advantage that it allows individuals to stick to what they enjoy and ensures quality work continues in their areas — client-side developers enjoy doing client-side development, and no-one could expect a back-end developer to as good a job there. But equally, it avoids the issue of trying to break down barriers between roles. And I suspect that one thing that helps break down those barriers is ensuring the teams remain as consistent as possible. But that’s a topic for another day.

The common theme

The common theme to both these differences — not fretting over individual estimates, and having a single estimate for each story — is that the intended outcome (end of iteration delivery) is successful even though the details are fuzzy or downright wrong. This is counterintuitive, but I also find it liberating. It’s always good to find new approaches to a topic you think you know well.