Agile Estimates

Estimating work is one of the most misunderstood aspects of agile product management. The actual job is not to produce perfect estimates — that is impossible — but to use estimation as a tool for planning and learning. Most PMs struggle because they confuse two fundamentally different units of measurement: person hours and story points.

Person hours measure the effort needed to complete a task in terms of uninterrupted work time. One person hour equals one hour of focused work by one team member. Story points, on the other hand, measure relative complexity — a unitless score that reflects how much effort a story requires compared to others.

Understanding the strengths and limitations of each is essential to making better planning decisions and setting realistic expectations.

Person Hours: What They Measure and Why They Fail

Person hours are straightforward: if a developer spends one hour fully focused on a task, that's one person hour. If two developers work simultaneously for six hours each, that totals 12 person hours.

For example, imagine you have three user stories in your backlog, and you need to complete the first story in 10 days. You have two team members, John and Jane. Each spends about two hours daily on emails and meetings, leaving six productive hours in an eight-hour day. The total person hours to complete that story would be:

2 persons × 10 days × 6 hours = 120 person hours

This calculation seems simple, but estimating person hours accurately is surprisingly difficult.

Why person hours are unreliable

• Some tasks are inherently difficult to estimate. Research-heavy or novel work has unpredictable timelines.
• Team members often underestimate hurdles. They may not foresee complexities or dependencies.
• Managers may overlook experience levels. Assigning the same hours to junior and senior team members leads to inaccurate plans.

These issues mean person hours often fail to provide a reliable basis for sprint planning. They work best when tasks are repetitive and the assignee has prior experience.

Story Points: Estimating Complexity, Not Time

Story points emerged to address the limitations of person hours. Instead of estimating absolute time, story points estimate relative complexity — how hard or large a user story is compared to others.

Effort = Complexity = Story Points

Story points use scales like the Fibonacci sequence (0, 0.5, 1, 3, 5, 8, 13, 20, 40, 100) to reflect increasing uncertainty and complexity. For example, a story estimated at 8 points should be roughly twice as complex as a 5-point story.

The key difference is that story points are assigned collaboratively by the whole team, not by individuals. This collective approach balances out individual biases and experience levels.

Example of story point estimation

Consider three user stories:

1. As a cloud user, I want to open an existing file on the platform.
2. As a cloud user, I want to save a new file to the platform.
3. As a cloud user, I want to automatically back up files to the platform.

The development team unanimously picks User Story 2 as the simplest and assigns it 1 story point. They decide User Story 1 is more complex and assign it 5 points. This relative scoring helps the team understand the workload distribution without committing to exact hours.

Why story points work better than person hours

• Story points do not depend on individual experience. The team agrees on complexity, which stays consistent despite team changes.
• They capture uncertainty better than time estimates. Larger stories get exponentially larger point values to reflect risk.
• Story points enable better velocity tracking over time, helping predict how much work a team can complete in a sprint.

Velocity: Measuring Team Capacity Over Time

Velocity is the average number of story points a team completes in a sprint. It reflects the team's capacity and efficiency. Tracking velocity helps you plan how many stories the team can realistically commit to.

Velocity usually stabilizes after a few sprints, giving a useful baseline for forecasting.

What velocity tells you

• Increasing velocity in new teams indicates growing efficiency and better processes.
• Stable velocity in mature teams shows consistent delivery.
• Decreasing velocity signals problems like blockers, team disruptions, or poor estimation.

Velocity is measured in story points or person hours, but story points are preferred for their consistency.

Field Exercise: Estimate Your Backlog with Story Points (15 min)

Pick three user stories from your current backlog. Gather your development team and:

1. Identify the story with the least complexity and assign it 1 story point.
2. Assign story points to the other stories relative to that baseline.
3. After a sprint, track how many story points your team completes.
4. Reflect on what velocity tells you about your team's capacity.

This exercise helps internalize the difference between time and complexity estimates and improves your sprint planning accuracy.

Judgment Exercise

From the Field: Why Story Points Matter More Than Hours

Where to go next

• Learn to break down work effectively: User Stories and Epics
• Master sprint planning and execution: Sprint Planning and Agile Ceremonies
• Understand how to measure team performance: Metrics and KPIs
• Improve your stakeholder communication: Managing Expectations and Reporting

PL alumni now work at Razorpay, Swiggy, Flipkart, PhonePe, and dozens of other Indian startups.