Embrace Estimation

There’s a prevalence of negative attitudes toward estimation in software development. It stresses engineers out. It leads to disappointment when deadlines aren’t met. Why should we subject ourselves to this pain?

Well, most businesses need to plan ahead. Proper planning builds trust between departments and gives stakeholders the confidence they need to develop a long-term strategy.

In my line of work as a consultant, missing a deadline is rarely an option. Accurate estimation is fundamental to client satisfaction and developer happiness. Whether you’re an engineer, team lead, or stakeholder, you stand to benefit from a positive estimation culture in your organization.

Estimates are your friend

It’s not just a matter of how long it will take to ship. You want to avoid crunch time in the final weeks. You don’t want gotchas cropping up in the middle of development because requirements weren’t considered thoroughly. If you don’t go through a rigorous estimation process, you leave your team vulnerable to these pitfalls, and accountability goes out the window.

Estimates empower developers and managers alike. Scope creep is a constant battle that must be triaged regularly. You need a comprehensive understanding of your roadmap to make pragmatic decisions that will keep your project lean and focused.

We don’t have a hard deadline. Why bother?

If you’re in the enviable position of not having to deliver at a set time, you can still benefit from the estimation process. Estimating helps uncover ambiguities in your requirements. If there are any issues with the design, it’s a great impetus to clarify things before the rubber meets the road.

Divide and conquer

When estimating an entire project or large feature, I’ll identify the major components and assign hours to each area of concern. I find that thinking in terms of development domains helps me paint an accurate picture. Here’s an example estimate for an in-app payments feature:

The Backend and Frontend columns are pretty self-explanatory. Modeling is for the planning and discussion around the data representation of a feature. I like giving it its own category because it can involve multiple disciplines and is easy to gloss over. Management is a catch-all for requirements documentation, task assignment, meetings, and other things that are not explicitly engineering. These categories may not be a perfect fit for your team, so by all means come up with your own. The point is to capture all of the effort that goes into development.

Capacity/Week is based on 4 developers, each contributing an average of 30 hours per week. It’s important to be honest about your team’s actual productivity. In a typical 9–5 job, you’re not getting a solid 8 hours of output per employee. There’s stand-ups, planning meetings, all-hands meetings, company outings, and many other distractions throughout the day. You also can’t depend on everyone bringing their A-game 100% of the time.

Rinse / Repeat

My estimates tend to be a little too optimistic on the first pass. Initially, my mindset is focused on breaking the project down into measurable components. This tends to be biased toward the happy path, which is a great place to start, but it often misses more obscure factors that contribute to the timeline.

After my first pass, I’ll take a break. Then I’ll come back with fresh eyes and do another pass while asking these questions: Are there ambiguities in the requirements that could cost us time to reconcile? How likely is the implementation to encounter technical hurdles? How likely are requirements to change? Each of these factors bear an hourly cost that is impossible to predict perfectly, but the hope is that they will add up to a more accurate picture.

Share the love

Estimating can be overwhelming at first, especially for longer timelines. Make sure other members of your team participate in the process and help fine-tune your numbers. When tasks are assigned, ask the assignees if the time allotted makes sense, and give them ample time to respond. The more members of your team are comfortable with estimating tasks and projects, the more accurate your timelines will be.

A rant about story points

A common dictum of Agile™ is to use an abstract unit of measurement (story points) to estimate a task’s “size”. In my opinion, this just obscures the very thing you’re trying to measure. I think it’s best to do away with such hand-waving and just have 1 story point equal 1 hour.

Culture of transparency

Estimates are just that, estimates. They’re guaranteed to be off by some amount, but the goal is to reduce that differential as much as possible. The more input you bring into the process, the better your accuracy will be. Of course, this includes making adjustments to the timeline or scope during development. Developers should be encouraged to raise the alarm at the moment they realize a task is going to take longer than anticipated. It’s important to keep the lines of communication across your team open and honest.

When you take a rigorous approach to estimation, you’re in a much better position to manage expectations for your customers and stakeholders. Expectation management is key to maintaining a healthy organization and keeping customers happy. Even when things don’t go according to plan, a good reference is essential to improving your process in the next round.