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

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

A Hyper-Practical, Zero-Fluff Guide for Scrum Teams

1. What This Is & Why It Matters

You’re a Scrum Team Lead. Your Product Owner (PO) just dropped 20 new user stories into the backlog. The sprint starts in two hours, and your team is staring at you like, "How long will this take?" If you guess wrong, you’ll either: - Overcommit-Miss deadlines, burn out the team, and erode trust with stakeholders. - Undercommit-Waste capacity, look slow, and get pressure to "do more" next sprint.

Estimation isn’t about precision—it’s about relative sizing to make better decisions. The Scrum Guide 2020 doesn’t prescribe a method, but Planning Poker, T-Shirt Sizes, and Affinity Mapping are the three most battle-tested techniques. Use them to: ? Align the team on complexity (not just time). ? Expose risks early (e.g., "This story is a ‘L’ because it touches three microservices"). ? Prioritize effectively (e.g., "We can fit two ‘M’s and a ‘S’ in this sprint").

Real-world scenario: You’re migrating a monolithic app to microservices. The PO says, "Just estimate the whole thing as 40 story points." Your team groans—some stories are trivial (update a config file), others are nightmares (refactor auth across services). Without structured estimation, you’ll either: - Pad estimates-Stakeholders think you’re slow. - Underestimate-The team works weekends to hit a fake deadline.

This guide gives you the tools to estimate fast, fairly, and consistently—so you can plan sprints with confidence.

2. Core Concepts & Components

? Planning Poker

• What it is: A gamified estimation technique where team members vote on story complexity using numbered cards (Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100).
• Production insight: If your team’s estimates vary wildly (e.g., 3 vs. 13 for the same story), it’s a red flag for unclear requirements or hidden risks.
• Why Fibonacci? Forces coarse-grained decisions (e.g., "Is this a 5 or an 8?" vs. debating 6 vs. 7).

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

• What it is: A quick, low-fidelity way to categorize work into size buckets (e.g., "This is a ‘Large’ because it needs a new API").
• Production insight: Great for early backlog refinement when details are fuzzy. Later, convert to story points for sprint planning.
• Trap: Teams often argue over "Is this M or L?"-Solution: Define clear criteria (e.g., "M = 1-2 days, L = 3-5 days").

? Affinity Mapping (aka "Silent Sorting")

• What it is: A silent, collaborative way to group similar items (e.g., "All these stories touch the payment service-they’re related").
• Production insight: Reveals dependencies and reduces duplicate work. Use it before Planning Poker to avoid "anchor bias" (first estimate influences others).
• How it works:
• Write stories on sticky notes.
• Team silently groups them by similarity.
• Discuss outliers (e.g., "Why is this story alone?").

? Story Points vs. Hours

• Story points: Measure complexity (effort + risk + uncertainty).
• Hours: Measure time (but vary by person).
• Production insight: Never mix them. If stakeholders demand hours, convert story points to hours after estimation (e.g., "1 point-1 day for our team").

? Velocity

• What it is: The average number of story points your team completes per sprint.
• Production insight: Use it to forecast, not to pressure the team. If velocity drops, investigate (e.g., tech debt, unclear requirements).
• Trap: Velocity-productivity. A team with high velocity but low quality is worse than a slow, careful team.

? Ideal Days vs. Elapsed Time

• Ideal days: "How long would this take if I had no meetings, no interruptions, and perfect focus?"
• Elapsed time: "How long will this actually take in the real world?"
• Production insight: Always estimate in ideal days, then add a buffer (e.g., 20% for meetings/slack).

? The Cone of Uncertainty

• What it is: The range of possible estimates narrows as you learn more (e.g., early: 1-10 points; late: 3-5 points).
• Production insight: Re-estimate as you refine stories. A "5" in sprint planning might become an "8" when you discover a hidden dependency.

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

Prerequisites

