Estimation Methods

Four units on one screen

Here is the whole comparison first, because it is what you came for. The four units are usually argued about as if one of them were correct and the others were mistakes. They are not rivals. They measure different things, suit work of different sizes, and hand the job of turning effort into a date to different people. Read the table by row to understand one unit, and by column to see where they really differ.

The column that matters most is the fifth. Every estimate is eventually turned into a date, because a client, a sponsor or a release plan needs one. With story points the factor that converts size into time is measured after the fact: it is the velocity the team actually achieved over its last few sprints. With man-days and hours the factor is assumed before the work starts — somebody decides that a day holds six productive hours, or that four people finish four times faster. That single difference explains most of the arguments about which unit is better.

Which unit for which decision

An estimate is a range, not a date

The most useful idea about estimation is also the least practised: an estimate is a probability distribution, and the number people say out loud is usually its most optimistic reasonable point. Everything else on this page — which unit, which scale, which ritual — matters less than that.

Three words get mixed up, and the mix-up causes most estimation fights. Steve McConnell separates them in Software Estimation (2006). An estimate is a prediction of how long something will take. A target is a statement of what the business wants — “we need this before the conference in March”. A commitment is a promise to deliver by a date, and it should be made from the estimate, not in place of it. When a manager asks “can you do it by March?”, they are asking whether the estimate supports the target, and the honest answer is a probability, not a yes.

Durations of work are skewed to the right. A task cannot finish in less than no time, but it can easily take three times as long as planned, and there are more ways for things to go wrong than to go right. On a skewed distribution the most likely value, the median and the average are three different numbers, in that order. When someone pictures the work going normally and says a number, they are naming the most likely value — which, with a spread like the one in the diagram, is met only about three times in ten.

How precise can it be?

Precision depends on what is known, and at the start very little is. Barry Boehm measured this in 1981, and Steve McConnell later popularised it as the cone of uncertainty: at the first idea, the real effort can land anywhere from a quarter to four times the estimate, and the range narrows as decisions are made. PMBOKPMBOKA Guide to the Project Management Body of Knowledge — PMI’s project management referenceThe Project Management Institute’s reference for managing projects, and the basis of the PMP certification. The edition matters: the 6th (2017) prescribed 49 processes, the 7th (2021) replaced them with twelve principles, and the 8th (2025) has six principles, seven domains and forty processes.Full article →All terms uses a similar ladder for cost — a rough order of magnitude at the start is expected to land within −25% to +75%, a definitive estimate within −5% to +10%.

Two warnings come with the cone. It is the best case, not the default: Todd Little’s data from Landmark Graphics (IEEE Software, 2006) showed the ratio of actual to estimated duration staying about as wide late in projects as early. The cone narrows only when the team makes decisions that remove variability — cutting scope, settling an architecture, finishing the risky integration — not merely because time passes. And a range narrower than the stage allows is not precision; it is a guess in a suit.

Story points: relative size

A story point is a unit of relative size. The team picks a reference item it has already delivered — a small, well-understood story — calls it a 2 or a 3, and sizes everything else by comparison: this is about twice that one, this is a bit smaller. The number deliberately bundles three things: the volume of work, its complexity and the uncertainty about it. A dull but large data migration and a small change to code nobody understands can both be an 8.

The unit is abstract on purpose. People are poor at predicting absolute durations and good at comparing two things side by side, and a relative scale uses the skill they have. It also cannot be read as a promise: three points is not three days for anyone, so nobody outside the team can hold the team to it as if it were.

Why the scale has gaps

Most teams use a modified Fibonacci sequence — 1, 2, 3, 5, 8, 13, 20, 40, 100 — often with a ½, a 0 and a “?” card. The gaps grow because precision should fall as size grows. The difference between a 2 and a 3 is visible; the difference between a 13 and a 14 is not, and a scale that offered 14 would start an argument nobody can win. Mike Cohn, whose Agile Estimating and Planning (2005) spread this sequence, explains it with Weber’s law from psychology: we perceive differences as percentages, not as absolute amounts, so the steps should be roughly proportional too.

