Estimation is often cited as one of the most challenging aspects of agile software development. Traditional approaches based on absolute time estimates frequently fall short due to the inherent uncertainty in creative work. This is where relative sizing—and specifically Planning Poker—has emerged as a superior alternative for agile teams.

This article explores the principles behind relative sizing, details how to implement Planning Poker effectively, and provides guidance on establishing a sustainable estimation practice in your agile team.

Why Relative Sizing Works Better Than Time Estimates

Absolute time estimates (hours, days) in software development suffer from several fundamental problems:

False precision: They create an illusion of accuracy that rarely matches reality
Inconsistency: Different team members have different working speeds
Psychological anchoring: Time estimates are heavily influenced by initial numbers mentioned
Poor scaling: Time estimates don't account well for complexity and uncertainty

Relative sizing solves these problems by focusing on comparing work items to each other rather than predicting exact durations. It acknowledges that while we struggle to say exactly how long something will take, we're quite good at determining if one task is larger than another.

The Science Behind Relative Sizing

Research in cognitive psychology supports the effectiveness of relative sizing. Humans are naturally better at comparative judgments than absolute ones. This is called "ordinal scaling"—we can more reliably say "A is bigger than B" than "A is exactly X units big."

This approach leverages our innate ability to pattern-match and compare, producing more consistent results across a team.

Story Points Explained

Story points are the most common unit for relative sizing in agile. They represent a composite measure of several factors:

Effort: The amount of work required
Complexity: How difficult or intricate the work is
Uncertainty: Unknowns and potential risks

By combining these factors into a single unit, story points provide a holistic view of "size" beyond just effort.

Common Story Point Scales

The most popular story point scales follow patterns that intentionally limit precision for larger values:

Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 34
Modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100
Powers of 2: 1, 2, 4, 8, 16, 32
T-shirt sizes: XS, S, M, L, XL, XXL (often with numeric equivalents)

These non-linear scales reflect an important principle: as size increases, our ability to estimate accurately decreases. The increasing gaps between values acknowledge this growing uncertainty.

Planning Poker: The Definitive Agile Estimation Technique

Planning Poker (also known as Scrum Poker) has become the gold standard for agile estimation. It combines relative sizing with team consensus building in an engaging format.

How Planning Poker Works

Preparation: The product owner presents a backlog item to the team
Discussion: The team asks questions to understand the requirements
Silent estimation: Each team member privately selects a card representing their point estimate
Revelation: All team members reveal their estimates simultaneously
Discussion of differences: If estimates vary significantly, team members explain their reasoning
Re-estimation: The team votes again after discussion, repeating until consensus is reached

The Psychology Behind Planning Poker

Planning Poker's effectiveness stems from several psychological principles:

Independent thinking: Silent estimation prevents anchoring bias and groupthink
Wisdom of crowds: Aggregating multiple independent estimates often produces better results than a single expert's opinion
Constructive disagreement: Differences in estimates highlight misunderstandings or hidden complexity
Shared ownership: The collaborative process builds team commitment to estimates

Running Effective Planning Poker Sessions

Before the Session

Ensure stories are refined enough for estimation
Establish or review the team's Definition of Ready
Select a baseline story as a reference point
Prepare poker cards or use a digital tool like Alignlee

During the Session

Timebox discussions: Limit initial discussion to 2-3 minutes
Focus on clarification: Questions should seek understanding, not dive into implementation details
Reveal simultaneously: This prevents anchoring bias from the first few voices
Address outliers first: Have the highest and lowest estimators explain their thinking
Keep re-estimation rounds brief: Move on if consensus isn't reached after 2-3 rounds
Record assumptions: Document key assumptions that influenced the final estimate

Common Planning Poker Pitfalls

Dominant voices influencing estimates: Ensure everyone participates equally, and consider having senior members reveal last

Sessions running too long: Limit discussion time and consider splitting stories that generate excessive debate

Pressure to conform: Create psychological safety for dissenting opinions—they often reveal important insights

Too much focus on precision: Remember that the goal is shared understanding, not perfect estimates

Establishing Your Story Point Baseline

A critical but often overlooked step in relative sizing is establishing a solid baseline—a reference story that all other estimates are compared against.

Selecting a Good Baseline Story

The ideal baseline story should be:

