Estimation in Agile: Here’s Why It Is Not Same As Signing A Blank Cheque

Estimation in Agile

Have you experienced this before: you want to fix parts of your car and the service agent tells you that he cannot commit on the cost, scope and schedule of the repair. Nevertheless, he assures you that he will deliver your car in excellent condition. Would you be convinced? The first thought to cross your mind would be the expense and then, the estimated time of delivery.

You might take back your car and consult another mechanic, right? What if you come across several others who claim the same? You might then succumb and feel like this is your only choice. However, deep down in your heart, you feel that the mechanic might leave you in the lurch, as you have zero visibility on your budget or timeline.

This is the same scenario for a customer who wants to develop software, but ends up being bombarded with the merits of Agile methodology, without any clear picture on the estimated projection of costs and time involved in the development. Blame it on the bad experiences delivered by the service providers or the improper adherence to Agile best practices (see example below), Agile may appear to be like writing a blank cheque, to most of the customers.


In this post, we will help you debunk this myth, and let you understand why definite estimates still remain a challenge in Agile; there is definitely a way out!

Have a look at this:


Has the above happened to you too? Customers look for a radius to define the budget for their project. But, what they also need to understand is that ideas evolve and requirements change as you dive in deep.. In addition, implementing the changes in the middle of development is a greater and costlier challenge when you follow the traditional waterfall methodology in place of Agile.

Let’s go through the key lessons we drew out of our experiences, while working on different projects, that might help you understand why estimation is challenging:

1. Change is Unavoidable in Software Development

Many people believe that developing software is a predictable process. However, this is a misconception that makes it difficult for customers to adapt to Agile software development methodology.

Developing software is a highly complex process, which involves many variables, unknowns and complexities. As you dive in to identify the requirements, you realize that they keep growing and changing. When that happens, it is very difficult to cater the new requirements in the existing plan.

Example: One of our clients who came with a requirement to build a travel app, wanted to add a chat module. The initial requirement was to only have an email module to connect the vendor and the users of the app; the addition of the chat module came nearly 6 weeks after the requirements were finalized. The need for adding the chat module was purely based on the feedback of initial users of the app and proved to be a significant feature. Had we carried out the development in the traditional waterfall model, there would have been drastic changes in the design as well as data base which could have cast a shadow on the work flow – resulting in delays in launch, as well as cost escalations.

Agile allows you the flexibility to accommodate sudden changes in requirements at any point in time during the course of development.

Matching the understanding of the developer and customer is a challenge. Developers tend to think more towards code and technology, while customers tend to think more towards the business side. Agile bridges the gaps by improving communication between the client and development team.

In addition, Agile allows us the flexibility to implement new technological developments during the execution of the project. Some of these developments make the implementation of the solution easier, or make it possible to implement more requirements with the same resources.

2. Agile Advocates for Short-Term and Frequent Releases that Allow Flexibility in Market Ready Product/MVP

The iterative and incremental approach in Agile allows clarity on the development to be carried out over a specific set of weeks.

Change in scope can have many reasons, including evolving insights into how systems should work, or how the process should be automated. There might be a situation where the domain you are working in has some disruption and you have to modify/tweak your business goals to remain competent. Customers should take advantage of an approach that allows for changes. Many projects fail because we deliver what was designed, instead of what was needed.

Instead of waiting for months to gather the final feedback from the customers, it is better to test out your idea with a minimal set of people initially.

For instance, one of our clients wanted to build to a mobile app allowing users to share their ride location and details with their family and friends. We adopted the Agile model to create a prototype of this app, and ensured that everything fell within the client’s budget.  We launched this prototype with minimum workable features. We provided release after every sprint to the client, and included more feedback in the subsequent sprints. We kept on iterating this until the product development finally included all the originally planned features, and launched it with the investors. Each of our releases introduced more features into the app – converting into a high-performing app.

Agile emphasizes on delivering functionality at the end of every sprint. Even better, each sprint’s functionality can be deployed to the production, or can be used to let the end user know that the project is going to be a success.

Agile allows the most direct communication, and sharing feedback, by putting the customer in the same with the people who will actually build the system.

Customers need to see the benefit of being able to start as soon as possible, instead of waiting for massive design/SRS/backlog documents (which are hard to read anyways). Agile emphasizes on breaking down the complex software development into small steps, and delivering the key features with priority.

3. Agile can Help Save Costs

When estimations look difficult in Agile, you are most likely heading towards a growing budget. However, you also need to look at the other side. Here is an example to help explain

A client came to us with a predefined set of requirements and asked for a fixed quote. We analyzed and found that Agile was a better engagement model. However, the client was hell bent on carrying it out with the fixed cost engagement model.

We gave them a projected figure and the project continued. Upon completion of the project, the client came back to us with some additional tweaks. We again provided an estimation of the cost to the client.

After a few weeks, some more changes were requested on the clients’ end. It was then, that they realized the escalation in their originally planned budget. Had they opted for the Agile model, the changes would have been incorporated within the same estimated costs and delivered in a much lesser timeframe. They decided to switch to the Agile model.

As described in #2, Agile allows the product owners to gather direct feedback from the users ,and provides a faster way to validate the idea and improve upon it. Especially when you are not completely confident in the success of your product idea.

Instead of investing your money into building the final product, you can made a limited investment in a prototype and test it out. Take the example of one of our clients who wanted to build an app for a corporate parking lot. They wanted a feature in the app  allowing the employees to open the entry barrier from a distance via the app. We created an MVP for the client. They tested it out with their employees. However, due to some limitations in the features and scope, they decided to scrap it. They saved their investment.

Agile, helps sort your additional costs. Along with that, it allows you to estimate a cap for the monthly budget. We will be discussing the right Agile estimation techniques in our next post Estimating a Project in Agile: This is How We Do It.


The challenges of agile software development are not confined to writing the code. They lay heavily in figuring out what code to write. Similarly in fixing a car, you know what you want to fix. However, you fear escalation in the cost of the repair, which could turn out to be exceptionally higher than your initial estimate.

Even though estimations in Agile are challenging, it comes with an overall forceful advantage over any other engagement model for the software development process. It focuses on ensuring a finished piece of software for you at the end of every sprint, while helping you save your time and money. Instead of waiting for months or years to see the end result, you get a real, workable update within a specific period, giving your company the opportunity to evaluate and decide whether the project is moving in the right direction. Having these mini-releases also allows you to gather more funding because you can release the software, get feedback from your users (or the market), then see if it’s worth getting additional funding for an improved version, or determine whether it’s time to go back to the drawing board.

If you are perplexed about estimating your project, or are looking for any help in building digital solutions for better customer or employee engagement, we can help. Please contact us at [email protected].

Salil Ahuja

About the Author

Salil is currently working as a Business Analyst with Net Solutions. He is enthusiastic about solving business problems involving complex workflows and creating solutions for disparate systems. He loves working on Agile project management methodology as it advocates for continuous product development. Besides work, he likes travelling, photography, gadgets and exploring new cars.

Leave a Comment