Evidence based estimation
February 22, 2018
I love this statement by W. Edwards Deming: “In God we trust. Everyone else must bring data”. It has dozens of practical applications, and one of them leads us directly to estimating project effort in agile mode.
In traditional project management, the project manager drills down into proposed scope and tries (hopefully with the support of the team) to arrive at reasonably reliable effort estimates. When I was first given this task as a junior project manager, I keenly felt the pressure to create perfect estimates for work that I didn’t fully understand, in very limited time. In most cases this didn’t go too well, and often the actual effort and schedule landed somewhere very different than I had planned. Very strangely, the more time and effort I spent on estimation, and the more exact I tried to be, the less accurate my estimates seemed.
Over time, I learned to consult my teams more and relax a bit about estimation. Roughly right was good enough, or at least preferable to exactly wrong. However, I only realized how I should have worked from the start when I started to learn agile methods.
It’s a common misunderstanding that there is no planning or estimation in agile. This is an oversimplification. It’s true that there is no traditional project plan when an agile team starts working. When the project starts, we don’t know what team’s velocity is, or in other words, we can’t know for sure how much work the team can deliver in the first sprint. However, the team itself – not the all-knowing project manager – estimates the size and complexity of the backlog items, and arrives at a rough estimation on how much of the backlog will probably fit into the first sprint. Usually the estimate of size and complexity is not made in hours or days of effort, but in T-shirt sizes, story points or some other similar format.
This estimation doesn’t look very sophisticated at first, but it’s power is revealed in the longer term. For the next sprint, we will have evidence based data on how much actual effort went into, for instance, a S-sized product. The next sprint the team has even more data, and will be able to confidently adjust any assumptions behind the project. This is also easy to argument to management, as we’re not talking about hunches – we have already proven what the team can achieve in what time.
A well-functioning agile team can usually achieve this evidence based capability and competence in 2 to 3 sprints, which is not much longer than what project managers can spend with traditional project plans. The quality, however, will be very different.
What do you think? How do you estimate, in agile or in tradition mode?