Agile Estimates

Agile estimation is one of the most misunderstood parts of product delivery. You will hear a lot about person hours and story points — two units that measure work effort very differently. The trap is to treat them as interchangeable or to rely on person hours alone, which leads to inaccurate forecasts and missed deadlines.

Your actual job is to understand why story points exist, how they capture complexity rather than time, and how velocity turns these estimates into meaningful predictions about your team’s capacity.

Person hours measure effort, but they are unreliable

Person hours are the simplest unit: one hour of uninterrupted work effort equals one person hour. For example, if a developer spends two hours coding a feature, that’s two person hours.

This seems straightforward — but it quickly breaks down in practice. Why?

• Some tasks are inherently difficult to estimate in hours, especially those involving research or exploration. You might say, “This will take two hours,” because you’ve done it before. But if it’s new or uncertain, you don’t know how long it will actually take.

• Team members often underestimate the time required because they cannot foresee hidden hurdles or added complexities. This leads to optimistic estimates that miss real-world challenges.

• The person assigning the hours — often a project lead, product manager, or project manager — may overlook individual experience levels. A junior engineer might be allocated two hours for a task, but realistically, it will take four.

These inaccuracies mean that person hours work only if the person doing the task has done it before and can reliably predict the effort. Otherwise, person hours become a source of error and rework.

Story points capture complexity, not time

Story points are a fundamentally different approach. They represent the complexity of a task relative to other tasks, not the absolute time it takes.

At its core, a story point is a score assigned by the whole team to a user story, reflecting how complex or difficult it is. The actual time taken can vary between individuals, but the complexity remains constant.

For example, consider two developers:

• Developer A estimates a task will take 4 hours because they have done it before and know the pitfalls.

• Developer B estimates 1 hour for the same task because they are an expert in that area.

Both are correct for themselves, but if you were to use person hours for estimation, the variance would cause confusion. Story points sidestep this by focusing on the relative effort.

Teams often use scales like the Fibonacci sequence (1, 2, 3, 5, 8, 13...) or T-shirt sizes (Small, Medium, Large, Extra Large) to assign story points. The key is to maintain consistency in how the team interprets these numbers.

Story points are a team agreement, not an individual estimate

An important distinction is that story points are assigned by the team as a whole, not by individuals. This collective agreement brings flexibility.

Imagine your team changes — some members leave, new ones join — but the project remains the same. If you were using person hours, you would have to re-estimate every task based on the new team’s availability and skill. This shifts timelines and creates confusion.

With story points, the complexity of a user story does not change with team composition. The story point value stays fixed because it measures the task’s inherent difficulty, not who does it or how fast.

This makes story points a stable yardstick for planning and tracking progress across sprints, regardless of fluctuations in team personnel.

Velocity measures how fast your team delivers complexity

Velocity is a simple but powerful concept: it is how much work your team can complete in a sprint, measured in story points.

Think of velocity as the speed at which you travel from the start of a sprint to its completion. If your team completes 40 story points in a two-week sprint, that is your velocity.

Tracking velocity over multiple sprints helps you forecast how many story points your team can handle in future sprints. This enables realistic planning and sets expectations with stakeholders.

Higher velocity means greater team capacity, but remember — velocity is unique to each team. Comparing velocity across teams is misleading because each team’s interpretation of story points differs.

How to assign story points effectively

Assigning story points is often done using techniques like Planning Poker:

• Each team member privately selects a card representing their estimate.

• Everyone reveals their cards simultaneously.

• The highest and lowest estimates are discussed to understand the reasoning.

• The process repeats until the team reaches consensus.

This method encourages discussion and surfaces hidden complexities that might otherwise be overlooked.

Another approach is Relative Mass Valuation, where you benchmark a story and estimate others relative to it.

Consistency matters more than precision. Over time, your team will calibrate their story point estimates to reflect their actual delivery pace.

Velocity helps forecast project timelines but requires discipline

Velocity is only useful if your team commits to a consistent amount of work each sprint and does not fudge estimates.

Watch out for these anti-patterns:

• The team consistently finishes early because they commit to less work than they can handle, which slows progress.

• The team misses sprint goals because they overcommit, causing burnout and quality issues.

• Work is not broken down into small enough pieces, causing erratic progress and steep drops in burndown charts.

• The product owner changes scope mid-sprint, disrupting velocity.

During retrospectives, ask:

• Were there unforeseen challenges that affected estimates?

• Can we break down work better to uncover hidden complexity?

• Is there external pressure pushing the team beyond limits?

• Are we accurately committing to what we can deliver?

Velocity naturally varies, especially for new teams. It tends to increase as teams improve relationships and processes.

Indian context: why story points matter more than person hours

In many Indian startups and enterprises, project managers and product managers still rely heavily on person hours to estimate work.

This leads to chronic underestimation and missed deadlines because of the variability in individual skills and unforeseen complexities.

Using story points aligns better with agile principles and helps teams focus on delivering value rather than tracking clock hours.

For example, a team at a Bangalore-based SaaS startup found that switching from person hours to story points improved their sprint predictability and reduced rework.

Common questions about story points

Q: Can story points be converted to hours?

No. Story points measure complexity, not time. The actual hours vary by person, task, and context. Over multiple sprints, your velocity can help approximate how many story points your team completes per unit time.

Q: How do story points handle changing team composition?

Story points remain stable because they measure task complexity, not who does the work. Velocity may fluctuate temporarily if the team changes, but story points themselves do not.

Q: What if team members disagree on story points?

Use Planning Poker or similar consensus-building techniques. Differences in estimates reveal assumptions and unknowns. The goal is a shared understanding.

Test yourself: Sprint planning at an early-stage startup

Where to go next

• If you want to break down work into manageable chunks: User Stories and Tasks
• If you want to improve your sprint planning skills: Sprint Planning and Execution
• If you want to learn how to measure team performance: Agile Metrics and Reporting
• If you want to master backlog grooming: Backlog Management
• If you want to understand Agile roles better: Product Manager vs Product Owner