This post originated from an RSS feed registered with .NET Buzz by Chris Flaat. Original Post: Trying to tame our estimates Feed Title: Chris Flaat's Weblog Feed URL: /msdnerror.htm?aspxerrorpath=/cflaat/Rss.aspx Feed Description: I mainly discuss tips & tricks about VS 2002, VS 2003, and upcoming versions of VS. Latest .NET Buzz Posts Latest .NET Buzz Posts by Chris Flaat Latest Posts From Chris Flaat's Weblog

Greetings all – 

It would seem that our estimates are slowly getting better with time.  When I compare the burndown chart for sprint 5 with the prior three charts, it’s quite good.  The first three look like a silhouette of the Olympic mountain range, whereas sprint 5 trends downward fairly nicely.  Sprint 5 is showing a fixed “drag” that is causing us to tick off less time than we had predicted (say, .75 days of work per actual day instead of 1.0), but this has led to a fairly steady sequence of getting behind, doing a cut, being caught up, slowly getting behind, and so forth. 

The next step, of course, is to better account for this “drag” and try to account for it in sprint 6.  What seems to be happening is not so much that the expected items are taking longer than expected, but that we are spending time on things that we didn’t account for in the sprint backlog.  This is right in line with what DeMarco & Lister say in chapter 9 of Waltzing with Bears (a book that I highly recommend), which is that most software project managers do a decent job of estimating the tasks that have to be done, but a lousy job of estimating that tasks that might have to be done. 

Much of the things that are causing us to tick off less than a day per person on sprint backlog tasks are “overhead” items that we never before tried to quantify: reading e-mail, answering questions from internal and external users, doing code reviews, attending meetings, etc.  We did have some blanket items for certain things (e.g. 2 days for unexpected high-priority bugs), but the list was incomplete. 

Going into prior product backlog selection meetings, we had only the most vague calculations of capacity and overhead, which was OK but not good enough, as we are seeing.  So I’m thinking that going into the next meeting I’ll work with the team to cook up a more comprehensive spreadsheet which accounts for both definite overhead (e.g. time in meetings) and possible overhead (e.g. build breaks that we have to respond to, unplanned absences, etc. – the kind of thing where some of them will occur but not all). 

The items which represent possible (but not certain) overhead are quite interesting.  I’m using some concepts from Waltzing with Bears to try to deal with this.  I’m not using their all-out risk diagrams, but simply planning to take possible items and multiply the cost when realized times the probability of occurrence, which should give a reasonable “risk mitigation reserve” on the schedule. 

I should also comment on my motives here.  So far there hasn’t been any attention to our estimates from higher-ups – if there was, I’d say we already stack up quite well against other teams in our product unit & division.  However, the people who seem to be most stressed out by our running behind is the team itself, and ensuring that they’re not feeling constantly “in the crosshairs” is very important.  Thus I see better estimates as a way to help avoid “behind schedule” situations (which are bad for everybody). 

More work has to be done on this, but I’m hopeful that our estimates can be much better for sprint 6.  I expect this subject to come up from team members during the sprint retrospective, as they’ve already been bringing up the issue of overhead that is important but not accounted for. 

Over & out!

Chris