27 June 2011

Build Work Around Teams to Solve the Estimating Problem

Some teams are moving away from forming, closing and reforming teams.  In this instance you may have variations in the total size of the team (as peaks and toughs in demand call in temporary support) and the work varies from maintenance of a set of legacy systems to new product development and other things, but you also have something really valuable: Continuity.

People have been making a big deal about the value in keeping working teams together based on the team effectiveness that grows over time.  I buy into that.  But I want to amplify the case for building work around teams rather than vice-versa by highlighting that the established teams also come with established capacity and estimating standards.

Take your team today for example.  Look back at your history and assuming you've collected the data you'll be able to work out the average size of a project (Days, T-shirt sizes, dog breeds, or my favourite - types of beer.)  You'll see that you team addresses X number of requirements per month.  You don't even need to be working in iterations.  You just have to be releasing software to get measurable start & end data.
  • How many requirements were addressed?
  • How many weeks work did it take?
Is this a reasonable sample size?  Once a team has hit a controlled rate of delivery, you've sufficient data to estimate for the future.

A caveat to my position: By team I include the person who is managing the requirements that flow into the team.  The quality and standards around requirements are probably the most variable aspect of many project teams, and it's just as important to normalise the requirements as the solution delivery work.

No comments:

Post a Comment