TECH **Agile Estimation Techniques: Planning Poker, T-Shirt Sizes & Affinity Mapping**

Agile Estimation Techniques: Planning Poker, T-Shirt Sizes & Affinity Mapping

A Hyper-Practical, Zero-Fluff Guide for Real Projects & Certifications

1. What This Is & Why It Matters

Estimation in Agile isn’t about predicting the future—it’s about reducing uncertainty so your team can make better commitments, prioritize work, and avoid death marches. If you skip estimation, you’ll either: - Overcommit → Miss deadlines, burn out the team, and erode trust with stakeholders.
- Undercommit → Waste capacity, look unproductive, and lose funding.

Real-world scenario:
You’re a Scrum Master inheriting a team that’s consistently missing sprint goals. The Product Owner (PO) blames "poor estimates," but the devs say, "We don’t even know what we’re estimating!" You need a way to: 1. Align the team on what "done" looks like.
2. Surface hidden assumptions (e.g., "Does this task include testing?").
3. Give the PO data to forecast releases without micromanaging.

This guide covers three battle-tested techniques to do exactly that: - Planning Poker (for granular, consensus-driven estimates).
- T-Shirt Sizes (for quick, high-level sizing).
- Affinity Mapping (for grouping similar work to spot patterns).

2. Core Concepts & Components

? Planning Poker

• Definition: A gamified estimation technique where team members vote on story points using numbered cards (Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100).
• Production insight: If your team’s estimates are always "5" or "8," you’re not discussing complexity—you’re rubber-stamping. Divergence in votes is a gift—it reveals hidden risks.
• Why Fibonacci? Forces trade-offs (e.g., "Is this a 5 or an 8?"). Linear scales (1, 2, 3, 4…) make people think in hours, which kills Agile.

? T-Shirt Sizes (XS, S, M, L, XL)

• Definition: A coarse-grained estimation method using clothing sizes to categorize work (e.g., "This epic is an L").
• Production insight: Use this before breaking work into stories. If everything is "L" or "XL," you’re not prioritizing—you’re just labeling.
• When to use: Roadmapping, backlog grooming, or when the PO asks, "How big is this initiative?"

? Affinity Mapping

• Definition: A visual technique to group similar items (e.g., user stories) based on size, complexity, or effort.
• Production insight: Reveals hidden dependencies (e.g., "All these ‘M’ stories require the same API change"). Use it to rebalance the sprint before committing.
• Pro tip: Do this after T-shirt sizing but before Planning Poker to avoid anchoring bias.

? Story Points vs. Hours

• Story points = Relative effort + complexity + risk.
• Hours = Absolute time (anti-pattern in Agile).
• Production insight: If stakeholders demand hours, say: "We’ll give you velocity (points per sprint) after 3 sprints. Until then, hours are guesses."

? Velocity

• Definition: The average number of story points a team completes per sprint.
• Production insight: Velocity is team-specific—never compare across teams. If your velocity drops, investigate (e.g., tech debt, context switching).

? Ideal Days vs. Elapsed Time

• Ideal days = Pure development time (no meetings, no interruptions).
• Elapsed time = Calendar time (what stakeholders care about).
• Production insight: If a story is "2 ideal days," it might take 5 elapsed days due to meetings, reviews, and blockers.

3. Step-by-Step Hands-On: Running a Planning Poker Session

Prerequisites

• A backlog with refined user stories (INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable).
• A physical or digital Planning Poker deck (e.g., PlanningPoker.com, Scrum Poker Cards).
• 3–9 team members (devs, testers, designers—anyone doing the work).
• A timer (5–10 minutes per story).

Step 1: Set the Stage

• Goal: Align on the "reference story."
• Script:

  "Let’s pick a ‘3’ story from last sprint—something we all agree was medium effort. For example, ‘Add a login button to the homepage.’ We’ll use this as our anchor for today’s estimates."

  
  

• Why? Without a reference, estimates are meaningless.

Step 2: Read the Story Aloud

• Do:
• Read the title + acceptance criteria.
• Ask: "What’s unclear? What are the risks?"
• Don’t:
• Let the PO or Scrum Master dominate the discussion.
• Skip the "Definition of Ready" (DoR) check (e.g., "Do we have designs? API specs?").

Example Story:

Title: "As a user, I want to reset my password so I can regain access to my account." Acceptance Criteria:
- User enters email → receives reset link.
- Link expires in 24 hours.
- Error handling for invalid emails.
- Logging for security audits.

Step 3: First Vote (Silent)

• Rules:
• Everyone picks a card without discussing.
• Reveal all at once (avoids anchoring bias).
• What to watch for:
• Consensus (e.g., all 5s): Move on.
• Divergence (e.g., 3, 5, 8, 13): Dig deeper.

Step 4: Discuss the Outliers

• Script for the high voter:

  "You voted 13—what’s making this risky?"

  
  

• Script for the low voter:

  "You voted 3—what’s missing from the story?"

  
  

• Common reasons for divergence:
• Unknowns: "We don’t know if the auth service supports this."
• Dependencies: "This needs a new DB column, which requires a migration."
• Edge cases: "What if the email bounces?"

Step 5: Re-Vote

• After discussion, vote again.
• If still divergent:
• Split the story (e.g., "Basic password reset" vs. "Advanced logging").
• Spike it (time-boxed research).
• Assign a temporary 8 and revisit next sprint.

