I ran into Steve during the agile 2007 conference so I invited him to do the session for us at BayXP. Last October, Steve came down and hosted a session of the Team Estimation Game. This is the first time I learned it I really liked it.
Given a set of defined stories, the purpose of this game is to come to the consensus about the relative estimation of the work to be done for each story. If you don't have a set of stories to try it out, you can use the sample produced by Steve here.
So once you have all the story cards, you first estimate their complexity relative to each other:
- Place Story Cards in pile on table.
- First player places top card on playing surface.
- Next player places top card on playing surface relative to first card.
- Next player can either:
* Play top card from pile, or
* Move a card on the playing surface, or
* Pass - Repeat Step 4 until
a) no more cards remain in pile, and
b) no player wishes to move a card
Here is an example of the result:
After the first stage is finished, you can now go on to assign points to them so that you can track your team velocity:
6) As a team, choose estimation units and values.
With the agreed units:
7) Place an estimate at the top of each column.
8) Change estimates until all team members agree.
We did it during the meeting and it went very smoothly. The interesting thing is that Steve told us the result is not too much different from the ones that he has conducted elsewhere with other groups.
I am definitely going to try it on my next story estimation session.
References:
* Planning poker, which is another popular and useful estimation game.
* Steve's slides: http://www.shaneduan.com/estimation/Team_Estimation_Game.ppt
* Planning Poker Cards you can buy here.
6 comments:
This is really cool -- I'm going to try it this week with the team I'm coaching.
One nit: in my opinion "complexity" is only one factor in "effort." Some simple work turns out to be high effort, and vice versa. So I prefer to think of these as effort points.
That is very good point. It is the effort that matters in the end during the estimation not the complexity.
I agree, it's effort, and not just complexity, that we're trying to estimate.
Unfortunately, "effort" often contains emotional baggage that "complexity" does not.
I'd stick with describing complexity, then afterwards suggest the term "effort points" or just "story points."
Team estimation game looks like another good tool for the planning and estimation toolbox.
There is another technique that helps when there are a lot of stories to estimate, like during iteration 0. I call it The Planning Poker Party. Give it a click.
It's great method, but what about empty columns ... when you estimate with this method, you may have some cols leaved blank or empty, what about those. should we point them like other cols? what if we have too many empty cols between story groups? they will be cause big point numbers ...
Thanks alot
S.Samoel
I would like to recommend you try it out and think about a rule that can make it work. My sense is that it would not be a blocking issue once you realize the power of comparison.
Post a Comment