One of the things about writing software for a living is that customers are rarely happy when you tell them “It will be done when it’s done.” Even though development is fraught with uncertainty, it’s still incumbent upon us who practice this craft to be able to give people some idea of what kind of effort will be involved to implement a particular feature.

One way to do this is to have a project manager or senior programmer sit down, think really hard about it, and come up with numbers. This has the advantage of being  expedient, but the disadvantage of being almost certainly wrong. The reasons for this are many: it’s hard to estimate a job accurately when you’re not the person doing the work. All of us as individuals possess blind spots. And programmers are notoriously optimistic about how hard it will be to do something. (Not as optimistic as marketing people are when faced with a programming task, but still…)

One of the approaches I’ve seen that seems to promise the best results over time is Evidence-Based Scheduling. By having programmers estimate the tickets they’ll be working on, then record how much time they actually spend on it, comparing one to the other, factoring in how much productive time they have during the day once meetings, email, and the ilk are all done, and doing a lot of math, one can come up with good quality estimations — especially as one accumulates data on which programmers tend to exaggerate and which think they can finish nearly anything before lunch today. This approach has the advantage of producing really good estimates, but requires detailed tracking both of estimates and actual work time to produce good results.

Somewhere in the middle is Planning Poker, an approach that allows teams to collaboratively create estimates with a minimum of fuss. The basic idea is that you get all your developers together, give each of them a deck of cards with a time estimates written on each card, and have everyone choose how long they think a given task will take by throwing the corresponding card on the table. If there’s not agreement, everyone discusses it, explains their reasoning, and then you do it again until there’s a consensus. (You can read more details here if you’re interested.)

When we’re planning what to do for the next phase of a project, we have to consider two things: how important an issue is, and how much work it will be to do the fix. The latter has, up to now, been done off the cuff by whomever of the developers happened to be in the room. But in the past week, we’ve added a field to our ticketing system for estimates and started doing Planning Poker sessions to capture estimates for the tasks ahead. These seem to be going well, and I’ve noticed some interesting things about them:

• These sessions are actually pretty fun. Nobody has come away hating the process, and several of the devs involved have said they’ve really enjoyed them.
• Because the rules of the game call for the people with the highest and lowest guesses to explain their reasoning, we hear from people who are sometimes a bit more reluctant to speak. Having their opinions respectfully listened to can be a very affirming, especially for new folks who may not have a history with the team yet.
• We’ve actually been doing on-the-fly technical design as we discuss the issues, and have come up with some really good ideas and insights that we’ve then recorded in the ticket since we already had it open there. This was a pleasant surprise to me; I’d only been hoping to get estimates, but have also benefited from some terrific collaborative technical brainstorming.
• It provides natural cross-training, since even programmers who aren’t involved in a particular project get to listen, ask questions, and vote on its tickets.

So after two sessions, I’m counting Planning Poker as a success, and have scheduled regular sessions to finish estimating our backlog of tickets and to handle new ones as they show up.  Many thanks to Mike Cohn for the great writeup that got me excited about it!