Steps to Successful Story Point Estimation

1. Identify base stories.
2. Talk through the requirements of the story.
3. Discuss and jot down things you want to remember when implementing this story.
4. Some of these questions team ask themselves when they start sizing.
5. Find some point of relative comparison.
6. Reach a consensus among entire team present as to the size of the story as per definition of done.
7. Validate that your estimates are internally consistent among stories as you go along.
8. Periodically ensure that all of the 1′s are about the same, all of the 2′s match, etc.

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…