Rothman Consulting Group, Inc.

Volume 12 #5: Creating Trustworthy Estimates

ISSN: 2164-1196
Posted by johanna

2 Replies to “Creating Trustworthy Estimates”

  1. 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?


    1. 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.

Leave a Reply