Getting Good Estimates

We use Microsoft Team Foundation Server for tracking our activities during our sprints.  You can jump over there to read up a little about this if you have never seen it.  One of the areas that we are focusing currently is estimating how much work we can realistically get done in our two week sprints.

We started tracking our work to the half day level a few months ago.  As an aside, there are several schools of thought on how to track this type of activity.  You can track by the hour or the day is one example, and there is even a difference of opinion for how to track items that will take more than 1 day.  Some folks say just use the best estimate you have, and others say always round up, and even debates about using the Fibonacci sequence for scheduling.

Where we have focused has been on two areas:

1. Simply creating a task for everything we need to do.
1. An example here is a couple of our folks are working on documentation for a new feature we are trying to start.  Each of them devoted X number of days to get the documentation done.  So far, so good.
2. The problem was that the entire team needs to read, review and respond to the documentation.  We had not devoted any scheduled time to that work in the past.  If we each need 1 or 2 days, that is a large percentage of a 2 week cycle.  We learned our lesson in the past so we devote dedicated time here.
3. Other examples would be blocking time for code reviews (more time if we know a particularly complex change will be attempted in the sprint), time for hackathons, etc…
2. Once we have those estimates, TFS gives us a summation of how much time we have and how much work we are adding to a sprint.  If we have 100 engineer days, for example, we should not try to take on 120 days of work. 
1. We have tried this in the past and it seldom works.  The extra work simply gets carried over to the next sprint, but having that long list makes prioritizing difficult. 
2. Plus, if we have a work item that partner teams need done, the state of it should accurately reflect when a change would be expected.  By pulling it into the current 2 week cycle, stakeholders may reasonably expect a change within 2 weeks.  We have worked to avoid this situation.

So now we have the correct number of work items, all with our best estimates attached on the first day of the sprint.  We take the highest priority items in first.  (This assumes we have an accurately prioritized back log of work items, which we have).  So far our burndown charts show that we have decreased our range of estimates by about 75% - we are 75% more accurate now than 2 months ago.  We'll keep iterating to get this number more accurate over time.

Questions, comments, concerns and criticisms always welcome,

John