Creating Trustworthy Estimates
Do the people who ask you for estimates trust your estimates?
It's difficult to build trustworthy estimates. Here are three tips you can try for estimates that work for you, not against you.
Tip #1: Never provide a single-point estimate.
When people ask me for an estimate, I provide a percentage confidence or a three-point estimate. I use the percentage confidence when they want to know, “Can you meet this specific date or budget?” I can be very confident close to the end of the project and much farther away at the beginning of the project. When I say, “I have a 50% confidence in that date–that means I am sure we can get about half of the work done, but I am not sure at all about the other half,” the requestor understands the problem.
I often provide a three-point estimate when it comes to schedule. “This date is possible, but it's not likely. This other date is likely, but not guaranteed. I am very sure we can make it by this last pessimistic date.” People might not want to hear these qualifications on dates. In my experience, when you train people to hear estimates with reasons, they are more likely to trust your estimate.
Tip #2: Ask the people who will do the work to estimate.
Have you ever noticed that if some work is easy to discuss, some people think it's easy to do? If people outside your project estimate the apparently easy work, they might underestimate the work for your project team. If you make commitments to anyone based on those estimates, you could be in trouble before you even start the project.
You might discover over time that a specific team over- or under-estimates. If the team has that history, ask them if it's okay if you increase or reduce their estimate, based on history. Show them their history. And, try Tip #3.
Tip #3: Plan to iterate on your estimate as you learn more.
I wish the world didn't change when I have to estimate something. But, it does. You can change your estimate based on new information or changes. If you plan to estimate and explain to the people who want the estimate, “This looks like our estimate for now. I will know more in a month. Do you want another estimate then, after our demo?”
Now, you've set their expectations about what they will see and when you will update the estimate.
Creating estimates that people trust is difficult. You can persist and explain what your estimates mean. If you deliver working product as you iterate on your estimate, you build trust.
More Learning With Johanna
If you liked these tips, learn more with Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. The book is available everywhere now, in ebook and print formats. (Those of you in Canada might have to wait a couple more weeks for print.)
If you are looking for information about estimating a large program, take a look at my book in beta: Agile and Lean Program Management: Scaling Collaboration Across the Organization.
I am speaking July 21 at Uberconf in Colorado:
* Design Your Agile Project
* Tuning Your Agile Team
See my calendar page for all my workshops and speaking dates.
New to the Pragmatic Manager?
Are you new to the Pragmatic Manager newsletter? See previous issues.
See my books page for my books. If you see one that interests you, and you would like me to speak about it, let me know.
Do you need a friendly ear and some sound advice? See my coaching page for my packaged and customizable coaching services.
See my workshops page for my workshops.
I keep my blogs current with my writings: Managing Product Development, Hiring Technical People, and Create an Adaptable Life.
Johanna
© 2015 Johanna Rothman
Johanna, there are several kinds of estimates here — target calendar date (useful for management/customers who need to plan for arrival) and resource estimate (relevant for developers, who are knowledgeable about how many hours of time it might take). It is challenging to correlate the two.
As a software dev manager, I feel one of the most important skills for each team member is that they properly understand how to provide accurate estimates of their own work items. Even if the guesses are initially somewhat arbitrary one should assume over time that these will improve in accuracy as long as they are tracked and similar work is estimated in the future. However, I have been disappointed too many times to count.
As a manager I have an idea of how many hours I “am willing to invest” for a certain person to perform a certain unit of work. For example, I might inform a particular developer that I expect the login dialog will take between 8 and 16 hours of their effort. This is not my ‘wishful thinking’ but a reflection of how “good” I want this feature and considering the skills of the person assigned the work. I ask for an estimate from the developer and then a conversation should ensue if the estimates do not reasonably overlap (because surely if I am making mistakes in my estimation then I need to adjust as well). If the estimates jibe, but there is room for optimization, then various accelerating techniques might be applied (find sample code that performs nearly the same task, pair program with a person experienced in this area, etc).
We used to apply multipliers to estimates based on whether the person had ever done similar work before, or knew someone who did, or whether this is something no-one else has ever tried before. Perhaps it was because most of what our team did was novel so a large percentage of time was spent googling, a clear indication that estimations might be unreliable.
Even with all of this, the developer-supplied estimates rarely match the actual time spent. It is frustrating for everyone. What techniques do you suggest for improving estimation accuracy among team members?
Ken
Hi Ken, I wonder this: Have you asked people to provide you a three-point estimate with different criteria for done-ness, instead of bounding their estimate?
I have been in your position before. Years ago, I decided to ask people to develop inch-pebbles so I would know that they had thought through what it would take to deliver the feature or task. (This is before agile, so we did a mixture of features and tasks.)
When they did, I could say, “I don’t need this piece. I do need that part. Hmm, why do you need to do this thing? I would have thought the work would end here (3 steps before the work was done).” We discussed. Often, I was wrong. The developer (or the tester) needed to finish the rest of the work to have the result I wanted.
I started asking for the results I wanted. “I want a prototype of this thing and it only has to do these three things, please.” The developer would say, “But, doesn’t it have to do these other 15 things?” I would say, “Not yet. Just these three.”
I started to put criteria on milestones or inch-pebbles. I am not good enough as a manager to help my people understand what I mean by “good enough” if I don’t say it.
I worked with people on their estimates, making sure I was explicit about what I wanted. (Sometimes, I timeboxed the work. “Please spend no more than 5 hours on this.”)
Estimates are wrong for many reasons. One of the most common is multitasking. If your people bounce between two tasks (or more), no estimate can be correct because no estimate can account for context switch time.
If you want people to estimate better, ask them to deliver results, any one of which is small and they will do sooner rather than later. (See What Model Do Your Estimates Follow?) Make sure the person understands the criteria by which you (or someone) will judge done-ness. Make sure the person doesn’t multitask.
Once they practice these approaches and check what the actual was, they will learn how to estimate better. They will be better at estimating longer/larger/farther out work. The larger and farther out, the more of a guess they will have.
Oh, one more thing. Many technical people think a person-day is 8 hours. It’s not. The best a person-day can be is 6 hours. In my informal assessments at my clients, I see a “day” of work range from 3 hours (tons of meetings and multitasking) to 5.5 hours.
Estimating is a non-trivial piece of learning how to manage your work. Sometimes, the environment at work is what creates difficult estimation.