Story Points vs. Man‑Days: When to Use Which Method?

Introduction

In IT project planning discussions, the question often arises: should we estimate work in story points or in man‑days? For many teams, story points are a natural tool for sprint planning and delivery forecasting. For business stakeholders, man‑days are more intuitive because they can be directly tied to budget, team capacity, and timelines. The problem is that both methods serve slightly different purposes, and mixing them without understanding the context leads to wrong decisions.

It’s not about choosing a single “best” method forever. More important is to understand what we want to measure, who the audience is, and what decisions we need to make based on the estimate. Story points and man‑days can complement each other, but only when the team clearly communicates the limitations of each metric.

Business Problem

From a business perspective, the most frequent questions are: how long will it take, how much will it cost, and what can actually be delivered within the agreed timeline. Man‑days feel convenient because they directly suggest the amount of work. If a team says something will take 20 man‑days, stakeholders immediately translate that into “two people for two weeks”. This shortcut is tempting, but it ignores context: people’s availability, communication overhead, technical dependencies, and uncertainty.

Story points, on the other hand, are often criticized by business stakeholders for not translating directly into cost. If a team says 40 points, but cannot explain how that impacts schedule or budget, managers may feel they’re getting an abstract metric. The issue isn’t the method itself, but misuse. Story points are meant to help predict team velocity, not replace a conversation about cost.

Technical Explanation

Story points measure relative complexity. The team compares tasks against each other, taking into account scope, risk, uncertainty, and implementation effort. This allows maintaining consistent planning even when different people work at different speeds. The key concept is velocity – the number of points a team delivers in each iteration. When velocity is stable, story points support short‑term planning well.

Man‑days attempt to describe work in a unit of time, usually representing one person’s workday. This metric is more direct but also prone to false precision. In practice, a task estimated at two days may take four if new integration, unclear requirements, or unexpected fixes appear. Man‑days work best when the scope and implementation approach are already well understood.

The crucial technical rule is not to treat story points as hidden hours. If a team says one point equals half a day, story points lose their purpose and become just another way of estimating time, defeating the benefit of relative difficulty comparison.

Practical Example

Imagine a SaaS team building an HR application. The backlog contains three items: CSV report export, user‑role configuration, and integration with an external SSO system. Export is well‑known and similar to past work. Role configuration is moderately complex and touches many screens. SSO integration looks simple on the UI side but carries risk due to provider documentation and security concerns.

In story points the team might assign:

• Export: 2 points (low risk)
• Roles: 5 points (moderate risk)
• SSO: 8 points (high risk and unknowns)

A business stakeholder might intuitively assume the SSO integration will take less time than the role work because “it’s just login”. Here story points better highlight that the task is riskier and potentially more effort‑heavy. Conversely, with historical velocity data, the team can translate points into a timeline and cost for the business.

Common Mistakes

• Using a single method for everything. Story points are weak for direct budget conversations if velocity isn’t stable. Man‑days are risky as the sole sprint‑planning metric when the backlog is full of unknowns.
• Comparing velocity across teams. Points are team‑specific and should not be used for performance rankings.
• Over‑granular estimation. Breaking every task into fractions of a day or overly precise points makes planning costly and adds little value.
• Expecting man‑day estimates to be a deadline guarantee rather than an approximation based on known scope and identified risks.

Recommendations

1. Use story points for iterative planning and assessing relative complexity within the team.
2. Translate story points to time and cost only after establishing a stable velocity and clarifying scope.
3. Employ man‑days for budgeting, forecasting, or capacity modelling when the scope is well‑defined and risks are transparent.
4. Combine both perspectives: plan the backlog in story points, then convert to a time/cost range for business stakeholders using historical data and risk buffers.

Summary

Story points and man‑days are not competing religions but tools for different decision‑making contexts. Story points help teams gauge relative complexity and plan work under uncertainty. Man‑days help communicate capacity, budget, and expected effort in language more familiar to business. The key is to clearly define the goal of the estimate and avoid expecting a single metric to answer all questions. When teams understand the differences and can translate between them, planning becomes more transparent and the risk of miscommunication drops dramatically.