This post originated from an RSS feed registered with Ruby Buzz
by Jay Fields.
Original Post: Agile: Estimating
Feed Title: Jay Fields Thoughts
Feed URL: http://blog.jayfields.com/rss.xml
Feed Description: Thoughts on Software Development
A blog entry from you on "estimating" and how you go about it (for various types of stories/buckets) would be a big help.
On the projects I'm generally involved in each story is estimated twice.
High level estimate A high level estimate is usually helpful when a story is created. The high level estimate can be used to determine where it belongs in the current release (or in a subsequent release). I prefer that high level estimates be done by 3 or 4 developers. I also prefer the estimation scale be the same as the scale that will ultimately be used for the iteration estimate (i.e. don't use small, medium, large for the high level estimate and 1, 2, 3 for an iteration estimate). A high level estimate usually begins with a subject matter expert (often an analyst) explaining the details of the story. These details aren't the full details of the story, but the key aspects that effect the estimates. Following the explanation and any questions, the devs will independently determine their own estimate for the story. If all the devs agree (or are close) then you move on; however, if the estimates are wildly off then a conversation is had and the independent estimation process will occur again.
Iteration estimate An iteration estimate is helpful for getting the entire team on the same page and determining which stories will be played in the next iteration. At ThoughtWorks we generally have an Iteration Planning Meeting (IPM) before each iteration. During the IPM the subject matter experts (again, usually analysts) explain all the details of the story. Following the explanation and any questions the entire* dev team will independently estimate the story. If the estimates are consistent, you move on, otherwise more discussion needs to occur and the independent estimates need to happen again (just like high level estimates).
Having 2 estimates is helpful for a few reasons. While the original estimate is good for planning purposes, the iteration estimate is better for determining what goes in the upcoming iteration. The iteration estimates should be more accurate because more people have the chance to participate in the estimation process, and (it's likely that) more information is known then when the high level estimate was taken. Given more accurate estimations and a known team velocity, predicting what can be done in each iteration should be a fairly easy task. Also, it's valuable to track if the high level estimates are generally lower or higher than the iteration estimates. Knowing this statistic can help make the high level estimates more accurate for release planning.
*Generally teams contain between 4-8 developers. For teams of this size having the entire team estimate seems to work well. However, if your team has more than 8 devs, I would suggest breaking into two estimation groups. Splitting the team clearly has consequences. At a minimum you will want each story to be started by at least one person who estimated it. Also, you'll need to find a way to communicate the details of each story to the half of the team not involved in estimation. I've seen this handled 2 ways.
The details of the story are presented to the entire team, then the team is broken to estimate.
Team Split 1 presents their stories to Team Split 2 following estimation and vice-versa.
I've used both, and they both seem to work fine.
Despite the consequences, splitting large teams for estimation has been much more effective in my experience.
Previous Topic