Step 6: Record the Estimate

• Tools:
• Jira: Set the "Story Points" field.
• Azure DevOps: Use the "Effort" field.
• Physical board: Write the number on the card.
• Pro tip: Add a comment explaining the estimate (e.g., "5 because of the 24-hour expiry logic").

Step 7: Rinse & Repeat

• Timebox: 5–10 minutes per story.
• When to stop:
• The team is fatigued (max 10 stories per session).
• The sprint backlog is full (enough for 1–2 sprints).

Verification: Did It Work?

• Check 1: Velocity stabilizes after 3 sprints.
• Check 2: The team feels ownership of estimates (no "PO assigned this 5").
• Check 3: Stakeholders trust the forecasts (e.g., "We’ll deliver 40 points next sprint").

4. ? Production-Ready Best Practices

? Security (Estimation Edition)

• Don’t estimate in isolation: Include security tasks (e.g., "Add rate limiting to the password reset API").
• Flag compliance risks: If a story requires GDPR/PCI work, double the estimate.

? Cost Optimization

• T-Shirt sizes for epics: If an epic is "XL," break it down or kill it (it’s too risky).
• Spikes for unknowns: Time-box research (e.g., "2-day spike to evaluate AWS Cognito vs. Auth0").

?️ Reliability & Maintainability

• Estimate tech debt: If a story adds 3 points of debt, add 1 point to the estimate to account for cleanup.
• Definition of Ready (DoR): Never estimate a story that doesn’t meet DoR (e.g., missing designs, unclear acceptance criteria).

? Observability

• Track estimate accuracy: After each sprint, compare estimated vs. actual points completed.
• Retro topic: "Why did Story X take 8 points when we estimated 5?" (e.g., "The API was down for 2 days").

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "Which technique is best for…?"
2. Planning Poker: Granular, consensus-driven estimates (e.g., sprint planning).
3. T-Shirt Sizes: High-level roadmapping (e.g., "How big is this feature?").

4. Affinity Mapping: Grouping similar work (e.g., "Which stories are related?").

5. "What’s the purpose of the Fibonacci sequence?"

6. Answer: Forces trade-offs (e.g., "Is this a 5 or an 8?") and prevents false precision.

7. "Why not estimate in hours?"

8. Answer: Hours are absolute (varies by person), while story points are relative (team-specific).

9. "What do you do if the team can’t agree on an estimate?"

10. Answer: Discuss outliers, split the story, or assign a temporary 8 and revisit later.

⚠️ Trap Distinctions

• Story points vs. hours: Story points = effort + complexity + risk. Hours = time (anti-pattern).
• Velocity vs. capacity: Velocity = historical data (points/sprint). Capacity = available time (hours/sprint).
• Spike vs. story: Spike = research (time-boxed). Story = deliverable work.

Scenario-Based Question

"Your team’s velocity is 40 points/sprint. The PO wants to commit to 60 points next sprint. What do you do?" - Answer:
1. Push back: "Our historical velocity is 40—60 is a 50% increase." 2. Negotiate: "Let’s commit to 45 and see how it goes." 3. Investigate: "Why the sudden increase? New team members? Less tech debt?"

7. ? Hands-On Challenge

Challenge:
Your team is estimating a story:

"As a user, I want to export my data as a CSV so I can analyze it in Excel." The votes are: 3, 5, 8, 13.
What’s your next step?

Solution:
1. Ask the 13 voter: "What’s making this risky?" (Likely answer: "The data is in 3 different DBs, and we need to join them.") 2. Ask the 3 voter: "What’s missing from the story?" (Likely answer: "Does this include error handling for large exports?") 3. Split the story:
- Part 1: Export from a single DB (3 points).
- Part 2: Join multiple DBs (5 points).
- Part 3: Add error handling (3 points).
4. Re-vote on the smaller stories.

Why it works: Breaking down the work reduces uncertainty and aligns the team.

8. ? Rapid-Reference Crib Sheet

⚠️ Exam Traps:
- Default story point scale: Some tools use 1, 2, 4, 8… (not Fibonacci). Stick to Fibonacci for consistency.
- Estimating bugs: Bugs should not be estimated in story points (they’re debt). Track them separately.
- Overestimating spikes: A spike is research, not development. Cap it at 1–2 points.

9. ? Where to Go Next

1. Planning Poker Tools:
2. PlanningPoker.com (free for small teams).
3. Scrum Poker Cards (Android/iOS).
4. Books:
5. Agile Estimating and Planning – Mike Cohn (the bible of Agile estimation).
6. Scrum: The Art of Doing Twice the Work in Half the Time – Jeff Sutherland.
7. Certification Prep:
8. Scrum Alliance – Certified ScrumMaster (CSM).
9. Scrum.org – Professional Scrum Master (PSM).
10. Advanced Techniques:
11. Monte Carlo Forecasting (for release planning).
12. NoEstimates (controversial but worth understanding).

Final Thought

Estimation isn’t about being "right"—it’s about reducing surprises. The best teams don’t have perfect estimates; they have honest conversations about risk, complexity, and trade-offs.

Your mission:
1. Run a Planning Poker session this week.
2. Use T-shirt sizes to size your next epic.
3. Affinity map your backlog to spot dependencies.

Do this, and you’ll ship more predictably—without burning out your team. ?