Agile estimations

I love agile software development because of the high quality software it produces in the shortest possible time, which also makes the stakeholders happy. By releasing frequently the development team gathers feedback almost instantly, so they can promptly verify if they're still on the right track or adjustments are necessary because of the changed requirements. However, the team can only release frequently if they work in short iterations and finish all of the work they've planned for that iteration. A key factor of avoiding failure and delivering as much business value as possible is the more or less accurate estimation of the tasks that the team is committed to get done.

But how much work a team can finish during an iteration? It depends on many things. Based on the previous iterations the team must have some sort of statistics (velocity) about their productivity which can be used as a reference to plan the new iteration. The availability of the team members is also important. And, of course, the team must estimate the effort it takes to get the planned job done.

Estimating is not easy though. If you start working on a project from scratch, you don't have much reference to rely on when you have to come up with some figures. It's even worse if you start working with a new team because you don't know how the team performs. But even if you work on the same project for months with the same team members, reaching an agreement can be difficult.

We had our planning meeting yesterday and we faced a different problem: I had the feeling that not all the team members shared the same understanding of the metric and scales we use to estimate the planned user stories. Being comfortable with the used metric is crucial, otherwise the planning meeting can turn into a never-ending argument. However, it isn't simple to shift your mind from time-based estimation into something more abstract.

It's not easy because at the end it all comes back to time: you have to finish something during the iteration. Your manager is also not interested in the amount of abstract things you've estimated your tasks in, but she will ask if you will finish your work, let's say, by the end of the week. Time is certainly not a negligible factor though, but estimating the user stories in the number of days it takes to implement them is just simply wrong. Why? Because you can only manage your time, but estimation is about the team effort. Implementing an algorithm that calculates the prime factors of a number can take a day for someone without mathematical background, but can be a ten-minute long finger exercise for someone practicing the Prime Factor Kata. What is the estimation in this case? One day or ten minutes? It depends on who picks up this task from the whiteboard.

We need to find something else then which does not depend on the skills of the team members as much as the time-based estimation. We could use complexity points to estimate our user stories. Complexity points - as their name suggests - reflect how complex a feature is, that is how difficult it is to implement it. Sounds good, doesn't it? The prime factor algorithm isn't going to be more complicated just because the team's junior programmer picks it up. Unfortunately, this won't work either. It won't work because complexity points completely ignore the effort which has to be taken to finish something. Typing in the text from a thousand-page long book is a fairly easy task, there isn't anything complicated about it. It most likely will, however, take the same amount of, or even more effort than to implement an algorithm that solves the Rubik cube.

At RIPE NCC we're doing Scrum, and we (when everybody has the same understanding) - like many others - estimate our coming work in story points. Story points represent the necessary effort to finish a user story. When you estimate in story points you take into account everything that is related to that user story: implementation, documentation, setting up the test environment, communication with other departments, and so forth. Story points are not independent from time or from complexity though. Implementing a complicated feature, like solving the Rubik cube, must be estimated to a higher story point value than implementing a simple Hello, World! application. Time-consuming yet simple tasks, like typing in one thousand pages, must also be estimated to a higher story point value. Nevertheless, the estimated story points must represent the team effort to get that particular user story done.

The number of delivered story points will change over time due to the inaccurate estimations in the beginning, the unforeseen events the team has to deal with, the different level of skills the team members have, and whatnot. As the team grows more mature and experienced, their estimation becomes more and more accurate, which ideally leads to a relatively constant velocity, which in turn aids them in even more accurate estimations...