There was a Sprint Team that consists of a Child and a Brain Surgeon.

Their product backlog includes two items:

1. Lick 1,000 stamps
2. Perform a Simple Brain Surgery – Snip and Done

These items are chosen for the upcoming Sprint iteration.

These tasks are estimated to take the same amount of time.

Despite their vastly different complexities

… Both item items should be given the Same Number of Story Points

…… As each Task is expected to take the Same Amount of Time

In Agile estimating, we assume the right person for the job will do the work.

We do not assume the child will:

1. Finish High School
2. Complete Undergraduate School
3. Graduate from Med School
4. Do a Seven-year Residency
5. And then begin the Brain Surgery

while we have a skilled surgeon sitting in a cubicle licking stamps.

The Right Person

… for the Right Job

The Planning poker game relies upon Team member opinions, Technology analogies, and real world experiences into a fun game approach to estimating complexity of User Story development

This process results in rapid but very reliable complexity estimations.

It is important in planning poker includes all of the Developer Team members involved in the upcoming Sprint.

This includes the Scrum Master, Product Owner, Architect Team’s Designers and any other team representatives required for the selected Sprint activities.

These Sprint Team members include the Business, QA and Network Infrastructure representatives.

Any given Sprint Team should not exceed ten members. This does not include the Product Owner and Team representatives; they can be represented across multiple Sprint Teams.

Each Sprint Team estimates independently to keep the size down.

The Product Owner and Scrum Master participate in the Planning Poker game but do not estimate task’s complexities.

The Poker Game Process

Planning Poker uses playing cards similar in size to regular poker playing cards.

Each of the estimating team members is given a deck of cards that represent the First Order of Magnitude of the Fibonacci Numerical Sequence.

The seven card deck reads: 0, 1, 2, 3, 5, 8 and 13

A Zero Level of Complexity Represents that the Estimator

… Has Knowledge that the Requirement Being Estimated

…. Has Been Developed and Available with Minimum Work

The Poker Decks are prepared ahead of the Sprint Planning meeting by the Product Owner for all meeting recipients that will be participating in the estimations.

Poker Cards are returned to the Product Owner after the estimation session is concluded.

For each selected Backlog item to be estimated, a selected Estimation Moderator reads the description.

Estimation Moderator should be the Lexicon Master as it will help to maintain the Ubiquitous Languages integrity but it can be any non-estimation team member.

The Product Owner will answer any questions that the estimators have about the Backlog item.

It is important that at some point additional discussion does not lead to improved accuracy.

An accepted technique is to have available a Two Minute Hour Glass Timer and turn it over by the Estimation Moderator for all to see when an issue is being discussed.

The discussion ends when the “Sands of Time” expires.

The goal in the Planning Poker game is not to create an estimate that is “Bullet Proof”.

The Planning Poker game goal is create consensus where a valuable estimate can be arrived at the lowest reasonable complexity number.

After all issues are answered, each estimating team member selects a card from their deck with a Story Point number that represents their complexity estimate.

Cards are not shown until each Sprint Estimation Team member estimator has made a complexity number selection.

At that time, the Estimation Moderator requests that all cards are simultaneously turned over view viewing by all of the Sprint Estimation Team members.

The Estimates May Very Well Differ Significantly

… This is Actually the Purpose of this Exercise

When estimates differ, the High and Low Estimators have a maximum of two minutes each to explain and justify their Complexity Estimates with the entire Sprint Planning Team.

It’s Important Not to Attack the Team Member’s Estimate

… You want to Understand the Motivation behind the Estimate

Remember the Team Member would not be in the Meeting

… if their Professional Opinion was not Valuable

The Estimation Moderator takes any notes that will be helpful when this User Story is being developed and tested as part of the Ubiquitous Languages Lexicon of Terms.

Notes for the development of supporting documentation can be created and given to the Architect Designers.

After the discussions are completed, each estimator re-estimates by selecting a card for display.

Story Point cards are once again kept private until everyone has estimated, at which point they are turned over again at the same time.

In many cases, the estimates will already converge by the second round.

But if they have not, continue to repeat the process.

The goal is for the estimators to converge on a single estimate that can assigned to the Business User Story’s Complexity Bucket.

It rarely takes more than three rounds, but the process should continue as long as estimates are moving closer together.

It is not required that all estimators turns over a card with exactly the same estimate written down.

If an estimation collection returns a set of 5, 5, 5, and 3

… Ask the low estimator member if they are OK with an estimate of 5

Again, the exercise is not about absolute precision but a reasonable “Estimation” in a timely fashion.

The Product Owner has the Responsibility

… For Resolving User Story Point Estimation impasse.