Well understood by all team members
Of medium complexity (usually assigned a value of 3 or 5)
Recently completed, so it's fresh in memory
Representative of typical work the team does

Creating a Sizing Scale Guide

Many teams create a sizing scale guide with example stories for each point value:

1 point: "Add field validation to the signup form"
3 points: "Implement password reset functionality"
5 points: "Create a dashboard showing user activity metrics"
8 points: "Implement OAuth authentication with multiple providers"
13 points: "Redesign the checkout process with A/B testing capability"

This guide evolves over time as the team completes more work and refines their understanding of different sizes.

Virtual Planning Poker for Distributed Teams

With the rise of remote work, virtual Planning Poker has become essential. Tools like Alignlee enable distributed teams to follow the same principles effectively:

Best Practices for Remote Estimation

Use video whenever possible to read non-verbal cues
Ensure everyone has reviewed stories before the session
Use digital tools that enforce simultaneous reveal
Actively facilitate to ensure all voices are heard
Use shared documentation for recording questions and assumptions
Consider asynchronous pre-voting for teams across time zones

Beyond Planning Poker: Alternative Estimation Techniques

While Planning Poker is the most popular technique, several alternatives may better suit certain teams or contexts:

Affinity Estimation

A spatial approach where team members physically arrange story cards in relative size order. Ideal for initial sizing of a large backlog.

Place reference stories representing different sizes
Team members silently place new stories relative to references
Discuss and adjust outliers
Assign point values to groups

T-Shirt Sizing

Uses familiar clothing sizes (XS, S, M, L, XL) as a simpler scale. Often used for very high-level initial estimates or with non-technical stakeholders.

Dot Voting

Team members place dots on a scale to indicate their estimates. The visual clustering helps identify consensus and outliers at a glance.

#NoEstimates and Counting Approach

Some teams forego detailed estimation entirely, instead focusing on breaking stories into similar-sized items and simply counting them. This approach works best for mature teams with stable velocity and consistently sized stories.

Translating Story Points to Timelines

While story points intentionally avoid time units, stakeholders often need timeline projections. Here's how to bridge this gap responsibly:

Using Velocity for Forecasting

After several sprints, calculate your team's average velocity (points completed per sprint). This allows you to forecast approximately how many sprints a given backlog will require:

Example: If your team's average velocity is 25 points per sprint and your release backlog contains 100 points, you can forecast approximately 4 sprints to completion.

Using Range Forecasting

For more realistic projections, use ranges based on historical velocity:

Optimistic: Based on highest historical velocity
Expected: Based on average velocity
Conservative: Based on lowest historical velocity

Example: "This 100-point release will take between 3 sprints (optimistic) and 5 sprints (conservative), with 4 sprints being most likely."

Evolving Your Estimation Practice

Estimation is not a static practice but evolves as teams mature:

For New Teams

Start with simpler scales (T-shirt sizes)
Estimate frequently to build consensus on sizing
Re-estimate completed stories to calibrate understanding
Discuss estimates extensively to build shared context

For Established Teams

Move to more nuanced scales (Fibonacci)
Reduce estimation frequency for routine work
Maintain a library of reference stories
Track estimation accuracy to identify patterns

For Advanced Teams

Consider lighter estimation approaches
Focus estimation effort on high-risk or uncertain items
Use historical data to pre-suggest estimates
Evolve toward more standardized story sizes

Measuring Estimation Effectiveness

How do you know if your estimation process is working? Look for these indicators:

Positive Signs

Stable velocity over time
Consistent story completion within sprints
Minimal scope changes mid-sprint
Short estimation sessions with minimal debate
Team members referencing past stories when estimating

Warning Signs

Wildly varying velocity
Stories frequently rolling over between sprints
Estimation sessions becoming contentious
Team members pushing for specific estimates
Management pressure to reduce estimates

Conclusion

Relative sizing with Planning Poker offers agile teams a powerful approach to estimation that acknowledges the inherent uncertainty in software development while providing the forecasting capability needed for effective planning.

The true value of estimation lies not in the numbers themselves but in the conversations they generate. The best estimation processes build shared understanding, uncover hidden complexity, and create alignment around what's being built.

By mastering relative sizing techniques and adapting them to your team's specific context, you can transform estimation from a dreaded chore into a valuable tool for delivering better software more predictably.

Agile Estimation Techniques: Mastering Relative Sizing with Planning Poker