• A backlog with well-defined user stories (use the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable).
• A Planning Poker deck (physical cards or a tool like PlanningPoker.com).
• 3-9 team members (developers, testers, designers—anyone who’ll do the work).
• A timebox (e.g., 1 hour for 10 stories).

Step 1: Set the Stage

1. Explain the rules:
2. Everyone votes simultaneously (no anchoring).
3. Discuss only if votes differ by more than 2 steps (e.g., 3 vs. 8).
4. The goal is consensus, not perfection.
5. Define your scale:
6. Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100.
7. T-Shirt: XS, S, M, L, XL (map to points later if needed).

Step 2: Pick a Baseline Story

1. Choose a "gold standard" story (e.g., "Add a login button" = 2 points).
2. Write it on a whiteboard for reference.
3. Why? Gives the team a shared reference point.

Step 3: Estimate the First Story

1. Read the story aloud (e.g., "As a user, I want to reset my password so I can regain access").
2. Ask clarifying questions (e.g., "Does this include email validation?").
3. Everyone votes silently.
4. Reveal votes:
5. If all votes are within 1 step (e.g., 3, 3, 5), accept the highest vote.
6. If votes differ by >2 steps (e.g., 2, 8, 13), discuss for 2 minutes max:
   • High voter: "I picked 13 because the email service is flaky."
   • Low voter: "I picked 2 because we have a template for this."
7. Re-vote until consensus.

Step 4: Repeat for All Stories

1. Timebox each story (e.g., 5 minutes max).
2. Skip stories that are too vague (mark them for refinement).
3. Flag dependencies (e.g., "This story is 8 points, but it depends on the 5-point API story").

Step 5: Convert T-Shirt Sizes to Points (If Needed)

Example: - "Refactor the checkout flow" = L-8 points. - "Fix a typo in the footer" = XS-1 point.

Step 6: Validate with Velocity

1. Check your team’s average velocity (e.g., 30 points/sprint).
2. Add up the points for the sprint backlog (e.g., 28 points).
3. If > velocity, negotiate with the PO (e.g., "We can do 25 points—drop the 3-point story or split the 8-point one").

Step 7: Document Assumptions & Risks

• Add a "Risks" section to each story (e.g., "Depends on API team’s availability").
• Update the Definition of Ready (DoR) to include "Estimated in story points."

4.-Production-Ready Best Practices

? Security (Yes, Estimation Has Security Implications!)

• Never estimate security work as "small." A "quick" auth change can break everything.
• ? "Update JWT library" = 2 points.
• ? "Update JWT library + test all auth flows" = 8 points.
• Flag compliance risks (e.g., "This story touches PII—add 3 points for security review").

? Cost Optimization

• Estimate infrastructure costs (e.g., "This story needs a new EC2 instance-+$50/month").
• Use T-Shirt sizes for cloud costs:
• XS = <$10/month (e.g., Lambda).
• S = $10-$50/month (e.g., small RDS).
• M = $50-$200/month (e.g., EKS cluster).
• L = $200-$1k/month (e.g., multi-AZ RDS).
• XL = >$1k/month (e.g., data warehouse).

Reliability & Maintainability

• Estimate tech debt (e.g., "This story is 5 points, but we’ll add 2 points of tech debt").
• Use "spike" stories for unknowns (e.g., "Spike: Research GraphQL vs. REST for the API" = 3 points).
• Tag stories by risk level:
• ? Low risk (e.g., UI tweak).
• ? Medium risk (e.g., new API endpoint).
• ? High risk (e.g., database migration).

? Observability

• Track estimation accuracy (e.g., "We estimated 5 points, but it took 8—why?").
• Monitor velocity trends (e.g., "Velocity dropped from 30 to 20—is the team blocked?").
• Use a "confidence score" (e.g., "This story is 5 points, but confidence = 70%-add a buffer").

5. Common Mistakes & Traps

6.-Exam/Certification Focus (PSM, CSM, etc.)

Typical Question Patterns

