«
»

My Customers Need Estimates, What Do I do?

13th May 2013, 08:14 pm

It seems a lot of people have an argument against the “No Estimates” idea that goes something like this:

“Our Customers Need Estimates*”

There are many variations on this, but they typically come down to the same thing: We need customers, customers need estimates, therefore, we do estimates. The following are a few generic examples of this idea:

  • No customer will agree to hire us to write custom software for them unless we give them an “estimate”.
  • The reality of business is that we must give estimates to our customers so we can get work.
  • We must be good at estimates because our competitors are giving estimates.
  • The customer want’s to know if we can do their work at a price they can afford
  • The customer needs to know if they can make a profit based on the amount their software will cost, so they need an estimate.

How Can I Get These Customers Without Estimates?

This is a very easy question to answer: You probably can’t get these customers without estimates.  They want estimates – it’s part of the way they think. You probably MUST DO ESTIMATES for these customers.  That is, you don’t tell these customers “We don’t do estimates” if you want to work with them.

If you have chosen to work with the sort of customer that requires an estimate (or price) then give them what they want: an estimate (or price).  Your main job is to figure out a way to be able to make money taking on work for this sort of customer.  I understand that. You understand that. What more do you need to know?

A few points you might want to consider:

  • Are you willing to give an estimate/price for free?
  • Who pays for the estimates for jobs you don’t get?
  • How much extra do you need to “pad” the work for the “unknows”? Why should your customer pay for that?
  • Are you going to give a range?: “It will cost you no less than this but no more than that”.  Will you guarantee that?
  • If it costs you more to make the software than you estimated, are you willing to take the loss? Why??? If not, how will you deal with that? Re-negotiate the contract?
  • How do you know enough about the work to be able to give a resonably accurate price/estimate?
  • If a competitor shows them a better way, will they ever come back to you again?
  • That’s just a start – I’m sure we can come up with a lot of other things to consider.

If you choose to work following the “we must do estimates” model you are in good company (or at least in very numerous company), as there seems to be many who feel this is a reasonable way (or the only way they’ve found, perhaps?) to do business.

The Agile Way

I recently heard Jeff Sutherland do a talk where he mentioned the “80/20” rule – that “80 percent of the value is in 20 percent of the features” of a software project.  He quoted someone (I don’t remember who) as having suggested “we should just fund the 20% and not do the rest”.  I agree.  I’ll take it a bit further: I believe that the rule is more like “95/5” – that is: 95% of the value is in about 5% of the features, and that the people paying for the project will quickly end the project once that 5% is in use. Perhaps our goal is to pay as little as we can to discover and create that 5%.  So… how to do that?

Some choose the Agile way.  In this model, we recognize that “requirements emerge”.  If we can get good at allowing the more important and useful requirements to naturally emerge it pays off very nicely.

What does this have to do with estimates?  If I have to tell you, then you probably should be reading someone else’s blog.  But here it is: A customer who needs to “know how much it will cost” before they will decide to hire you to do the project might not be the sort who is willing to let requirements emerge.   It’s just not their way of thinking.  You might be able to “change them”, but probably not.

Not All Customers Require an Estimate (or price)

What it comes down to is this: You get to choose who you do business with.  If you choose to serve customers who need an estimate/price, then do estimates/prices, and figure out how to make that work for you.  If you choose to serve customers who are willing to let requirements emerge, then get good at the Agile way, and go for those customers.  It’s your choice.

Some of my other posts on estimates and “no estimates”

NOTES:

* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.

Category: Estimating, No Estimating, NoEstimates  |  Comment (RSS)  |  Trackback

