PokerFace

Agile Estimation Walkthough

The User Story
A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer.

Example User Story:

"As a registered user, I want to be able to reset my password, so that I can regain access to my account if I forget my current password."

This story clearly defines the WHO (registered user), WHAT (reset password), and WHY (regain access).

The Estimation Team & Scale
The team gathers to discuss and estimate the story. We'll use the scale: 0, 1, 2, 3, 5, 8, 13, 21, 34, ∞, ?, ☕.

The team consists of developers, a QA engineer, and a product owner (who clarifies the story but doesn't typically vote). Each voting member has a set of cards with the estimation values.

Why this scale? This modified Fibonacci-like sequence reflects the increasing uncertainty with larger items. The gap between numbers grows, acknowledging that precision decreases as complexity increases.

  • 0: Negligible effort, or already done.
  • 1, 2, 3: Small, well-understood tasks.
  • 5, 8, 13: Medium complexity, some unknowns.
  • 21, 34: Larger, more complex, significant unknowns.
  • ∞ (Infinity): Very large or complex, needs to be broken down into smaller stories.
  • ?: Don't understand the story / need more info.
  • ☕: Need a break!
The Estimation Discussion (Planning Poker)
The team discusses the "Password Reset" story and votes using the agreed scale.

Round 1:

The Product Owner explains the story. Team members ask clarifying questions:

  • "Does it need to send an email or an SMS?" (Email)
  • "What are the password complexity requirements?" (Standard: 8 chars, upper, lower, number, special)
  • "Is there a lockout mechanism after too many failed attempts?" (Yes, 5 attempts)

Everyone selects a card and reveals simultaneously. Votes: 3, 5, 5, 8.

Round 1 Discussion:

The highest (8) and lowest (3) estimators explain their reasoning:

  • Dev A (voted 3): "It's a standard feature. We have libraries for email. UI is simple."
  • Dev B (voted 8): "We need to handle token generation, token expiry, secure storage of tokens, email template, and the lockout logic. Seems like more than a 5."

The team discusses the points raised by Dev B. Dev A realizes they underestimated the security aspects and token management.

Round 2:

After discussion, everyone re-votes. Votes: 5, 5, 8, 5.

The estimates are converging. The team might briefly discuss why one vote is still an 8, but if the difference is small and understood, they might agree on 5 as the estimate. If the '8' voter still has strong concerns about overlooked complexity, further discussion or choosing the higher estimate might be warranted.

Key Takeaways:

  • Estimation is a team activity promoting shared understanding.
  • Differences in estimates are valuable for uncovering assumptions.
  • The goal is not perfect accuracy, but a reasonable, agreed-upon relative size.
  • Break down stories that are too large or unclear (especially those estimated as ∞).