The problem we face when we think about dropping estimates is: how will we respond to the two main questions for the customers’ decision on whether he will accept to work with us or not: how much will it cost, and when will it be delivered.
In my opinion, this can be achieved if we start modifying the processes at the higher level. I will first described what is the common practice that I have applied or have seen applied so far, and how I think it could be changed for eliminating waste, and giving the customer control and vision on the price and schedule, without estimates!
We usually start working on the project when the customer has written the user requirements. They describe the high-level vision, as well as a general description of the different required features, often with an indication of the priority for each requirement. Then we are asked to provide a high-level estimate, so that the customer can decide if he will do the project or not.
After that, if the customer decides to go on with us, we work with him on the functional specifications and write a detailed document based on the exploration of the requirements, and several workshops to choose what we think are the best solutions in terms of features, quality and UX/UI.
The document describes in details what we will have to develop. It allows us to produce a revised estimate, based on the better knowledge of the work to do. In an agile approach the specifications document is light, but in any case it needs some time to be written.
There are many steps between the moment the customer has had the idea of making a website and the moment the first line of code is written:
- User requirements
- Rough estimate
- Go/no go decision
- Functionnal specifications
- New estimate/planning
- Technical specifications
In an Agile approach, the development is incremental and iterative, so there are many decisions and changes on the initial requirements, and specifications/user stories, during the development.
So the estimate and the global planning have to be revised very often. But the price and launch date have usually been agreed, so even with changing requirements we must fit to an obsolete estimate. One alternative could be that we intervene sooner in the project: at the beginning of the writing of the requirements.
When the customer already has a high-level vision of his project, it should really help him if we could write the requirements with him, instead of waiting to get the document before we begin studying it. For each requirement that the customer is thinking about, we could already give him an indication of the complexity, the feasibility, and help him making some triage in the priority.
With this practice, during the elaboration of the requirements, we could even begin the developement, which would help us test some asumptions about feasability, complexity, and missed features.
We could even agree with the customer that he is going to pay in an incremental way: each day of development and work on the requirements would have a cost.
The advantage for the customer would be:
- The development would begin sooner than in a traditional approach, almost some days after we begin writing the requirements.
- The customer would pay only for what we build, and decide by himself when he’s had enough, if he does not want to pay for more features, when to launch the website, when to make a pause in the development, and when to add new functionalities.
- The development would help define the requirements, and vice-versa.
- For each feature, from the beginning, it could be prototyped by the programmer, or incrementally developed and specified, and the associated cost would be known almost in real time.
I don’t know what you think of this kind of approcah, which I have never experimented, but I’d love to test it one day.