Sometimes estimating in software can seem like a mystic art or something which only mathematicians could achieve with any accuracy. In this blog, I want to share some of my experiences in estimating and some of the tools and techniques which have helped me try and tread this rather difficult tightrope. Estimating is always an intense topic of discussion in the tech world. Understandably stakeholders want them to have an idea of when a project will be delivered and the budget. Developers don’t want to give them as far too often they are taken as deadlines. Project managers get caught in the middle trying to work out how to appease both sides, while accurately trying to plan out the project. So how do we solve for this?
So what’s the problem with estimates? The straightforward answer is the fact they are made at the start of a project, the point at which the amount of unknowns is at it’s highest. All too often these estimates are overly optimistic and set an unreasonable or even impossible expectation. The result: a disheartened team; a disappointed client; a late project. The reason that I highlight late here is the inference of time and it is this time basis that I believe is the route of the problem. So what have I done to try and solve this since starting my career as a project manager?
So we began as most do, just a straight up hours estimate. As you can probably guess from the above this didn’t work too well. For me, the key issue was that as a team you have to provide one estimate, however, the estimate didn’t necessarily reflect the person doing the work. For example, if a senior engineer estimates, a junior engineer probably wouldn’t be able to deliver at the same pace. This becomes even more pronounced the bigger the team gets and the ratio of junior to senior engineers increases, and the bigger this gets, the more the project falls behind its initial estimates.
So we tried to rectify this by using story points to try and create some disassociation with time. The key problem, we said roughly speaking it’s 5 points a day per person… so we created the disassociation, and then straight away put an association back in, admittedly looser, but still there. For a time this gave us some leeway while giving stakeholders an expected date for delivery. However, the usual happened with the project, complexities were found, scope increases were needed, staff sickness and holidays. The list can go on, but the result is the same, the project doesn’t get delivered when you predict. It was a baby step in the right direction, but we wanted to push for more.
So how did we try to get this leap forward? We moved to complexity estimates. The beauty of complexity estimates is that we can complete divorce time from the initial estimation. For anyone who is unaware of how to do complexity estimates here’s a quick guide:
- Select the easiest task to do and give it a benchmark figure based on the Fibonacci sequence (I tend to pick 2 as something easier always tends to appear)
- Estimate the next ticket in comparison to the complexity of the first and so on and so forth until we have a fully estimated backlog.
- The team picks an amount of work they think would be achievable in the first sprint.
- As the team velocity develops this can then be used to estimate the length of the project.
The major drawback is that most clients want to know how long a project will take before committing to starting. This hurdle is something which can be mitigated by having an initial ‘finger in the air’ estimate and then managing expectations and risks as the project progresses. This both limits expectation management and allows for the project to develop and evolve over time. This has worked successfully on the projects we have run this exercise on, and the tools and reports we use have made this even more effective – such as the velocity chart and version reports in JIRA.
So to finish, my best advice to anyone looking at estimation – try and remove time from the initial equation and allow the team to develop it’s own pace while using all the benefits of an Agile mindset alongside the methodology you are using to manage expectations! Couple this with a good reporting toolset and you might be able to avoid some of the pains of usual time-based estimates and traverse the ‘cone of uncertainty‘ to a place where we are confident in our estimates. Always remember the words of Robert Burns from To a Mouse (1786) when it comes to planning though:
“In proving foresight may be vain:
The best laid schemes o’ mice an’ men
Gang aft a-gley,
An’ lea’e us nought but grief an’ pain,
For promised joy”
