Web development: why noestimates is the way to go

Can I get an estimate for this?

We understand why our clients ask for estimates. No, really we do. Getting an upfront ap-proximate cost for a proposed piece of work can be important if you need to go cap in hand to a finance department. Clients also want to get a feeling of when some work will be done. And maybe estimates will let them work out which feature will cost them the most, so therefore help them decide if it’s in or out. Asking for estimates feels natural and we should try our best to get accurate ones so our clients can make informed decisions.

Or should we?

The great unknown

The team I serve was recently asked by a client to provide a “ballpark” estimate for a piece of software development.
We normally encourage face-to-face meetings with clients, but in this instance they’re in central Europe and we’re in the UK so a conference call was set up. I fixed it at one hour’s duration.
By the end of the phone call, we were no clearer about what the client actually wanted us to do for them. With so little information, there was no way we could size anything. I set up a second conference call for the following week.

Ever meet resistance from clients to #noestimates in Agile web development?

On that subsequent call, the client’s colleagues from other offices in other countries joined in. Again, we had an hour but with the added complication of fielding responses from a truly multi-national team, complete with the much-loved VOIP phone line time delay. Joy!
By the end, we concluded two things:
■ nothing beats a face-to-face meeting
■ we only had a slightly better idea of what the client wanted

After bidding farewell, we got our heads together and we finally agreed on the following action: to not estimate the work.

Don’t get me wrong; this doesn’t mean we refused to estimate. Far from it. After looking at the available data (of which there was as close to none as you can get without actually being none) and after two sessions during which we tried to understand the client’s key goals, we concluded that there was very little use in providing a number, even if just a “ballpark” one. Such a figure would have been misleading, ill-informed and, frankly, wrong.

So what did we do?

Be brave

When creating proposals for clients and prospects, you walk a fine line between keeping the client happy and keeping yourself and your business happy. Ideally, you want everyone to be happy and in agreement of what needs to be done.

However, your nerves are tested just before you reveal your estimate for the work. You agonise over the risks posed by not doing the work (because the client may reject your proposal) versus going for a low and unrealistic number so that you win the work (which equates to either a loss for your company, or lots of stress for your developers) versus winning the work, exceeding your estimate and potentially souring your relationship with the client. Surely there are easier careers!

The team convened. We debated the various approaches we could take. Another meeting with the client? Write some high-level user stories based on our current understanding? Admit defeat? Sell them three sprints? Sell them 10? We all agreed that we simply didn’t have enough information to provide any sort of estimate. We spoke with our business manager to find out the cost of losing this piece of work. He was happy for us to try what we wanted, even if it meant losing the client.

This is what we finally pitched (names have been removed to protect the innocent):

We have chosen not to specify a cost for the development of the aforemen-tioned outcomes as the level of uncertainty is too high to provide you with a reliable figure. However, all is not lost.
Due to the inherent uncertainties mentioned above, we will work with you for at least one sprint, ensuring that we deliver something of value to you during that time.

It will be up to all parties to ensure ongoing daily collaboration takes place.
You have the option of engaging with us for further sprints, and if this becomes the case, as each sprint concludes we will be more able to forecast which set of stories can be delivered. We believe that only by doing the work can we give you a forecast for when further increments will be finished (and therefore a better projection of future costs).
You have the option of disengaging with us at any time.
We believe this approach gives you a high level of flexibility. You can use us for as many sprints as you desire, or will fit within your budget, to get the most value from us without having to work to a fixed specification.

Those few simple paragraphs took us a good couple of days to forge. Each re-write was accompanied by a rational fear: “How will the client react?”

Let’s think about that fear for a moment

We ask our developers to use their past experience and knowledge to have a go at estimating work which, due to reality’s annoying habit of being causal, they have never done before. We know it’s flawed. We know that every single software project we’ve ever done comes complete with unseen roadworks, gotchas, impossible-to-find-until-the-very-last minute defects, gross misunderstandings, U-turns and zombies (OK, maybe not zombies). Yet a fear of losing the bid, or upsetting a client, forces us to forego common sense and past experience. We end up sticking our necks out to give a number, just because we were asked to.

“Sometimes, a very inaccurate estimate acts as a placebo: it will provide you with bad information that will make you feel secure, but when you realize the estimates were wrong it might be too late”
– Vasco Duarte, No Estimates

