How to Give Better Estimations to Customers

Question

We are working in an environment where customers give us thick requirement documents and they expect the technical team to do an estimation on the whole requirement. Once they receive our estimates, they can approach the budget team to ask for the money according to the estimated effort. They have been doing this for more than 15 years, and recently there have been some talk to move to a more agile process.

This practice of BIG estimation up front will be the first thing that they have to deal with among other things. The big question that they are trying to solve right now is "how can they advise the customers that we can't give them full estimates up front?" Agile process relies on simple, easy to estimate stories, where each story carries a certain estimates - well at least this is how stories are defined in XP.

Following XP principals, the technical team should not produce a big estimate up front, rather they should break up the requirement into stories. If this is the case, how can the customers get full estimates and ask for budget?

Is this where Agile process need to be tailored, or mixed with another practice to make things work?

Answer 1

I don't think there is any secret to estimating or sharing the estimates...

1. Estimate in as small a breakdown as possible with the customer
2. Always look at the same problem from multiple views (create multiple estimates from different perspectives - architectural perspective, UI perspective, group think, top down, etc etc.)
3. From the above and with the team, generate a "graph" of with "level of confidence" on the X axis. The graph will look a little like the tangent curve from trigonometry (at 99% confidence, your estimate will be huge, at 1%, it will be very small)
4. Review the confidence curve with the customer. Work with them to establish the estimate. They can choose a lower estimate, but they need to understand there is a smaller chance of delivery.
5. Establish a buffer with the customer. That is, drive the team to an internal (unbuffered date) and commit to the external (buffered date)
6. Manage the buffer (complex, but since this is about estimating, I'll just leave it at that...)

Always get comfortable with generating an estimate even with limited information, but never give a single number. Generate the confidence graph every time, it will help convey the level of uncertainty in the estimate, and gives you an opportunity to engage the customer in dialog that will help you manage the project.

The real "trick" in Agile is that a customer shouldn't care nearly so much about the -cost- of development, and instead focus on the -benefit- of having the product with the feature built in. By working in small chunks and keeping "in progress" work to zero and always having a deliverable product at the end of an iteration, the customer can always say "thats enough benefit for me now, lets move on..." and moving on might be "ship it!" or some other feature.

This, however, requires you to change the mind of the customer to adjust to this mindset. I know of no magic for that!

Answer 2

I usually do a release plan prior to, or very shortly after a project starts.

Sit down with the stakeholders and write some really high level stories (you'll see them called epics in some places, personally, I hate the term). Essentially, you're looking to brainstorm the key features in your product.

Get the stakeholders to prioritise them - I usually insist on linear priorities (that is to say, no two things can have the same priority). This gives you an idea of scope and an idea of ideal delivery order.

Now sit down with your dev team and lay out all the stories in priority order. Rather than estimating each story, just get them to draw a line after what they expect to be a couple of weeks work. The devs should be factoring in thinking time for the more unknown tasks. It's a good idea to have a flipchart to capture dependencies, risks, assumptions and spikes needed too. Keep going down the list, splitting the work into 2 week segments as you go through. When you get to the end, you have an idea of how much the whole project will cost.

At the end, check the devs are happy that the final figure sounds about right. If not, re-visit and refine. It can be useful to have a stakeholder in the room both to answer questions and to give them a better feel of the reasoning behind the final figure.

In terms of reporting the result back up the chain, you need to factor in the risks, dependencies and assumptions. If possible, express the result as a range, with the difference between your lower and upper figure reflecting the number you've identified.

If you can spend the time, it's a great idea to do an inception phase, although I from your question I'm guessing you're looking to do this at a point where there is no go-ahead decision for the project so getting the time needed would probably be difficult.

Of course, ideally, if you're only doing this for financial sign off, you should try to work with the finance guys to come up with a better system. If your projects currently run over budget reasonably regularly, they might be quite receptive to looking at ways to improve the system of requesting and granting sign off to something that suits all parties better, depends how open your organisation is to change.

Answer 3

There is nothing wrong in "big estimate upfront". The problem is that in most cases people don't understand how to manage accuracy and precision of estimates. How about this big upfront estimate:

"1000 man-days, 150% accuracy/precision"

Answer 4

zfranciscus I don't think there's anything wrong with people asking for an estimate up-front. I believe the root cause lies with the "thick" requirements document. We just don't know everything up-front, many of those requirements in the reqts document are likely waste (not needed, never will be used) and some reqts that should be in there are not.

The classic approach is to abstract the detailed requirements to a higher-level (as Ben advocates above) allowing yourself flexibility in the details.

The problem is that this does not address the real problem. The "thick" requirements document is a safety blanket. Those creating it believe this is the only way to be successful and perhaps they also believe that if they don't get all the reqts approved before the baseline is approved it will cost them a lot of money. It is always difficult to address these fears through conversation. The very best way is to get people involved and demonstrate by doing (running a few iterations).