Planning Poker in Scrum

1. A Moderator, who will not play, chairs the meeting.
2. The Product Owner provides a short overview.
3. The team asks questions and clarifies assumptions and risks.
4. A summary of the discussion is recorded by the Project Manager.
5. Each individual lays a card face down representing their estimate.
6. Everyone calls their cards simultaneously by turning them over.
7. People with high estimates and low estimates are given a time box to offer their justification for their estimate and then discussion continues.
8. Repeat this process until a consensus is reached.

 Planning Poker is a fast, card based approach to team estimation. Team members are given cards with the numbers 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100 on them to represent development effort estimates.

User stories are presented to the team and discussed as a group to round out understanding, Then everyone selects a card that represents their estimated effort for the development. The cards are kept private until everyone has selected a card and then they are all revealed together.

If the resulting estimates are close then it is safe to record the estimate and move onto the next story. If there is significant divergence then people are invited to discuss why they believe it will be so different (for example last time we added a column to the account table it took 8hrs to regression test the legacy applications). Then in light of this new information people estimate again, as before only revealing their cards when everyone has selected a card. The process iterates until sufficient consensus has been reached.

Planning Poker takes the group based consensus building and anonymous estimating concepts of Wideband Delphi estimation and packages them in a faster, more enjoyable format. 

Scurm Estimation using Story Points

1. An abstract number to measure size of a feature.
2. Does not mean anything in isolation, but conveys relative size of features when compared.
3. Different teams size-up the same features differently but the relative measures between features might be the same.
4. Fibonacci series preferred as story points: 1, 2, 3, 5, 8, 13, 21, …
5. Geometric series also preferred: 1, 2, 4, 8, 16, 32, …

Story point estimation allows us to:

1. Rapidly estimate long-term product backlogs without requiring detailed specifications and complicated dependency charting
2. Provide broader insight from diverse functional experts (which offers checks and balances and less point sensitivity) to ensure that estimates aren’t being padded nor under-baked
3. Ensure that the entire ‘brains trust’ of the team is able to understand and assess the merits of the requirements, allowing for early detection of any potential issues as well as areas for improvement
4. Leverage the knowledge gained from completing legacy work
5. Actually have some fun whilst conducting a traditionally mundane and frustrating task. Planning Poker sessions are interactive, lively and much faster than traditional estimation marathons
6. Sound pretty snazzy as talking about your ‘team velocity’ is way more exciting than mumbling something about your ‘team rate of progress’ – ok maybe leave that one out…

Agile Estimation Basics

1. Traditional PM methods estimate by activities – Break the scope into activities, estimate the duration of activity, add them up.
2. Agile PM methods estimate by features – First estimate size of features, then estimate duration of features.
3. Estimation of size happens as early and as often as possible.
4. Estimation of duration happens as late and as often as possible.
5. Always be a whole-team activity.
6. Estimates of size: User story or ideal days.
7. Estimate of Duration = [sum of all user stories or all ideal days] / [velocity]