Team Estimation Game

Estimation: wouldn't it be nice if we didn't have to do it? Well, maybe we don't. In a mature agile or lean/kanban development system where prioritized value is flowing at an acceptable rate, and in a context where knowing both the scope and date of a delivery is not necessary, estimates don't provide much if any value. So don't blindly assume that you must estimate your features/stories. And if you do evaluate the need for estimates and determine that they are worthwhile, you need to determine how much value they provide so you can be sure the effort spent estimating is commensurate with that value.

One of the best-known ways of estimating user stories is planning poker, first described by Mike Cohn (as far as I know anyway). I've used planning poker very effectively, but I recently came across an alternative approach: the Team Estimation Game, originally created by Steve Bockman and described here by NetObjectives (you may need to register to see the link).

In a nutshell, the team starts with a stack of cards containing stories or features. Over the course of the game, story cards are physically arranged linearly according to size: small stories on the left side of the board/table, and larger stories farther to the right. Stories of the same or similar size are stacked together in a group. Taking turns, each member of the team may either (1) place the top card on the stack in the place where he/she believes it should go, or (2) move a card previously placed by another team member, explaining the reason why it was moved. At the end of the game, you can assign story points to each group of cards.

One of the strengths of this game is the emphasis on relative sizing; it makes it more easy and obvious to compare all the stories you're estimating. I also like the tactile nature of the paper cards and the physical involvement of people moving and interacting versus sitting still like they would in planning poker.