4squareviews

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

Today’s post is about the process 3.11 Planning Poker, which is a tool used as part of doing the process 3.8 Sizing.  Sizing is the process of estimating the relative amount of development effort needed to complete a user story.   Planning poker is a tool used to accomplish this.

1. Out of all the user stories, the team chooses a story that represents a midpoint, which could be referred to as a “medium” size user story.   Usually this story is given a value on the Fibonacci scale, typically 5 or 8 story points.
2. Each successive story is shown to the team, together with a brief discussion to clarify what it entails.   Then each member of the team makes an independent vote with a deck of cards that have Fibonacci numbers on them.   So if the user story is about the same difficulty as the first “medium” story, then a person would assign it an “8”, let’s say, if that was the number assigned to the midpoint story mentioned in the paragraph above.   If it is a smaller user story, then each member of the team assigns it a value from 1, 2, 3, or 5; likewise, if it is a larger user story, the team member assigns it a value or 13, 21, or larger.
3. The votes are compared, and the person or persons who gave the lowest score out of the range of numbers given as a a vote has to explain the reason for the outlier estimate; likewise the person or persons with the highest score of the range of numbers must explain their vote as well.
4. A revote is done until a consensus on the size of the story.
5. If there is no consensus reached, then this could be because the story is too vague to be effectively estimated, and it is returned to the customer/proxy for further clarity.
6. If there is a largest value allowed for a user story, say 21, and a consensus is reached that the particular user story is larger than the allowed maximum, then that story is returned to the customer/proxy for further decomposition.

John Stenbeck recommends that the Planning Poker meeting be facilitated by someone outside the team, either an agile coach or a Scrum Master from a different team.

Now the two dimensions of priority and size of a user story are combined in a process 3.12 Affinity Estimates, which is the subject of the next post.

In the next post, I will discuss how the three elements of a cross-functional team, planning poker, and Fibonacci numbers can help reduce three significant risks associated with estimating and sizing (processes 3.8 and 3.9).

Filed under: Uncategorized |