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
sequence for scheduling.
Where we have
focused has been on two areas:
Simply creating a task for
everything we need to do.
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.
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.
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,
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.
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.
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.
concerns and criticisms always welcome,