Agile Estimation Techniques

Estimating work effectively is a foundational skill for any product manager working in agile teams. The trap is to treat estimation as a solo activity or as a crude guess. The actual job is to use collaborative techniques that build shared understanding of complexity and effort — so the team can plan realistically and forecast velocity.

Three agile estimation techniques stand out in Indian product teams: Planning Poker, T-shirt sizes, and Relative Mass Valuation. Each has its place, strengths, and limitations.

Planning Poker builds consensus through discussion

Planning Poker is the most popular and structured method for agile estimation. The process is simple but powerful:

• Every team member receives a set of cards, typically numbered using the Fibonacci sequence from 0 to 21.
• The product owner or PM reads a user story aloud to the team.
• Each team member privately selects a card representing their estimate of the story’s effort or complexity.
• Everyone reveals their chosen card simultaneously.
• The team members with the highest and lowest estimates explain their reasoning.
• The team discusses differences until they reach consensus or a close approximation.
• The agreed story point value is assigned to the user story.

This method forces the entire team to engage with the story’s complexity, surface assumptions, and calibrate their understanding. It avoids the problem of dominant voices or anchoring bias because all estimates are revealed simultaneously.

The use of Fibonacci numbers is deliberate: the increasing gaps reflect the growing uncertainty and risk in estimating larger tasks. Stories scoring above 21 points signal that the task is too large or complex and should be broken down further.

In practice, I have seen Indian teams use Planning Poker to great effect in sprint planning sessions. It creates a shared language for complexity and effort — which is essential when team members have varying experience and domain knowledge.

T-shirt sizes allow abstract, fast estimation

When precision is less critical or when the team is new to estimation, T-shirt sizing is a practical alternative. Instead of numbers, stories are estimated as XS, S, M, L, XL, or XXL.

This method removes the pressure to assign exact values and encourages thinking about effort in broad buckets. It is especially useful in early backlog grooming or when the team needs a quick relative sizing without detailed discussion.

The downside is that T-shirt sizes do not translate directly into numerical values, making velocity calculations and forecasting less precise. Teams often convert T-shirt sizes to story points later, or use them as a first pass before refining estimates.

In Indian agile teams, I have observed T-shirt sizing used effectively in large programs where many stakeholders contribute and the goal is to quickly triage work rather than nail exact effort.

Relative Mass Valuation sorts large backlogs quickly

Relative Mass Valuation (RMV) is a fast method to estimate large backlogs by sorting stories relative to each other.

The process:

• Write each user story on a card or sticky note.
• Select a random story and ask the team to classify it as small, medium, or large.
• Place the story at the appropriate end of a table or whiteboard.
• Pick another story and compare it to the stories already placed, positioning it between small and large as appropriate.
• Continue until all stories are ordered from smallest to largest effort.

This method works like a binary sort algorithm — the team quickly narrows down relative sizes without assigning numeric values upfront.

RMV is useful when the backlog is large and teams want a quick, rough ordering of effort before deeper estimation.

In Indian product teams managing extensive backlogs, RMV helps unblock prioritization discussions and brings clarity on what is truly big or small work.

Story points vs person-hours: why complexity matters more

Traditional estimation methods use person-hours — how many hours a task will take. This is notoriously inaccurate because:

• Team members cannot foresee all hurdles.
• Individual skill levels vary.
• Estimators are optimistic or biased.
• Projects change scope mid-way.

Story points estimate complexity and effort relative to other stories, not absolute time. This distinction makes velocity more stable even when team composition changes.

For example, a story with 8 points is roughly twice as complex as a 4-point story regardless of who executes it.

Indian agile teams adopting story points find it easier to forecast sprint capacity and manage stakeholder expectations.

Velocity is your team's speed, not a target

Velocity measures how many story points a team completes in a sprint. It is a lagging indicator — a reflection of past performance, not a goal.

New teams often make the mistake of pushing to increase velocity artificially, which leads to gaming estimates or cutting quality.

The actual job is to use velocity trends to forecast delivery dates and adjust scope realistically.

Test yourself: Choosing an estimation technique

Field exercise: Run a Planning Poker session (time=15 min)

Pick a current product backlog or a set of user stories. Gather your team or a group of colleagues. Follow these steps:

1. Prepare a set of Fibonacci cards or paper slips numbered 0, 1, 2, 3, 5, 8, 13, 21.
2. Read the first user story aloud.
3. Ask everyone to select a card privately for their estimate.
4. Reveal cards simultaneously.
5. Invite the highest and lowest estimators to explain their reasoning.
6. Discuss and re-estimate until consensus or near-consensus is reached.
7. Record the agreed story point.
8. Repeat for 5-10 stories.

Reflect on how discussions surfaced assumptions and aligned the team.

The trap of precision: don’t confuse estimation with commitment

Estimates are guesses, not promises. Many teams fall into the trap of treating story points as exact commitments or deadlines.

The honest truth is that estimation is inherently uncertain. The goal is to improve over time, learn from velocity trends, and adjust plans accordingly.

Indian startups often face pressure to over-commit in sprint planning. As PM, your job is to push back and set realistic expectations.

Where to go next

• If you want to master backlog prioritization: Mastering Prioritization Techniques
• If you want to improve your sprint planning: Sprint Planning Best Practices
• If you want to understand user stories deeply: Writing Effective User Stories
• If you want to develop team collaboration skills: Facilitating Agile Ceremonies

PL alumni now work at Razorpay, Swiggy, Flipkart, PhonePe, and other top Indian companies.