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.
Despite the consequences, splitting large teams for estimation has been much more effective in my experience.
Thanks for the post, Jay! It helps. Just couple more questions: don't you normally break down stories into engineering tasks (basically something in developer language that implements the user-language stories)? If you do, when do you perform the break-down --after iteration-level estimation of stories or before? And do you estimate against tasks too?
ReplyDeleteI guess this is where we do things a bit differently: we make the high-level estimates against stories but the iteration-level estimates against broken-down tasks (which we then roll up to get the iteration-level estimate for the story). The idea is that something in developer language is better understood by developers and easier to estimate accurately.
Do you think this leads to wider gaps between the two estimates or is it ultimately equivalent to what you do?
It depends on the project, but I tend to prefer to define the tasks, but still estimate the story.
ReplyDeleteThe problem with estimating tasks is that they don't seem to scale well to story size estimates.
So, our usual process is to task out a story to get a good feel for it and then estimate the entire story keeping the tasks in mind.