Gunnar Kudrjavets

Honestly estimating time available for software development/testing tasks

Prologue

Microsoft Speech Server 2004 is set to launch and I'm looking back on how it was to work on this product. For last 2.5 years my full-time job has been to carry out the duties of PHB. In addition of writing code now being a guilty pleasure for me ;-), this also means that I spend fair amount of time dealing with things like:

• Giving the estimates for certain tasks,
• Changing these estimates based on some events,
• Justifying my estimates to anyone who asks ;-),
• Providing constant status updates to my superiors about the status of the project, and
• Comparing my initial estimates with the actual time spent and trying to understand what I missed while doing my initial analysis. This is usually the phase where I beat my head against the wall and yell: “How didn’t I think about this earlier? Bad Gunnar, bad Gunnar!“

When I'm being asked to estimate anything then one of the first things I usually do is try to figure out how much actual working time I really have? I know it sounds a little bit naïve. This isn’t a complicated problem, just count the days in calendar, right? Month is a month of development. Two months are two months of development time and so on. Well, actually it’s more complex than it sounds. Software estimation in general is a tricky beast. I’ve spent pretty noticeable portion of my life working nights and weekends because of unrealistic schedules or the estimation mistakes I made because of my own incompetence. Edward Yourdon's “Death March“ is a book I try to reread every four-five months or so to motivate myself to spend enough time on just thinking before doing anything ;-)

Honest estimates

There’s something I call “honest estimates” i.e., realistic estimates about how much time there’s really in schedule for getting the real work done e.g., how much time developer really has to design a solution, write code, debug something, fix bugs etc. I don’t use anything fancy (ever heard of COCOMO II?), just common sense to figure out the amount of available resources. Is there anything new I have to say about this subject? No, just some pragmatic recommendations which are proven to be successful in my immediate workgroup. Bertrand Russell once said: “Most people would rather die than think: many do.” The first thing I’m negotiating with my superiors is trying to establish what expectations are made in regards to working hours. I usually try to negotiate towards 8h per day and five days a week schedule. Organizational culture may vary, but to be able to estimate correctly anything at all, you need to get sign-off from people to whom you report that they agree with your assumptions. Working 40h a week may not always be the case, sometimes 60h is expected, sometimes 80h is expected etc. It depends. The main thing to take away from this is that everyone in your organization should be clear what the expectations related to working hours are.

Enough theory, let’s get down to business. To better understand how I do my basic estimations; let’s look at the hypothetical development team consisting of Alice, Bob, and Eve (crypto people, sounds familiar?). Let’s say that we need to estimate how much each of these individuals will have time to do the real work during March 2004. So, I start out by writing down how much calendar days we have in month and how much of them are weekdays:

Simple thing, but I just wrote down an assumption that nobody will work on the weekends. Next thing I do is check for following: a) Do we have any official holidays in March? Let’s assume that March 12th is for example Elbonian holiday and the entire team will get a day off. b) Does anyone have any vacation plans? Let’s also assume for the sake of the exercise that Eve wants to take a week off and visit her parents (from 03/15 till 03/19). This gives us the following:

What else is time not spent working? Sometimes people take professional training sessions to learn new skills. For example Bob may decide to take a 2-day training course (from 03/08 till 03/09) about how to write secure C# code. As his manager, I fully support this idea ;-) Also I may notice that as a morale event the entire division is scheduled to go to the movies on March 25th. This is a time not spent writing product code. Let’s adjust our estimates once more:

Now I start thinking about how much meetings we actually have in our team? Usually there are: a) A weekly 1:1 session between individual contributor and his/her manager (let’s say it takes 1h) on Monday. b) Weekly team meeting (another hour) on Tuesday. c) Bi-weekly meeting for bigger workgroup (yet another hour) on Friday. For Alice this means five 1:1-s, five weekly team meetings, and three workgroup meetings – total 5×1 + 5×1 + 3×1 = 13 hours of time spent not working in her office. For Bob it means four 1:1-s, four weekly meetings, and three workgroup meetings – total 4×1 + 4×1 + 3×1 = 11 hours of time spent not working in his office. For Eve it means four 1:1-s, four weekly meetings, and two workgroup meetings – total 4×1 + 4×1 + 2×1 = 10 hours of time spent not working in her office. Let’s say that all these meeting won’t take a full hour and round the time down as one working day lost in meetings and preparations for meetings. This gives us the following:

This is where I usually stop and say that the precision achieved is a good enough for me. There are a number of other things which I could theoretically take into the account:

• Business trips.
• Possible power outages in the building.
• Sick days.
• Time off because of personal reasons.
• Unplanned meetings.
• ...

I’ve taken the approach that I count these events as non-working time when something actually happens and then readjust my schedule accordingly. This has proven to be good enough. Summa summarum, currently I have something with what I can go to my superiors and say: “Actually we don’t have a full month – Alice has 20 weekdays available, Bob 18 weekdays, and Eve only 15 weekdays available. Therefore I can only get done this much.” It's kind of hard to argue against these basic facts. Fortunately I’ve been extremely lucky in this sense that because of some strange reason, people I work for have agreed with my style of estimation (which is just common sense and nothing else). Skeptic reader can have a question about this approach working in real life? The track record of my team shows that we haven't missed a single date during last two years i.e., everything we promised to accomplish by certain date, we did. There were cases when we were forced to readjust the dates because of the reasons not directly under our control, but we were able always to provide heads-up to relevant parties' months ahead of a time.

Problems with this approach

First time I went to the review meeting and presented my estimates, I was very scared ;-) Imagine telling some number of influential people that you will actually get done twice as less as everybody is expecting you to do. The best approach which helps to overcome the tension is being able to justify every damn thing you say and being able to offer alternatives. For example:

• If we would cut Bob’s training then we can get feature A implemented, but Bob won’t probably be very happy with this.
• We can assume that during March the team will work 60h a week, but this will have an impact on morale and work-life balance.
• We can cut the bi-weekly workgroup meeting and therefore have more time for debugging.
• …

Epilogue

This was just scratching the surface when it comes to software project management ;-) In my personal bookshelf there are lots of scary looking books covering related subjects in very detailed manner and I don't want to retell them. My main goal will be to write some posts about the things which seem to be working for my team and are simple enough to cover in blog.