Anything at 20 or above is not an estimate but a signal. The item is too large or too unclear to size, and the right response is to split it, or to run a spike — a short, time-boxed investigation — and estimate again afterwards.

Planning poker, step by step

Planning poker was described by James Grenning in 2002 and popularised by Mike Cohn’s 2005 book. Its value is not the number it produces. It is that it makes disagreement visible before the work starts, while disagreement is still cheap.

1. 1.One round of planning poker

   1. 1.1The Product OwnerProduct Ownerowns what gets builtThe one person accountable for what the team builds and in what order. The authority is real — a Product Owner who has to get every decision approved elsewhere is a messenger, and the role stops working.Full article →All terms reads the item and answers questions. Nobody estimates yet.
   2. 1.2Everyone picks a card privately.
   3. 1.3All cards are turned over at once, so nobody anchors on the first voice.
   4. 1.4The highest and the lowest explain their reasoning — they usually know something the others do not.
   5. 1.5Vote again. Stop when the cards are close; if two neighbouring values remain, take the larger and move on.
   6. 1.6Time-box it: an item that does not converge in two or three rounds needs splitting or a spike, not a fourth vote.

There is evidence for why this works. In 2008 Kjetil Moløkken-Østvold, Nils Christian Haugen and Hans Christian Benestad studied a Norwegian software company and found that estimates reached in planning poker were less optimistic, and more accurate, than the average of the same people’s individual estimates for the same tasks. The discussion finds the work somebody forgot. The Scrum page describes the same effect from the other side: a 2 and a 13 on one item are not an arithmetic disagreement but two different understandings of the task.

From points to a date

Points become a date through velocity: the points the team actually completes per sprint, measured over its last three to six sprints. Forecast with the range, not the average. If the last six sprints delivered between 24 and 35 points and 180 points remain, the honest answer is “between six and eight sprints”. Saying “seven” throws away the most useful part of what you know.

Where points came from, and the second thoughts

Story points came out of Extreme ProgrammingExtreme Programmingthe engineering-first agile methodAn agile methodology from the late 1990s built around engineering practices: test-first development, pair programming, continuous integration, refactoring and small, frequent releases. Much of what teams now call technical agility comes from it, and a team that adopts Scrum’s events without these practices usually watches its sprints slow down.All terms, on the Chrysler C3 payroll project in the late 1990s. Ron Jeffries has described how. The team first estimated in “ideal days” — how long a pair would take if nobody interrupted them — and multiplied by a load factor of about three to get real time, so a story of three ideal days took about nine. Explaining why an ideal day took three real ones confused everybody, so they started calling ideal days simply points. In 2019 Jeffries wrote: “I may have invented story points, and if I did, I’m sorry now.” His objection is not to relative sizing. It is to what organisations did with it: velocity charts compared across teams, and points demanded as output.

The fifth option: stop estimating and count

Jeffries now recommends what the #NoEstimates movement, started by Woody Zuill around 2012, has argued all along: slice every item small enough to finish in a day or two, then forecast by counting items instead of adding points. Once items are consistently small, their count predicts almost as well as their sum, and the hour spent arguing a 3 against a 5 goes back into splitting. It is not the absence of forecasting. It is forecasting from throughput — the method the Kanban page describes with percentiles and Monte CarloMonte Carlosimulation by many random runsA method that answers a question by running it thousands of times with randomly sampled inputs and reading the distribution of the results. On a schedule it replaces a single date with a range and a probability, which is the honest form of an estimate built out of twenty uncertain tasks.All terms — and Siemens Health Services’ 2012 switch, with its numbers, is on the Scrumban page.

Man-days: effort in people’s time

A man-day (MD), also called a person-day, is one day of one person’s work, usually counted as eight hours. It is an absolute unit of effort, and in service companies it is the unit money is counted in: a quote, a fixed-price bid, a rate card and a time-and-materials invoice are all in man-days or their bigger siblings. A man-month is conventionally around 20–21 working days, or about 160–168 hours, depending on the country and the contract.

