Sunday, September 4, 2011

Sizing Stories with Planning Poker

Sizing Stories with Planning Poker

As a Scrum Master / Coach i hear a lot of non-agile enthusiasts complain about Story Sizing.

" Why size stories and waste time?"

"I want hours and not some vague story points"

"We spent so much time playing poker but i really see no value in it"

Well Story Sizing exercise is definitely a waste of time if you don't know the real reason behind it.

"The value in sizing is in the cross-functional discussion"

This is the probably the first time a group of individuals of various skill sets are coming together and having a discussion. Developers, Testers, Business Analysts & UI folks look at user story from various angles and this is what you want to capture during the sizing exercises.

If you are convinced about the usefulness of sizing then read on..

“Olive garden serves me twice the amount of Chicken Alfredo Pasta than what I would get at the Cafeteria”

Our Limitations:

We humans are better at relative sizing than absolute sizing..Why spend days coming up with upfront effort estimation in hours when most of the time your numbers rarely match up with actual's.


Story Points:

  • Story Points are only used to size stories on the Product Backlog and Not Within the Sprint
  • Story points are NOT effort estimation in hours
  • Story points are relative estimates
 i.e. You get the numbers by comparing one Story to another
 There is always a reference story (A )and all other stories (B, C &D) are compared to this reference story.

Usually…
The Higher the uncertainty and risks for a given story the higher is the story point.

 Why not estimate these Stories in Hours?
   A While ago Yale University had reported that
“The best developer on a project takes one hour to complete a task while the worst developer takes 10 hours “

This means that Hours completed tell us nothing about how many features we can ship and when we can ship them.

The most important metric that defines our progress is ..
The number of story points the team has committed and can deliver per Sprint.
Rather than the number of hours being spent by the team per Sprint.

How is Planning Poker Done

  • Each person (estimator) participating in the estimation process is given a deck of cards, each card has valid estimate written on it
  • Customer/Product owners reads a user story and it’s briefly discussed
  • Each estimator selects a card that represents their estimate
  • Cards are turned over so all can see them
  • Differences between estimates are discussed
  • Re-estimate until estimates converge

Varied Estimates!!
Varied estimates mean that it’s a good time to get the unknowns out. Testers might have some specific scenarios in mind which developers have not even thought about.
Same goes with developers too!!


Repeat Till estimates converge




Let’s Play Poker!

No comments:

Post a Comment