The Consequences

We felt we were giving our client full flexibility while at the same time acknowledging our uncertainty surrounding their requirements. Despite the inherent risk of rejection, the team felt this was the most honest approach. Hitting the Send button actually felt good. We weren’t making things up; we weren’t lying in order to win the bid. We were honest and truthful.

So we waited. And we waited some more.

After two weeks’ of waiting, the response came.
It wasn’t what we had hoped for, but the consequences were almost as good.

Dear team,
Thank you for your comprehensive summary.
I fully understand the approach and I appreciate open communication.
I couldn’t go at this point with your approach and had to assume a magnitude of the project.
I’m thinking about 8-16 iterations to get us there and this is, at the moment, the range I will communicate to my stakeholders.

The client had considered our approach and rejected it. But by doing so, he had considered instead a budget he could afford, expressed as a range. This is healthy. Such a budget provides us with constraints within which to work.

“Constraints force simplicity. Constraints force creative thinking. Constraints force you to focus.”
– Len Lagestee – illustratedagile.com

This, for me, is a win-win situation even if we didn’t get our ultimate #noestimates way. The team did not provide an estimate; the client dropped his requirement for an estimate and in-stead decided what he could afford to invest.

Our advice?

Be brave. Try what feels right, rather than what is expected. The consequences may surprise you.

Andy Deighton

After spending over 20 years wandering the wilderness as a software developer, Andy chose the path of Agile and is now safely camped at Bright Interactive, performing Scrum Mastery and serving teams to the best of his agility. He shares his personal experiences in the agile landscape over at scrum-boy.com.

I would love to get a star rating for this post:

Web development: why noestimates is the way to go
5 (100%) 7 votes

Leave a Comment

    • Lisa Jacobus
    • October 21, 2015
    Reply

    This is an excellent article around something that we face quite often in the software development space. I also agree with the honest approach and most clients/ potential clients I am sure would prefer the honesty and transparency.

  1. Reply

    Did you give them a price of a Sprint?

    Usually customer will find another vendor when the price did not fit their budget anyway.

    Appreciate the courage to speak about this in front of the customer.

    • Reply

      We give costs per sprint (or just our hourly rates).

      > Usually customer will find another vendor when the price did not fit their budget anyway.

      That’s what makes ballpark estimates (or indeed any estimate) so weird in presales. If a prospective client has a fixed budget then an estimate is unlikely to help them (or us) – what do we say if it exceeds their budget (and we are lucky enough to hear back from them)? “Yeah, but we kind of made up that number anyway, because we don’t know what we’re going to build yet, so you never know, it might cost less”.

      I’m beginning to think the best way for us to sell agile to prospects with a fixed budget (i.e. most) is to find out what that budget is and quote that (within reason!), and then spend the rest of our efforts convincing them that we have the right people and approach to build the best value thing for that budget.
      Perhaps there is a role for ballpark estimates- in trying to work out the budget of a reticent prospect. Say a number and watch their reaction closely. Joking aside, if a prospect won’t reveal their budget then our collaborative, transparent approach might prove tricky anyway.

      Martin

  2. Pingback: Trying #noestimates | Words of a Scrum Boy

  3. Reply

    I really like this article. Me and my colleagues have been in this situation quite often. And mostly we chose a similar approach by not estimating. But this always feels hard and makes you shiver a bit. But I think it’s the only honest way to deal with these situations.

    I linked your article in my Tumblr blog and shared it on Twitter since I’m really curious about the experiences of other teams.

      • Andy Deighton
      • July 1, 2015
      Reply

      Hi Roman,
      Shiver we did! But we were doing it not because we were refusing to estimate, but because it wouldn’t have been honest to do otherwise, given the amount of info’ we had. Thanks for sharing the article, too. Much appreciated.

      Andy

    • Reply

      Thanks :) I am sure Andy will be glad ;)

More from our blog

See all posts

Can a non-Tech person be a scrum master?

Continue reading

Demo – Anti Patterns

More a presentation than a review No review of timeline or budget…
Continue reading

Planning – Anti Patterns

No looking at previous velocitiy Blind acceptance of P0s proposal Backlog not…
Continue reading