The first trap is that effort is not duration. Twenty man-days is not four working weeks for one person, nor two weeks for two. It is twenty days of focused work, which somebody still has to spread across a calendar full of meetings, reviews, holidays and support duty. Teams handle this with a focus factor — the share of a working day that goes to the planned work. The number is a local measurement, not a law. A team that assumes 0.8 and actually runs at 0.6 is a third late before a single line of code misbehaves.

Why people are not interchangeable

The second trap is subtler, and it has a name. Fred Brooks managed IBM’s OS/360 and wrote The Mythical Man-Month (1975) about what he learned. The man-month treats people and months as interchangeable, he argued, and they are interchangeable only for work that can be split without anyone needing to talk to anyone else. Software is the opposite. Every person added must be brought up to speed by someone who already knows the system, and every pair of people is one more line of communication.

The number of lines grows as n(n−1)/2: three people have three, six have fifteen, twelve have sixty-six. Brooks’s law follows from it — adding people to a late software project makes it later, because the newcomers spend the time of the people who know the system before they contribute any of their own. In the 1995 anniversary edition Brooks admitted the law was an outrageous simplification and stood by it anyway, as “the best zeroth-order approximation of truth”. For a man-day estimate the lesson is concrete: the MD total does not tell you the calendar, and more people shorten it less than the arithmetic promises.

Three numbers instead of one

The standard correction for a single optimistic number is to ask for three: optimistic (O), most likely (M) and pessimistic (P). PERT, developed for the US Navy’s Polaris programme in 1958, combines them as (O + 4M + P) ÷ 6, with a spread of roughly (P − O) ÷ 6. The formula matters less than the question it forces. “And what would the bad week look like?” is the question single-number estimation never asks.

Read the table twice. The three most likely values add up to 21 man-days; the expected total is 24.5, and the difference is the long right-hand tail showing through. And the first two tasks have the same expected value of 6.0 while carrying very different risk: the reports will almost certainly take a week, the payment integration might take nearly three. A single number would have made them look identical.

Hours: the finest grain

Hours are man-days at a finer grain, and they are the right unit for one kind of work: small, familiar tasks that take less than a couple of days. Splitting a sprint item into tasks of two to six hours, fixing a known kind of bug, an operations ticket — at that size an engineer’s estimate in hours is usually decent, because they did the same thing recently and can picture every step.

Above that size hours become false precision. An estimate of 340 hours for a feature claims to be accurate to about one percent, on something whose real range at that stage is a factor of two. The number is not more accurate than “about two months”; it only looks it, and anybody who adds it into a plan inherits a precision that never existed.

Four laws that eat hour estimates

Together they explain a result that surprises new managers: adding a safety margin to every task makes projects later, not safer. Each task’s margin is consumed locally, by Parkinson and by the student syndrome, and no task ever gives time back — a task finished early is simply handed over later. Goldratt’s answer in Critical Chain is to strip the margin from individual tasks and hold it as one shared project buffer, spent visibly and only when something actually needs it.

T-shirt sizes: order of magnitude

T-shirt sizing puts items into a handful of classes — XS, S, M, L, XL — instead of giving them numbers. It is the coarsest of the four units, and that is its purpose: it is for the stage where anything finer would be invented. Roadmap lines, epicsepica large backlog itemA large piece of work that is split into features or stories before anyone builds it, best written as a bet with a hypothesis and a condition that closes it. Its size depends on whose vocabulary is in use — anything above a story in Jira, a portfolio investment with a business case in SAFe — so check before comparing two epics.Full article →All terms, a portfolio of candidate projects, a first conversation with a client about what something might cost.

It is also fast. In affinity estimation, a team lays forty or fifty items on a wall and silently sorts them into columns by size, then discusses only the items people keep moving. A backlog that would take a day of planning poker is sized in an hour, to exactly the precision the stage deserves.

Every size must mean a range

The step teams skip is the one that makes sizes useful: agreeing, in writing, what each size means in a real unit. Without it one person’s L is another’s M, and the sizes carry no information to anyone outside the room. The ranges below are an example for one team; yours will differ, and they should be wide.

