#NoEstimates and the question of how much and when?

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
  • Development

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.

One thought on “#NoEstimates and the question of how much and when?

  1. First of all, it seems you have forgotten the whole purpose of why we’re estimating.
    The purpose of estimates is to get a sense of cost and when to expect it to be done. Estimates is not “a problem we face” when answering those questions – it’s *the reason* we do them.

    And, #NoEstimates is not about dropping estimates, but I agree, it’s easy to interpret it as such.

    Your approach seems quite fine. I think it’s pretty much how we’re doing it at my company already, although we don’t call it #NoEstimates. And to be honest, one of the first thing you mention in this post is “provide … estimate” 🙂 Seems impossible to “drop them” (as you say), right?

    When you say:
    “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.”
    Only paying for what we build is called “open price”. It’s what we do in our company already, but it has nothing to do with estimates or no estimates. We still provide estimates to give customer a sense of “how much and when”.

    Thus, how does the customer knows he will have something to release when money has ran out? When has money ran out?
    And what if the customer wants to drop some features before the project even starts? If one feature is larger than another, maybe he wants to focus on other features and pause some of the larger ones (even if they seem quite important) till next release? Maybe he wants to release something quickly over something with high quality or with everything in place?
    How can we help him with all this if we don’t estimate?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s