1. "Which technique is best for a new team with vague requirements?"
2. ? T-Shirt Sizes (quick, low-fidelity).

3. Planning Poker (requires more detail).

4. "What’s the purpose of the Fibonacci sequence in Planning Poker?"

5. ? Forces coarse-grained decisions (e.g., "Is this a 5 or an 8?").

6. "Because it’s mathematically optimal" (trap answer).

7. "When should you re-estimate a story?"

8. ? When new information emerges (e.g., "We found a dependency").

9. "Never—estimates are set in stone" (trap answer).

10. "What’s the biggest risk of estimating in hours?"

11. ? Varies by person (e.g., senior dev vs. junior dev).
12. ? "It’s less accurate" (trap answer—story points aren’t "more accurate," just more consistent).

Key Trap Distinctions

Scenario-Based Question

"Your team’s velocity is 30 points/sprint. The PO wants to add 40 points of work. What do you do?" --Negotiate: "We can do 30 points. Which 10 should we drop or split?" --"Just do it—we’ll work harder" (trap answer). --"Add more people to the team" (trap answer—Brooks’ Law: "Adding people to a late project makes it later").

7.-Hands-On Challenge (With Solution)

Challenge:

Your team is estimating a story: "As a user, I want to export my order history to CSV so I can analyze my spending."

Votes: - Alice: 3 - Bob: 8 - Charlie: 5 - Dave: 13

Why the disagreement? Alice thinks it’s a simple database query. Bob knows the export feature needs pagination (10k+ orders). Charlie assumes the CSV format is predefined. Dave is worried about GDPR compliance (PII in the data).

Your task:
1. Identify the root cause of the disagreement.
2. Propose a solution to reach consensus.

Solution:

1. Root cause: Unclear requirements (pagination? PII handling? CSV format?).
2. Solution:
3. Split the story into smaller, clearer tasks:
   • "Export first 100 orders to CSV" (3 points).
   • "Add pagination for large exports" (5 points).
   • "Anonymize PII in exports" (5 points).
4. Re-estimate each subtask (e.g., 3 + 5 + 5 = 13 points total).
5. Add a spike (e.g., "Spike: Research GDPR-compliant CSV exports" = 2 points).

Why it works: - Smaller stories = less uncertainty. - Spikes reduce risk. - Team aligns on scope before voting.

8.-Rapid-Reference Crib Sheet

Planning Poker

• Scale: 1, 2, 3, 5, 8, 13, 20, 40, 100 (Fibonacci).
• Rule: If votes differ by >2 steps, discuss for 2 mins max, then re-vote.
• Trap: Letting the loudest person dominate (enforce silent voting).

T-Shirt Sizes

Affinity Mapping

1. Write stories on sticky notes.
2. Team silently groups similar items.
3. Discuss outliers (e.g., "Why is this story alone?").

Velocity

• Formula: Velocity = (Story Points Completed in Last 3 Sprints) / 3.
• Trap: Using velocity to compare teams (it’s team-specific).

Spikes

• Definition: Time-boxed research stories (e.g., "Spike: Evaluate AWS vs. GCP for our use case").
• Estimate: 1-3 points (never >5).

Definition of Ready (DoR)

A story is "ready" if it has: - Clear acceptance criteria. - Estimated story points. - No blocking dependencies.

9.-Where to Go Next

1. Scrum Guide 2020 – Estimation (Official source).
2. Planning Poker Online Tool (Free for small teams).
3. Book: "Agile Estimating and Planning" by Mike Cohn (The bible of Agile estimation).
4. Mountain Goat Software – Estimation Articles (Practical tips from Mike Cohn).

Final Pro Tip

Estimation is a skill—practice it like coding. - Run a 10-minute Planning Poker session for your next sprint. - Track your accuracy (e.g., "We estimated 5 points, but it took 8—why?"). - Refine as you go. The goal isn’t perfect estimates—it’s better decisions.