The ranges roughly double or triple at each step, for the same reason the Fibonacci scale has gaps: an honest size gets less precise as it gets bigger. And XL is deliberately not a size at all. It is the label for “we do not know enough yet”, and the useful response to it is work that finds out, not a bigger number.

Six estimates and what they missed

These are worth knowing because each one is documented in public — by the organisation it happened to, in a peer-reviewed study, or in the book its author wrote about it — and because each one shows a different way an estimate goes wrong. None of them is a story about lazy people.

Where estimation turns into theatre

Estimation is easy to perform without doing. The numbers look like data, the ceremonies look like diligence, and nothing about a well-filled estimate field says whether it changed a single decision. The diagram shows the most common shape of the theatre.

The chart is illustrative, but the mechanism is not. VelocityVelocityhow much fits in a sprintHow much a team actually completes in a sprint, averaged over several. It is a planning aid for that one team and nothing else — comparing the velocity of two teams, or setting it as a target, reliably produces inflated estimates rather than more work.Full article →All terms is the team’s own number, produced by the team’s own estimates. Make it a target and the cheapest way to raise it is to estimate bigger — nobody has to lie, the 3s simply start to feel like 5s. It is Goodhart’s lawGoodhart's lawa target stops being a measureThe observation, named after the economist Charles Goodhart (1975), that a measure stops being a good measure once people are rewarded for moving it. Nobody has to cheat for it to happen; the usual defence is a second, guardrail metric that would break if the first were gamed.Full article →All terms in its usual form: when a measure becomes a target, it ceases to be a good measure. The other shapes are variations on the same theme.

• Points converted to hours in the tracker, then reported upward as if they were hours.
• Velocity compared across teams, or written into a performance review.
• The estimate negotiated down in the meeting — “could it be a 3?” — so the plan fits the date.
• Every item estimated, including the half of the backlog that will never be built.
• Finished items re-estimated upward so the sprint “hits” its number.
• A single date promised to the client from a range the team gave with a caveat nobody forwarded.
• Hour estimates compared with logged hours, person by person.

And the honest limit. No unit fixes the thing that makes software estimates wrong: the work is only fully known once it is done. Estimation reduces the error in the part you understand; it does nothing for the part nobody has imagined yet, and in Flyvbjerg’s data that part is where projects die. The controls for it are not estimation techniques. They are small batches, so a wrong estimate costs a week rather than a quarter; the riskiest piece delivered first, so the surprise arrives while there is still time to act on it; and a forecast re-made every sprint from what actually happened, instead of defended from what was said in month one.

When to use it

Related pages

• ManagementUser StoriesA user story is a short description of a need from the user’s point of view, written to start a conversation rather than to replace one. The template is the least important part; the skill is slicing work so that every story gives a user something they can actually use, and agreeing before the work starts how everyone will know it is done. The page opens with sixteen stories as teams actually write them, what is wrong with each and the rewrite, then covers card, conversation and confirmation, acceptance criteria and example mapping, nine ways to split a story, story mapping, INVEST, spikes and points, five episodes from the format’s history, and where it degrades.
• ManagementRisk ManagementRisk management is deciding in advance what could go wrong, which of those things is worth spending money on now, and who will notice if one starts happening. A risk is not a problem yet, and that is the entire reason it is cheap to deal with. The page opens with the whole map — seven groups and twenty-eight lines to check your own project against — then covers how to size a risk without faking precision, the four responses, the practices that actually move the number, and six public failures with the control that was missing from each.
• ManagementKanbanKanban is a way of managing work that starts from your current process and improves it by limiting work in progress and measuring how that work flows. It adds no roles and no sprints. The page opens with every element of a Kanban system on one screen — what a team writes down and what its absence looks like — then covers why a board alone is not Kanban and the two bodies that define the method, its six principles and six practices, the four flow measures and the arithmetic under them, forecasting from history instead of estimates, the seven cadences, five documented cases, and where it degrades.