Friday, July 27, 2012
Is velocity meaningful?
If you are estimating based on time to complete instead of relative complexity, NO.
If you are using it to compare two different teams, NO.
If you are doing just-in-time story estimation in your Iteration Planning Meeting, NO.
Relative complexity.
We want to estimate stories relative to other stories. Start by picking an “average” story and assigning it points. We’ll say that our average story is a “3”. We then estimate the remaining stories relative to our average story. If it’s simpler, give it a “1” or a "2". If it’s more complex, give it a “5”. If it’s a lot more complex, consider breaking it up into more stories.
Different teams.
It’s very likely that one team’s “3” is much different than another team’s “3”. It’s also likely that estimating skills are very different across teams.
Just-in-time estimating
Estimating stories at the iteration planning meeting for purposes of velocity is less than ideal. It’s easy to imagine a story getting different points assigned to it based on the iteration it was estimated because different people could be estimating or the understanding of the “average” story’s complexity is a moving target.
The right way.
It’s best to estimate all of the stories created in inception all at once by a few developers to get a meaningful baseline. With baseline estimates, a burn down chart can be used to predict release dates based off of “yesterday’s weather”.
Yes there are things that are going to be missed when the baseline estimates are given, but the thought is that for every story that is overestimated, there will also be an underestimated story.
If you are using it to compare two different teams, NO.
If you are doing just-in-time story estimation in your Iteration Planning Meeting, NO.
Relative complexity.
We want to estimate stories relative to other stories. Start by picking an “average” story and assigning it points. We’ll say that our average story is a “3”. We then estimate the remaining stories relative to our average story. If it’s simpler, give it a “1” or a "2". If it’s more complex, give it a “5”. If it’s a lot more complex, consider breaking it up into more stories.
Different teams.
It’s very likely that one team’s “3” is much different than another team’s “3”. It’s also likely that estimating skills are very different across teams.
Just-in-time estimating
Estimating stories at the iteration planning meeting for purposes of velocity is less than ideal. It’s easy to imagine a story getting different points assigned to it based on the iteration it was estimated because different people could be estimating or the understanding of the “average” story’s complexity is a moving target.
The right way.
It’s best to estimate all of the stories created in inception all at once by a few developers to get a meaningful baseline. With baseline estimates, a burn down chart can be used to predict release dates based off of “yesterday’s weather”.
Yes there are things that are going to be missed when the baseline estimates are given, but the thought is that for every story that is overestimated, there will also be an underestimated story.
# posted by Perry Hertler : 5:43 PM
Subscribe to Posts [Atom]