Estimates: a necessary step?

No matter what your role in the team or where you stand in the hierarchy, we all have to estimate time frames and scope.


Due to the number of parameters and the fact that they’re going to change (Guaranteed! Change is the only constant), providing estimates is one of the most complex tasks we tackle in our work as custom software developers.


But why are estimates considered so crucial?


They provide a sense of control and predictability. Humans love certainty and guarantees. We crave reassurance. A precise start date, end date, scope and budget. With this information, we can put together a team and work schedule (nothing like a good ol’ Gantt chart!). This lets us answer the client’s big question: when will the software be finished, and how much is it going to cost? Next come negotiations, signing the contract, the procurement process, etc.


How much time, money and energy are needed to satisfy this need for control?


Once the team is in place and the project is underway, people start asking questions, and the answers most often complicate the parameters—or even fully invalidate the assumptions in the estimate. The process can take so much time that the business context changes, invalidating the assumptions before the project can even kick off.


Very few projects with a fixed schedule and budget actually benefit both parties. Either the project falls behind because of faulty estimates (of effort and/or scope) and the service provider eats into their profits, or the project is deliberately overestimated by the service provider to account for contingencies and the client ends up paying way more to cover these potential surprises along the way (And if we put any stock in Murphy’s law, there will be surprises!).


In our VUCA world (an acronym for Volatility, Uncertainty, Complexity and Ambiguity), it’s crucial to be as flexible and adaptable to change as possible when developing software. Agile methods make this possible, for example by inverting the traditional “iron triangle.” Using a traditional (waterfall) model, the scope is determined, and then the schedule and budget are adjusted to fit. Following an Agile approach, the budget and schedule are established, and then the scope is worked out.


To ensure clients get the best value for their money, assumptions need to be validated as soon as possible. We can’t estimate what we don’t know, so we need to find out. The most direct approach is to deliver value to the client on a continuous basis while minimizing the feedback loop. The client will then be able, firstly, to see how the project is advancing with total transparency and, secondly, to decide which high value-added features to develop in the next iteration. That way, the client can control the budget and manage risks at their discretion. Estimates also need to be revalidated on a regular basis, depending on the system’s status and scope (if it changes). An estimate is uncertain, by definition.


But let’s get back to that one sentence and break down the different parts together: “Deliver value to the client on a continuous basis while minimizing the feedback loop.”


“Deliver” implies:

  • Functional environments for the service provider
  • Functional environments for the client
  • Development practices (including testing practices!) that are fully worked out


“Value” implies:

  • A dedicated product owner for the project on the client’s end, able to prioritize items to be developed based on business opportunities in the market and document them in a product backlog (or at least share their business knowledge so they can be documented)
  • Real users who can provide feedback to the product owner, ideally including performance metrics (time to complete tasks, for example)


“To the client” implies:

  • Collaboration
  • Transparency
  • Trust
  • Contract terms allowing for quick adjustments


“On a continuous basis” implies:


“Minimizing” implies:

  • Metrics
  • A continuous improvement process
  • Ideally, the client product owner will be on site with the service provider’s team
  • Regular revisions to the scope, asking what can be eliminated or simplified (with feedback from aforementioned users)
  • A test automation strategy, which ensures non-regression to prevent extra effort


“The feedback loop” implies:

  • Several iterations
  • Clearly established bidirectional lines of communication
  • Users on the client’s end to test the system after each delivery


With our initial estimate, we realize today that to define a fixed range project that operates on a budget and fixed length means huge risks for both parties. At first, it is very difficult to completely understand the scope. It unfolds as the project develop. How can we integrate this notion in the developing process? This is one of the founding elements at the core of Agility.


While constantly delivering value to the client is our priority, the estimation and the return on our continuous hypothesis allow us to clarify and narrow down this value. Together, these exercises ensure a framework for the scope relating to the budget and the calendar, and highlight the value and the quality of the application for the client. Because of his direct participation to the developing process, the client can really witness this value growing as the project reach its full potential.

Image Team Askida

Team Askida

L'équipe d'Askida / Team Askida