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.
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?
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
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.
Be brave. Try what feels right, rather than what is expected. The consequences may surprise you.
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.