Avoid Estimates in Agile Development – Use Budgets Instead

The initial stages of the software development journey can be exciting. It’s a time of possibility and experimentation; there’s a rush simply knowing you’re trying an alternative approach such as agile development. 

But these feelings start to wane when stakeholders try to figure the cost of getting the project from 0 to 100. The team might want to play with a couple of automation tools, but they require an extra set of expert hands; or there’s some research worth stretching out, but that means more data and more man-hours. 

As an agile team, it’s tempting to be idealistic and say “let’s go with the flow.” The more pragmatic project managers and directors requesting detailed budgets sound like spoilsports and it seems better to come up with rough estimates and adjust once you get into the trenches. 

Before we tell you why you should Avoid Estimates in Agile Development, let’s breakdown the concept of estimates in software development and why they are appealing in digital transformations.

Think of an estimate as an attempt to come up with a figure that’s as close as possible to the eventual quantifiable answer. An estimate can be used to guesstimate the time it takes to develop a product feature, the number of people needed, the total amount to be paid to them, tools and services they’ll use, etc.

Estimates gained popularity partly due to similarities in how digital technology solutions were developed in the past. When things like websites and databases were taking root among businesses in the crossover to the new millennium, it wasn’t uncommon for someone to say “I want something like the one X has, can you make it look like theirs?”

Being an early adopter meant that developers and designers could do a lot of copying and pasting during ideation and execution. With an earlier record of what it cost in time and money to put extra buttons on a web page or provide a specialized query function in a database, it was easier to make estimates.

However, a lot has changed. Nearly everyone is using digital technologies for one purpose or another. Several programming languages pop up every couple of years and brands are more obsessive about being unique.

Nevertheless, estimates are still common in modern-day software development. For starters, they help to break down the journey into several stages. Through estimation, developers and other team members can initiate a conversation about the unknowns and the extent to which they can affect product development.

Let’s dive deeper into how the effectiveness of estimates has dropped when it comes to project management, particularly in agile development settings.

Estimates Acknowledge Unknowns, but Don’t Dissect Them

One of the fundamentals of Agile development is the ability to adjust quickly to changing situations. Estimates tend to lean toward the side of best-case scenario, which isn’t always the case when developing software products.

 Say you have an estimate of how long it’s going to take to complete a product feature or component. But as tests are run, a few bugs are discovered. Your estimate may have insinuated that a sprint could take longer, but does it go into detail about why it may take longer? How many bugs will be discovered? The number of people needed to expedite the bug-fixing process and how much they are to be paid? 

Therefore, in such cases, estimates only soak your targets in wishful thinking without doing much in regard to contingency plans.

Estimates Disregard Additional Requirements for Smooth Collaboration

Another reason why estimates may not work for agile teams and DevOps settings is their tendency to focus on individual capacity to complete tasks. Estimates usually neglect the work that goes into achieving seamless collaboration between a number of coworkers playing different roles. 

Task estimates may not take into account the extent to which one person’s job is influenced by the availability of another team member, be it for a face-to-face meeting or submitting minor changes to a product. 

These are the kind of things that two or more people usually have a chat about to detail their availability so they can find an intersection between their schedules for when they need to collaborate in real-time. This process is continuous. Very few people can make promises regarding where there’ll be on a day that is months away.

So saying that a specific deliverable will be ready by a certain time because you know how much time it takes to type the necessary lines of code, design any visual aspects, or run tests is nothing more than optimism. 

Sometimes team members need to consult with workmates about temporary changes in approach and estimates can leave them feeling boxed in, unable to take impromptu actions. This may result in team members foregoing additional product-refining actions to meet a deadline, only for this decision to come back to bite the entire team later on.

Estimating often requires you to zero in on the smallest units or stints of the development journey, which reduces your ability to be accurate while taking up more of your time—especially for large projects. 

Organizations gravitate toward budgets since they can set aside extra resources in advance to address unforeseen eventualities. This process can be refined by taking the following steps.

Envisioning the Near-Term Goal

Ask yourself, “What’s the most important decision that I need to make soon?” This could be whether to develop a set of features for simultaneous ready-use or whether to start with the one core feature without which you’ll have no users. Or it could be a decision between hiring additional full-time employees or outsourcing the temporary services of one professional or a lean team. Only once you know why you’re trying to come up with a budget or estimate, you can move to the next step.

Precision Decision-Making

If your focus is on a broader strategic decision like whether to launch a startup or totally close a project, you’ll need to draw up a budget. You can’t just go around guessing what it will cost to do something as large as setting up an entire company or large department.

When dealing with a much smaller issue like adding minor functionality to a certain section of a software interface, you can resort to an estimate.

Breaking Down Your Budget

Without going into too much detail, list the primary components of your project. For instance, if you plan on setting up a video streaming service, you definitely need storage, signup or subscription mechanisms, search and indexing, etc.

By breaking the whole thing down, you’re more likely to arrive at sub-components that are a little bit similar to those used in other people’s projects, like the search and storage. There might be small variations due to the fact that you’re going to use these components for different purposes.

Nevertheless, you’ll be closer to a scenario in which a team member has worked on the creation of a similar component, say for a book store or a social media platform. They can tell you about those fundamental parts that are common irrespective of the use case for a component like a search and indexing.

This team member can also go on to highlight the ways in which search algorithms for a video streaming platform could differ from those of a bookstore, especially in areas like searching by describing the contents of the book or video.

At this point, you can start putting concrete figures on the time it takes and the amount of money it will cost. These figures can then be compared to the total initially set aside so as to determine whether the project costs more or less than what you have, and by how much.

The next challenge comes in when the gap is quite small. Here, you’ll have to sift through all the subcomponents of your project and separate the essentials from the optional elements. However, it’s important not to look at the gap as just something that needs to be closed. 

The gap between what you have and what the project will cost can help inform you on how much extra work you need to do down the road to make things work, whether it’s overtime for some core developers, sharing resources, etc.

As you move towards a budgeting approach, it’s important to remain aware of the finer areas that could still benefit from an estimate. 

Always ascertain the larger goals, then go into the details of how these goals can be achieved. In doing so, you can hope for a certain limit on necessary resources while keeping a finger on the project’s pulse to remain prepared to provide any supplementary requirements.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach