Agile Estimation Techniques for Product Managers

Agile estimation is one of those topics where many PMs stumble — not because the techniques are inherently complex, but because the purpose of estimation is often misunderstood. The trap is treating estimation as a prediction exercise rather than a communication and alignment tool.

If you approach estimation as a crystal ball, you will fail. The honest truth about agile estimation is this: the actual job is to build shared understanding quickly, not to deliver exact forecasts.

This lesson will teach you how to apply agile estimation techniques in a way that respects the realities of Indian product teams — where uncertainty is high, deadlines are tight, and stakeholder pressure is constant.

The problem with traditional estimation

Most teams start with time-based estimates: “This feature will take 10 days.” This feels concrete — managers like it, sales teams like it, leadership likes it. But the reality is far messier.

Time estimates are often wildly inaccurate because they assume perfect knowledge and no interruptions. In practice, requirements change, bugs appear, dependencies slip, and priorities shift. If you base your entire plan on these numbers, you will constantly be surprised.

Engineering teams often push back or inflate estimates to build buffer, which creates distrust. Stakeholders get frustrated when dates slip. The cycle repeats.

The pattern is consistent: time-based estimation is a promise you cannot keep, and the resulting tension wastes time and energy.

Agile estimation is about relative sizing, not absolute time

Agile teams use techniques like story points or T-shirt sizing to estimate work by relative complexity, effort, and uncertainty — not by hours or days. The goal is not to say “this will take 40 hours,” but “this is twice as complex as that.”

This reframing shifts the conversation:

• From “When will it be done?” to “How big is this compared to what we’ve done before?”
• From “I need a deadline” to “Let’s understand the relative effort and risks.”
• From “Commit to a date” to “Align on priorities and capacity.”

This is what I tell PMs: story points are a tool for calibration and prioritization, not a delivery guarantee.

Common agile estimation techniques

Story points

Story points assign a numeric value to user stories based on complexity, effort, and risk. Teams often use a Fibonacci sequence (1, 2, 3, 5, 8, 13) to reflect increasing uncertainty with size.

Advantages:

• Encourages relative thinking.
• Abstracts away from hours, reducing pressure.
• Facilitates velocity tracking over sprints.

Limitations:

• Requires team calibration and discipline.
• Can be misunderstood by stakeholders as time.
• Velocity varies by team and context, so story points don’t translate directly to calendar dates.

T-shirt sizing

T-shirt sizing uses categories like XS, S, M, L, XL to estimate stories. It’s less granular than story points but faster and easier to grasp.

Advantages:

• Quick and intuitive.
• Useful early in discovery or backlog grooming.
• Good for non-technical stakeholders.

Limitations:

• Less precise than story points.
• Needs clear definitions for each size to avoid confusion.

Timeboxing and ideal days

Some teams still estimate in ideal days or hours, often for specific tasks or bugs.

Advantages:

• Familiar to stakeholders.
• Useful for small, well-understood tasks.

Limitations:

• Prone to inaccuracies.
• Encourages false precision.

When to use each technique

The choice depends on team maturity, product phase, and stakeholder expectations.

The estimation ceremony: Planning Poker

Planning Poker is a collaborative estimation game where team members simultaneously reveal estimates for a story. Differences spark discussion and help uncover hidden risks or misunderstandings.

This ceremony is critical for alignment. It surfaces assumptions early, builds shared understanding, and fosters team ownership.

Indian product teams often skip or rush this step, leading to misaligned expectations and delivery surprises.

The trap of over-precision and micro-management

Here is the uncomfortable reality: no estimation technique will give you a perfect delivery date.

If your stakeholders demand exact deadlines and use estimates as commitments, you are setting yourself and your team up for failure.

What I tell PMs is: Manage expectations by framing estimates as hypotheses, not promises.

For example, say: “Based on relative sizing and past velocity, we expect this feature to take about 3 sprints. We will update as we learn more.”

This signals flexibility and creates space for adaptation.

Velocity: use it wisely

Velocity measures how many story points a team completes in a sprint. It can help forecast future capacity.

But velocity is a lagging indicator, not a lead indicator. It varies with team composition, technical debt, and external factors.

Indian teams at companies like Flipkart or Meesho often use velocity to set sprint goals. The trap is treating velocity as a target, which encourages gaming estimates.

The actual job is to use velocity as a guide, not a quota.

Estimation and stakeholder communication

Your actual job as a PM is not just to get an estimate but to communicate what the estimate means, what it omits, and what the risks are.

Stakeholders want to know:

• When will this be done?
• What can go wrong?
• What are the trade-offs if we want it faster?

Use estimation discussions to surface these explicitly.

For example, if a feature is large (8 points), explain it: “This is complex because of dependencies on legacy systems and unclear requirements. We can break it down or defer some parts to reduce risk.”

This builds trust and avoids surprises.

Agile estimation in Indian product teams: realities and adaptations

India’s product ecosystem is diverse. Many teams are transitioning from waterfall or hybrid processes to agile.

Here are some patterns I see:

• Engineering teams often see estimation as a negotiation — inflating numbers to build buffers.
• Product managers feel pressure from leadership to commit to dates, leading to over-promising.
• Stakeholders outside product and engineering may not understand story points, demanding time-based translations.
• Distributed teams across time zones add communication overhead, affecting estimation accuracy.

The solution is not to abandon agile estimation but to invest in education, discipline, and clear communication.

Example: Estimation at Razorpay

At Razorpay, the product teams use story points and planning poker rigorously. They calibrate velocity sprint over sprint and share velocity trends transparently with stakeholders.

When a new feature is estimated large, engineers explain the risks and unknowns. Product managers work with stakeholders to prioritize or split features.

This process reduces delivery surprises and builds credibility.

Example: Estimation challenges at a mid-stage B2B SaaS startup in Bangalore

A mid-stage SaaS startup faced repeated sprint slippages. The PM found that engineers were inflating story points to avoid pressure, and stakeholders were demanding fixed delivery dates.

The PM introduced T-shirt sizing during backlog grooming to simplify estimation and started framing estimates as ranges with confidence levels.

She also held estimation workshops to align engineering and product on what story points mean.

After three sprints, delivery predictability improved, and stakeholder frustration decreased.

Balancing estimation speed and accuracy

The trap is spending too much time estimating and re-estimating, chasing false precision.

The cleanest way to think about it: an estimate is good enough when it enables a prioritization or go/no-go decision.

If you cannot answer that, you are not ready to commit resources.

Field exercise: Applying estimation techniques

Test yourself: The estimation dilemma at a Series B fintech in Mumbai

Where to go next

• If you want to master backlog grooming and prioritization: Backlog Management and Prioritization
• If you want to improve stakeholder communication skills: Stakeholder Communication for PMs
• If you want to understand agile ceremonies beyond estimation: Agile Ceremonies and Rituals
• If you want to learn how to model requirements effectively: Writing Effective User Stories
• If you want to deepen your understanding of product delivery: Product Delivery and Execution