V-Base Development Blog

Becoming Agile is not an overnight process. That’s at least one thing that Yogi Masters and Scrum Masters will agree on. Yoga was not the path to Agility for us. Our approach was somewhat more intellectual: learning from our successes and errors and undertaking training.

So here we were, back to the classroom.

I had the chance to attend an“Agile Estimating and Planning” course with Mike Cohn as an instructor. We looked at various approaches to estimating and went through techniques for deriving estimates as well as when and how to re-estimate.

One of these techniques is “Planning Poker” and the rules are very simple:

When?

At the beginning of each iteration.

Who?

The whole team is involved in the process in order to discuss all aspects of the users stories presented (each user story is a discreet piece of requirement) but only the participants who are going to implement the user stories can play because only they have the knowledge of what actually needs to be done.

What?

All you need is a set of Planning Poker cards for each participant. Cards value are 0, 0.5, 1,2,3,5,8,13,21… (Fibonacci, anyone?)

How do you play?

1. The Product Owner presents one of the highest priority backlog items (user stories) to the development team.
2. After discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion.
3. All estimates are kept private until each participant has chosen a card.
4. All cards are revealed simultaneously and if the estimates differ, each player should explain the rationale behind the number chosen.
5. Following discussion, a second hand is played, following the same steps.
6. The round is closed when all players reach consensus on how much effort it will take to implement this particular user story (usually after no more than 3 hands).

After running a couple of iterations you know the average velocity of your team, i.e. how many story points they can commit to deliver in an iteration. When the total effort points committed to in the Planning Game of an iteration reaches the number representing the team’s velocity, developers can’t commit to more user stories and the game stops.

Benefits?

1. The people who will do the work provide the estimate. It isn’t a speculative number dreamt up by a manager who won’t actually be writing any code.
2. In fact, no single person supplies the estimate – it’s jointly arrived at by everyone involved, each looking at the problem from their own perspective/experience.
3. Developers commit themselves to a planned body of work.
4. It’s fun!

Here’s the team in action (click for larger image)…