Estimating Projects Without a Tardis

Time travel doesn’t exist. Okay, you might not think that’s news. But some people get really disappointed when I tell them.

The problem is that they’re looking for certainty in an uncertain world. They ask us how long a project will take, a project that might include many firsts for us, them, and the world at large; a project with fresh challenges that requires us to use our skills in inventive new ways. How can anyone be sure how long that will take? You can only know for sure how long things took once they’re done and in the past.

That doesn’t mean we don’t plan and estimate . We do. In detail. Using the scrum methodology, each project is made up of perhaps hundreds of user stories, which describe the functionality the users of the system need us to implement. The database of user stories is called the backlog. We estimate the complexity of each user story by playing speed planning poker, a game we’ve refined from the planning poker widely used in agile software development.

To play the game, the team gets together and reads the user story. The scrum master says: “Ready, steady, go!”, and each team member holds up a number of fingers to show how complex he or she thinks that particular user story will be to implement. (Incidentally, we say “Ready, steady, go!” instead of counting down because research shows that using numbers can bias the estimates.)

Some stories are easy to estimate, such as implementing user login. Others, such as improving a search algorithm, are harder to estimate. If everyone awards the same number of story points, we don’t need to discuss it further and can move on. If there are slight differences, we go with the higher number, because we know it’s only an estimate and it’s not worth debating. If there are huge discrepancies, we discuss why that is. Usually, it would be because there is a difference in understanding the task.

If you’re looking for a promised delivery date on a huge and complex project, story points might seem imprecise. But they reflect the truth of software development: you can’t know everything in advance.

The important distinction is that we’re not estimating time, we’re estimating complexity. A story that has five points would take about twice as long as a story with two points, but we might not yet know how long a two point story will take. That’s because complexity is only half of it. The other part is the velocity of the team, or how many story points they’re able to complete in a week. That varies according to the team, client, and project, and will often change during the project too. As the velocity changes, the team might take on more or less story points in a week.

If you’re looking for a promised delivery date on a huge and complex project, story points might seem imprecise. But they reflect the truth of software development: you can’t know everything in advance, and you can’t develop at a uniform speed throughout the project. Once you’re used to them, story points are a surprisingly flexible and accurate planning tool. We can tot-up the story points in the backlog to see how much remains to be done, and use the velocity to discuss how long it’s likely to take. As the velocity changes, the time to project completion changes, but we always have an idea of how long it’s likely to take.

Fundamentally, we believe this approach is more honest and more transparent. If someone says they can give you a cast-iron guarantee of how long a software development project will take, don’t believe him. Not unless he takes you for a trip in his Tardis first.

Get involved: New Bamboo Blog – Estimating projects without a Tardis