18.Story Point Estimations - Planning Poker

the Scrum Team plays Planning Poker® by adhering the following steps:

1.The Scrum Product Owner presents the story to be estimated. 2.Each member of the Scrum Team privately chooses the card representing the estimation. 3.After everyone has selected a card, all selections are revealed. 4.People with high and low estimates are asked to explain their assessment because they may have thought something that the majority of the Scrum Team members have been unable to see. 5.Another estimation is done for this particular user story until the team reaches a consensus for an estimate. 6.The Scrum Team repeats the game until they estimate all user stories.

The Scrum Team provide their estimates by using more abstract metrics to compare and qualify the effort required to deliver the user stories.

The Scrum Framework itself does not prescribe a way for the Scrum Teams to estimate their work. The teams who rely on the Scrum Framework do not deliver their estimates of user stories based on time or person-day units.

Common estimation methods include

• Numeric sizing (1 through 10), • T-shirt sizes (XS, S, M, L, XL, XXL, XXXL), or • the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, etc)

All user stories within the Scrum Product Backlog have to be estimated to allow the Scrum Product Owner to prioritize them and plan releases.

Nevertheless, it is recommended that the Scrum Product Owner does not interfere with the estimations that the Scrum Team performs. So the Scrum Team delivers its estimates without feeling any pressure from the Scrum Product Owner.

The reason for using the Fibonacci sequence is to:

Rreflect the uncertainty in estimating larger items. It would be a waste of time to discuss if a user story should have a size of 19, 20 or 21. And yet, it's relatively easier to decide if the user story fits better to the size 13 or 21.

A high estimate could mean that the Scrum Team members have not very well understood the user story yet.

So they can attempt to secure extra capacity for contingency before their commitment to this user story. Alternatively, that could also mean that the user story should be broken down into multiple smaller user stories. Scrum teams can usually estimate smaller and clearer user stories with higher confidence.

1.The Scrum Product Owner presents the story to be estimated.

The Scrum Team asks questions, and the Scrum Product Owner articulates the user story in more detail. If the Scrum Team has to assess many user stories,estimates can be time-boxed in a way that the Scrum Team does not spend more than a few minutes for each user story. If the team cannot still estimate a user story in a given time-box, then this could be a signal to which the Scrum Product Owner needs to pay attention. This signal indicates that either the end-user requirement or the user story or both of them are not clear enough, so they need to be rewritten.

Planning Poker / Scrum Poker

When using Planning Poker, the social proof influence among the Scrum Team members are minimal. Therefore, the Scrum Team produces more accurate estimation results.