8.1 Planning & Estimation Techniques

8.1 Planning & Estimation Techniques

Quick Answer: Agile estimation shifts the focus from predicting absolute chronological durations to measuring relative sizing. Rather than estimating work in hours or days—which varies wildly depending on who performs the task—Agile teams use abstract units like Story Points or T-Shirt Sizes. Techniques like Planning Poker (rooted in the Wideband Delphi method) and Affinity Estimating harness collective team intelligence while actively neutralizing cognitive anchoring bias.

Traditional project management relies heavily on bottom-up time estimates expressed in hours, days, or weeks. However, human beings are notoriously poor at estimating absolute time in complex, high-uncertainty environments—a phenomenon driven by Parkinson's Law (work expands to fill allotted time) and Student Syndrome (procrastination until the deadline). Agile replaces absolute duration guessing with relative estimation, allowing teams to estimate faster, with greater accuracy, and without premature commitment to fixed schedules.

---

Fundamentals of Relative Sizing in Agile

Relative sizing is the process of estimating the scale of a task by comparing it to another task of known size, rather than determining its absolute duration. Cognitive science demonstrates that while humans struggle to accurately estimate an object's exact mass (e.g., guessing whether a box weighs 14.5 or 18.2 kilograms), they instantly recognize relative proportions (e.g., recognizing that a dog is larger than a cat and smaller than an elephant).

In software and product development, relative estimation evaluates three core components simultaneously:

1. Effort — The total volume of labor required to complete the work.
2. Complexity — The intricate nature of the logic, architecture, or domain domain knowledge required.
3. Risk & Uncertainty — The unknowns, potential impediments, or external dependencies involved.

Neutralizing Cognitive Anchoring Bias

A critical objective of relative estimation is eliminating cognitive anchoring bias. Anchoring occurs when individuals base their judgments on an initial piece of information—such as a senior architect announcing, "This feature looks like a 2-day job." Once an anchor is dropped, subsequent estimates unconsciously gravitate toward that number, suppressing valuable dissenting perspectives.

Agile estimation frameworks use blind voting mechanisms where all team members reveal their estimates simultaneously. This forces every contributor to formulate an independent assessment based on their unique technical lens before being influenced by peers or authority figures.

---

Story Points vs. Ideal Time

Agile teams primarily utilize two units of measure during estimation: Story Points and Ideal Time.

Story Points

Story Points are unitless, abstract values assigned to a user story or backlog item to denote its relative size compared to a baseline user story. A story point value of 4 indicates that a item is twice as large or complex as a 2-point story, but it does not specify whether it will take 4 hours, 4 days, or 4 person-weeks.

Advantages of Story Points:

• Developer-Agnostic: A senior developer and a junior developer might take vastly different hours to complete a task, but both can agree the task is a 3-point story based on its inherent complexity.
• Resilient to Inflation: As a team's efficiency improves over time, story point values remain stable while the team completes more points per iteration.
• Eliminates Estimation Anxiety: Estimates are treated as relative ranges rather than binding hourly commitments.

Ideal Time

Ideal Time (or Ideal Days / Ideal Hours) represents the duration required to complete a task assuming 100% continuous focus, zero interruptions, zero meetings, no production support emergencies, and zero external dependencies.

While Ideal Time feels more familiar to traditional project managers, it carries notable drawbacks for Agile delivery:

• Stakeholders frequently confuse Ideal Time with calendar time, leading to unrealistic delivery expectations.
• It encourages individuals to estimate based on their personal working speed rather than team capabilities.

Comparative Overview

---

Planning Poker and the Wideband Delphi Foundation

Planning Poker is a consensus-based estimation technique designed to estimate backlog items iteratively while engaging the entire cross-functional team.

The Wideband Delphi Foundation

Planning Poker is adapted from the Wideband Delphi technique, an estimation methodology created by the RAND Corporation in the 1940s. Wideband Delphi relies on multiple rounds of anonymous expert estimation, interspersed with structured group discussion, to converge on a reliable consensus without falling victim to groupthink or loud-voice dominance.

The Modified Fibonacci Sequence

Planning Poker utilizes a specialized deck of cards featuring a modified Fibonacci sequence:
$\text{Sequence: } 1, 2, 3, 5, 8, 13, 20, 40, 100$

Additional special cards often include ? (Uncertain / Needs Refinement), ∞ (Too Large / Epic), and Coffee Cup (Need a Break).

Why a Modified Fibonacci Sequence?

• Reflects Escalating Uncertainty: As work items grow, uncertainty generally increases and wider buckets acknowledge the weaker precision. The gap between values expands (the difference between 1 and 2 is 1, but the difference between 13 and 20 is 7, and 20 to 40 is 20).
• Prevents False Precision: It is meaningful to debate whether a small feature is a 2 or a 3, but debating whether a large epic is a 36 or a 37 is a waste of time. The non-linear scale forces estimators to categorize large items into coarse buckets.

Step-by-Step Planning Poker Protocol

1. Presentation: The Product Owner presents a user story and clarifies acceptance criteria.
2. Discussion: The development team discusses technical implementation, architecture, risks, and assumptions.
3. Private Selection: Each team member selects a card from their deck reflecting their estimate and places it face down.
4. Simultaneous Reveal: All cards are turned face up at the exact same moment.
5. Outlier Explanation: If estimates diverge significantly (e.g., cards reveal 2, 3, 3, and 13), the high and low estimators explain their reasoning. The 13-point estimator might highlight a hidden database migration security constraint, while the 2-point estimator might reveal an existing reusable API.
6. Re-Vote & Convergence: The team re-votes until consensus or tight alignment is achieved.

---

Affinity Estimating and T-Shirt Sizing

When a team faces a massive backlog containing dozens or hundreds of un-estimated user stories (such as during initial project discovery or release planning), Planning Poker is too slow. Teams use Affinity Estimating and T-Shirt Sizing for rapid macro-level estimation.

Affinity Estimating (Silent Sorting)

Affinity Estimating leverages physical or digital boards to categorize stories quickly through silent collaboration:

• Step 1: Silent Placement: User stories are distributed to team members. Without speaking, team members place stories on a horizontal continuum ranging from "Smallest" on the left to "Largest" on the right. If a team member disagrees with a story's placement, they may move it to a different position without speaking.
• Step 2: Group Discussion: Once all stories are placed, the team breaks silence to discuss items that were moved repeatedly or provoke debate.
• Step 3: Bucket Assignment: The continuum is partitioned into relative sizing buckets (e.g., 1, 2, 3, 5, 8, 13) or T-shirt sizes.

T-Shirt Sizing

T-Shirt Sizing uses universal size categories: XS, S, M, L, XL, XXL. It is particularly effective for high-level portfolio planning, roadmapping, and early epic estimation before granular acceptance criteria are written. Later, as epics are decomposed into user stories for upcoming iterations, T-shirt sizes are converted into numerical story points.

---

PMI-ACP Exam Strategy & Common Pitfalls

• Consensus Rule: Planning Poker requires team consensus. If the team cannot agree after 3 rounds, the item should be split into smaller stories or flagged as requiring further technical investigation (a Spike).
• No Management Override: The Product Owner or Project Manager must never dictate or alter story point estimates. Only the team members who build the increment own the estimates.
• Avoid Cross-Team Velocity Comparisons: Story points are relative to a specific team's baseline. A 5-point story for Team A is completely independent of a 5-point story for Team B.