12 Comments

  1. Amy Lightholder:

    Which opens a whole new conversation: how do you cultivate Agile customers? My current best approach is to find something small/known, and iterate from there. But that seems like bringing the process back to estimating (only trying to exert better control) rather than getting away from it.

    14 May 2013, 12:38 pm

  2. Woody Z.:

    Hey Amy! You make a great point: How do we cultivate Agile customers? Just as with any sales activity, you have to know the benefits of Agile and be able to sell the sizzle (as they used to say). Starting with something “small” makes sense for some customers – but I’m not sure that there is any need to make any estimates. This does require that the development house needs to have the ability to deliver on the promise of Agile: Discovery, emergence, early and often delivery of WORKING software, rapidly responding to change, etc. In other words, you must be great at discovering and delivering the 5% that provides the 95% of value.

    14 May 2013, 2:27 pm

  3. Lisa Crispin:

    I’ve been fortunate to work on teams that use estimates as they should be used – just estimates. IME they do help with thinking about ROI of features, and short-term planning.

    Now that I work on a team that produces project tracking software, I have more vested in estimates. Without estimates, you can’t have velocity, can you? And without velocity, how do you establish a cadence and rhythm? I like what Karl Scotland says about cadence and time boxing: http://availagility.co.uk/2009/07/21/what-is-cadence/

    Given that our product depends on a calculated average velocity to “plan” future iterations, or at least give an idea what the team might be able to accomplish in a certain iteration given the stories they’ve estimated – should we just give up on trying to suggest timeframes? I’m not being facetious, I’m really curious. I can see the “no estimates” viewpoint quite easily, but then I don’t know what it means for the tool I help create, which I also think is very cool.

    14 May 2013, 8:06 pm

  4. Woody Z.:

    Hello Lisa – thanks for reading and commenting on my post!!! I am honored.

    You cover a great deal in your comment. The main topic of this post is how to work with customers who require that we “give a estimate/price” for a project. There are many other uses of estimates in software development, and in this post I’m just covering one common use. However, I am suspicious of all use of estimates and feel the whole decision making process is something we need to continue to scrutinize.

    In software development, estimates are typically used to “inform” a decision. It’s my contention that this is of little value, and more typically estimates are anti-value. That is, that estimates “mis-inform” the decisions they are used to support. In the “Agile” world, there is a HUGE dependence on estimates, just as there was in the “waterfall” world. I find this interesting and a bit perplexing as the Agile approach is a way to work without estimates and focus instead on delivering working software.

    Things like velocity, planning future iterations, cadence, and time-boxing are all outside the scope of this discussion as far as I can see. However, just like estimates, there is no mention of any of these things in the Agile Manifesto (values and principles). I realize that at least some of the folks who wrote the manifesto were thinking in terms of iterations (Scrum, Extreme Programming, etc.) as well as things like cadence/time-boxing/etc. but they did not consider any of them important enough to include in the manifesto.

    Some companies/managers really like these ideas (cadence, velocity, time-boxing, iterations) and/or see value in them. I argue that these are also ripe for serious scrutiny. Many of these practices are simply “adopted” or applied “without thinking” when an Agile approach is introduced. I’d suggest it is better to start “bare”, and only add practices/processes/techniques to solve observed problems or improve capability as needed. Perhaps I’m a dreamer.

    Well… I’m almost starting another blog post here so I’ll end this before that happens.

    Cheers!
    Woody

    15 May 2013, 10:09 am

  5. Lisa Crispin:

    It’s also my experience that people (esp. managers) abuse the whole idea of “estimates”. It makes me sad every time someone asks me, “How can my team get better at estimating?” I want to say (and sometimes I do), “How about you focus on getting better at developing software?”

    If the people worried about estimating would put as much energy into, say, doing proper retrospectives, or nurturing an environment where learning and experimenting are encouraged, the software world would be a better place.

    At the same time, it’s helpful (though less important) to know what work is coming up, and have some way to make priorities visible so we deliver the most valuable things at the moment. If we don’t size stories, then I’m not sure how the business people can judge the ROI of a thing. Often in our planning meetings, someone suggests a feature, we talk about how big it is, and our PO might say, “if it were half that size we might do it but it’s too big to do now, other things are more important”. You don’t need point estimates to do that, but you need some way to express relative size, no?

    But I think what I’m saying is irrelevant to this particular post, as you point out. And I have to admit one reason I worry when I hear the phrase “no estimates” is I’m not sure how we’d make Tracker work without them. There probably is a good way, though.

    15 May 2013, 10:43 am

  6. Woody Z.:

    Hey Lisa!

    I like your approach: Focus on putting most of our energy into getting good at retrospectives and improving our overall environment for learning/experimenting. To me, that is the way to go.

    I see little value in using estimates of cost (money, effort, time, whatever) to determine ROI or to make a decision to work on something. If we get good at discovery and breaking off “work-sized chunks” then we can work on anything of value. The more valuable the better, perhaps, but for me: as long as we are working on something that has a good chance at being something “we’ll use” or “will want”, that’s good enough.

    The point is that if we get good at breaking off chunks we can quickly get “into use”, then we can discover and create the 5% (that deliviers the 95% of value) quickly, and avoid most of the 95% that is of little value. The decision to “not do it because it is too big to do now” sidesteps a huge benefit of “Agile”: “The Best Requirements Emerge”. That “too big to do now” item is probably hiding a number of “just right to do now” stuff – we just have to get good at breaking off “just right to do now” things. Some call this “estimating” – but I don’t. I don’t have to judge or calculate that “this will take a few weeks”. It just has to be clear enough that we can start writing code and tests. The “small bits” will reveal themselves as we work on it, and as we discover those we can complete and deliver them.

    Anyway – hardly anyone sees this the same as I do, so take all of this with a grain of salt.

    Cheers,
    Woody

    15 May 2013, 11:21 am

  7. Lukas:

    Yesterdays talk by Vasco Duarte about No Estimates http://youtu.be/H7alhgSXKDI

    3 June 2013, 7:04 pm

  8. Leslie J. Morse:

    The “no estimates” ideas has been on my personal backlog of things to read about since ScrumGathering in May. Its just now hitting the top of the backlog as I am dealing with a
    “scrummish” team that has an estimating challenge for a lot of reasons and I simply got to wondering… do they even need to estimate? Is there value in it? (working to explore that with them today)

    No matter their answer I keep coming back to the need to have at least some sort of projected Go-Live date for the product. This is important because so many of the groups I work with have lots of dependencies to coordinate when it comes to actually getting something into production.

    So I ask, if I go down the ‘no estimates’ path – what is your suggestion for forecasting potential finish dates?

    21 August 2013, 6:40 am

  9. Dimitar:

    I usually work with clients that do need estimates. My approach is to simulate the new project using Monte Carlo and historical data. H
    I have put together something on how one can do it:

    The presentation can be seen here :
    https://www.slideshare.net/dimiterbak/noestimates-project-planning-using-monte-carlo-simulation

    And here is an Excel file to show how Monte Carlo is done http://modernmanagement.bg/data/NoEstimate_Project_Planning_MonteCarlo.xlsx

    Here is a video I prepared in order to help people understand how to plan a release using the Monte Carlo simulation in MS Excel :
    http://youtu.be/r38a25ak4co

    Here is the next part on high-level project planning using Monte Carlo simulation.
    http://www.slideshare.net/dimiterbak/high-level-project-planning-using-monte-carlo-simulation

    Previous part was about preparing the SIP of Average Takt time distribution for the 2nd leg of the Z-curve and now I show how we can predict project delivery time by running Monte Carlo simulation on all three legs of the Z-curve.

    Here are the SIPs for the baseline project http://modernmanagement.bg/data/SIPs_MonteCarlo_FVR.xlsx
    Here is the planing simulation in Excel http://modernmanagement.bg/data/High_Level_Project_Planning.xlsx

    29 May 2014, 4:15 am

  10. Mikaela Hedberg:

    Hi Woody,
    Thank you for a great post on a subject that is very central in my professional life. I work at a consultant firm where we sell “agile projects”. The problem is that we sell “agile projects” the traditional way – by giving the customer a price based on estimations. Even though estimations are called just “estimations”, somehow the customer tend to put more truth in them than there can possibly be at such an early point. You can see how this creates problems in the future of the project. I get such an agile project in my lap and the customer expects it to be an agile/scrum project – but it already has set estimations that in fact are very hard for everyone to see past.

    As you write – customers expects to get a price, and prices are based on estimates. At the same time my firm wants to offer agile projects to customers. I see this as an equation that just doesn’t add up.
    This post gave me some ideas, some new angles to look at in this problem and I thank you for that (also thanks to the comment by Dimitar, I’ll sure check that Monte Carlo simulation out too).

    It’s very tricky business, to build customer trust enough to sell projects in the true agile way. In my world, the customers who are willing to let the requirements emerge aren’t very many and I think we’re afraid even to suggest such approach, since it’s not what we’re used to.

    26 June 2014, 11:53 pm

  11. Bob MacNeal:

    As an itinerant developer, I’ve been on a quest to find customers hip to the no estimates advantage. In my experience, startups tend to be more savvy about what’s truly needed than stodgy organizations that are brimming with PMs and Agile-Schmagilists.

    When asked for estimates, I throw out a number within the range the askee would like to hear, then I promptly forget about it. It flummoxes me how serious estimates are taken by the people collecting them. If they only knew how little thought many of us put into providing them. Estimates in the software space are a huge red flag for me that I’m working with people who are green, if not clueless, about what it takes to produce software.

    9 July 2014, 5:54 pm

  12. Woody Z.:

    Hey Bob! There are people who understand these things, but we are still in the infancy of this. I see that “red flag” as well, and I’m encouraged to see that people are at least talking about this subject across the entire software development world.

    Cheers!
    Woody

    10 July 2014, 7:19 am

Leave a comment