Estimating Tasks
This week, a lot of Atalasoft went to AIIM. During such times, the office is quieter than usual and we, who have been left behind, try to do something to cheer up the atmosphere or to make those at the show jealous. Even better if we can manage both. Christina and I decided that instead of our usual Bacon Day, we would get hot wings for whoever wanted them.
We got a headcount, called up E.B.’s and placed the order, guessing that it would take an hour to go get them and bring them back. As I was driving down, I couldn’t help but think that this whole process is not a lot different from estimating the completion time of software.
I’ve heard a lot of engineers (and good engineers, mind you) make the claim that they are bad at estimating tasks or even can’t do it at all. I am not one of those people. I very confidently make estimates and stick by them. Usually, when I estimate, I have three main parts of the estimate: low-ball, high-ball and SWAG.
So here’s your task – estimate the total cost of getting lunch for your office. Work out ahead of time both how long it will take and how much it will cost. How do you do this? First, you need to figure out certain requirements: headcount, food source (restaurant, store, roach coach, etc), travel time. Second, is there any way to simplify elements of the task – one food type for everyone (i.e., just hot wings or a deli plate), or one payer? What things can go wrong in the process (restaurant closed, bad traffic, long line)? Can you sort those problems into bins of likelihood? Are there proactive things you can do to eliminate unknowns or cut overhead (internet/phone order, prepay, request delivery)?
Given all of these things, you should be able to either have some very confident numbers or have some clear unknowns. The unknowns will give you and idea of best and worst case. Here’s an example of a reasonable request that injects a huge unknown, “If they have a good soup, get me that otherwise just get me a sandwich.” This is not insurmountable and there are a number of ways to account for it. One way is to show up and pick whatever soup they have. Another is to just get some other sandwich. Another is to show up, ask the soup, call your colleague and ask if they’re OK with that then call back with the sandwich options. Another is to have your coworker call you while you’re on the way with his/her choice. Another is to veto the option at the beginning (NO SOUP FOR YOU!). All of these are valid solutions. Which ones are best for schedule, cost, morale, etc?
In the case of wings for lunch, we got a headcount, estimated a total number of wings per person, checked the menu, called in, placed the order (making the selection for the group), got the cost on the phone and the time until it was ready, check Google Maps for the travel time, and added time for waiting in line (I would be showing up at lunch rush) and a couple minutes to spare. The total time until arrival was within a few percent of the estimate. Why wasn’t it perfect? On the way back, I hit every single red light on the route except one and the exit ramp off the highway on the way back was under construction and backed up. Fortunately, I hit no red lights on the way down and made good time on the highway.
More importantly, I asked myself the question. The way to get better at making estimates is to make them and botch them royally and learn from your mistakes.
There is a quote I saw many years ago taped to a file cabinet in a managers office, “feed your troops and they will fight like hell for you.” Getting lunch for your team is a literal interpretation of this, but in the bigger picture, providing the opportunity to improve at what they do every day is another way to make that happen. I used to do estimates for our whole team. I try to no longer be that crutch and instead try to guide estimates. And fortunately the Agile Process through burn down tracking allows you to catch problems earlier and intervene if need be.