I’ve been teaching workshops these last few weeks. A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.”
I have found that the smaller the work, the better the estimate. If people work as a team, they can provide more accurate estimates than they can alone. And, if they work as a team, the more likely they are to meet the estimate.
The people in my workshops did not want to hear this. Many of them wanted to know how to create an estimate for “their” work, accounting for multitasking.
I don’t know how to create great estimates when people assume they work alone, or if they multitask.
In all of my experience, software is a team activity (especially if you want to use agile or lean). For me, creating an estimate of “my” work is irrelevant. The feature isn’t done until it’s all done.
When we create solo estimates, we reinforce the idea that we work alone. We can work alone. I have discovered I have different ideas when I pair. That’s one of the reasons I ask for review, if I am not actively pairing. I have also discovered that I find problems earlier when I pair or ask for frequent review. That changes my overall estimate.
Multitasking creates context switching, with built-in delays. (See Cost of Delay Due to Multitasking, Part 2 or Diving for Hidden Treasures.) I don’t know how to account for the context-switch times. For me, the context-switching time varies, and depends on how many switches I need to do.
If you want to create great estimates, estimate as a team. For hints, see Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Cost or Schedule.
I urge you to make the thing you estimate small, you consider how you work with other people to deliver this thing, and you do one chunk of work at a time. All of those ideas will help you create better estimates. Not for “your” work, but for the work you deliver to your customer.
