Development Estimates

A Different Take on a Contentious Practice

How to get value from development estimates and why I've learned to love them.

An Unpopular Opinion

Working as a programmer, I can't count the number of times that I've heard colleagues complaining about development estimates. Some of the complaints are simply grumblings of people who aren't generally cooperative. There's not much you can say to these people to change their minds. Other complaints are valid reasons that a lot of estimates aren't valuable or realistic. Here are 5 common mistakes that I see and what you can do to avoid them.

A Story

Let's start with an all too familiar story.

TechCo needs to develop a new product that will fit in with their offerings.

Jane the manager asks John the developer how long it will take to build the product and how much it will cost.

John says he'll think about it and get back to Jane. The next week during their weekly developers' meeting, John gives Jane an estimate that he thinks is reasonable.

Jane gives John's info to upper management who make a decision to go ahead with the project.

Months later when the project is about to meet its deadline, John, Jane, and upper management realize it's not going to be done on time and start trying to figure out what happened. Upper management puts pressure on Jane to make John finish on time. Jane pushes John hard to finish on time. John ends up finishing on time after putting in an 80 hour week. John is burnt out, Jane is glad to have upper management off her back, and upper management are happy the product went out on time.

Mistakes and Misconceptions

It's clear that at the end of this situation, we're in a bad place with a lot of growing animosity between our actors. It might not be immediately obvious where they went wrong though. In this situation, it would be easy to point the finger at John. After all, he could have made a better estimate and he's the lowest person on the totem pole. If we take a step back and think about the situation more holistically though, there are mistakes every step of the way.

Mistake 1 - Upper management and Jane asked John for an estimate without a well-defined scope

I think most people would agree that developing a piece of software is a more flexible process than, say, making a chair. The physical nature of chair building means that prototyping and building the chair is costly and time-consuming. On the other hand, it's easy and fast to prototype a software application and that's a good thing... until it isn't.

I think we sometimes think that the flexibility of software development means we don't need to take the time and create well-defined scopes for our projects. Just because it is easy to iterate, doesn't mean that we shouldn't have a specific goal for our iterations. A common giveaway that I need a better scope definition is someone asking me a question like "How long do you think it would take to build something like that?" Those words "something like that" tell a whole tale of undefined, changing expectations. It took me a while to build the confidence to tell people that it would be a disservice to everyone to give an estimate for an ill-defined project. Though at the end of the day, could you estimate how long it would take to build a chair if you didn't know I was expecting a lazy-boy with cup holders?

Mistake 2 - John built and reported an estimate without using data to back it up

As developers, we tend to do a lot of little estimates in our head all the time. I estimate how much I'll be able to get done in the day, what I'll be able to work on tomorrow, and whether or not I'll be in a good mood after tracking down this bug. I think that this mindset spills over into doing development estimates. When our manager comes and asks, "how long do you think it will take?", we just think about it for a minute and spit out an answer. This might not be a problem for small things, but it's definitely a problem for larger projects.

These off the cuff estimates can cause a disconnect in expectations. You might know that the estimate was rough and shouldn't be taken strictly, but after two or three relays of the estimate across the company, it could be taken as a concrete deadline. The difference in expectations is a recipe for disappointment and confrontation down the line.

The best way to avoid these problems is to use data for your estimates. How long did the last project like this take you? If you haven't done anything like this in the past, break the project down into smaller pieces. Odds are that you've done at least some of the component pieces in the past. How good or bad are you at estimating things historically? Add in a "fudge factor" that multiplies all of your estimates by some amount that you can fine tune based on your typical over/underestimates.

I know that in reality, giving an imprecise estimate to a manager about a day to day task isn't the end of the world. It is important, though, to tune our perception to be able to pick up on the times that giving a calculated and data-driven estimate is important.

Mistake 3 - The estimate was treated as a deadline

Humans are notoriously bad at estimating things. It's a common mistake that I'm notoriously guilty of. I look at the component pieces of a project, make an estimate for each of them, and then sum the parts. This approach ends up being precise and inaccurate. There are always unknowns and complications in connecting the parts. Instead, we should be giving estimates that use confidence intervals to take the uncertainty into account. A 90% confidence interval should be almost too wide to even be useful. From there, you can shrink the interval and the confidence so that the people using the estimate have a better understanding of the risks involved in using a precise estimate. Most managers will implicitly understand that a plan based on confidence intervals is subject to change and fluidity.

Mistake 4 - Nobody was flexible with changes to the reality of the situation

Unfortunately, reality gets murky. At times, it's important to put your best intentions aside, be a team player, and work with what you have. Maybe you don't feel comfortable telling the CEO of your company that you don't want to give him or her an estimate for their latest idea, and that's totally understandable. Maybe you don't have much experience at the company or with a piece of technology. No matter what, the most important thing is to be open and honest about your expectations, knowledge, and confidence in the estimate. Cultivating an open and honest attitude can change even the most stubborn of cultures into one where estimates are an exciting part of starting every new project.

Mistake 5 - There was no project debrief or retrospective

Every project needs a debrief. It's as simple as that. There's no way that we can learn from our mistakes if we never acknowledge them and there's a low chance of repeating success without understanding how we got there.

Beyond those inalienable truths, retrospectives offer a place for stress to be resolved productively. If a manager is driving their team extra hard on a project and there's no follow up after the team meets their goals, the team will feel used and unappreciated. On the other hand, a retrospective offers the opportunity for the manager to explain their reasoning, thank the team for bearing with them during that stressful period, and publicly acknowledge their hard work and effort.

A Better Story

Let's take another look at the story above taking these tips into account.

TechCo needs to develop a new product that will fit in with their offerings. They do research and define the core functionality that the product needs.

Jane the manager takes the core product definition and uses her technical expertise to define the scope of the project. She takes the well-defined scope to John the developer and asks how long it will take and how much it will cost.

John takes the scope, uses historical data, and confers with the rest of his team. He creates an estimate that includes a wide range of time with notes about where uncertainty is introduced throughout the estimate and gives it to Jane.

Jane gives John's info to upper management who make a decision to go ahead with the project.

Months later the project isn't going to be finished as quickly as upper management was hoping. They speak with Jane who reminds them that they're still within the wide estimate that John gave them, but who also realizes the importance of getting the product to market. Jane speaks with John and asks if he would be willing to work overtime to get the project done sooner. John agrees and is compensated for his overtime because upper management realizes that they are asking for effort beyond what was expected of everyone.

Later, John and Jane sit down and look back on the project. They make notes about where estimates were correct, where they were too generous, and where they didn't allow enough time. They talk about what went well and what could be improved. They put this data into a place where everyone can see and use it in the future.