A developer says a story is five points. By the end of the call, someone has written “Friday” next to it. Nobody decided that. It just happened. Five points became five days, became a date, became a promise the team never made.

That move is so common we stopped noticing it. And it quietly breaks the most useful planning tool an Agile team has.

Story points were never a unit of time. They were built so we could stop pretending we can predict time. Somewhere along the way that got lost, and now half the teams I meet use points as a stopwatch with extra steps.

What the number was actually for

A story point measures size, not duration. It bundles three things a calendar can't hold in one number: how much work there is, how complex it is, and how much you don't know yet. A one is small, simple, and familiar. A thirteen is big, tangled, or full of unknowns, often all three.

The reason points work is relative estimation. People are terrible at saying “this will take eleven hours.” We're surprisingly good at saying “this one is bigger than that one.” Points lean on the thing humans are good at and skip the thing we're bad at.

So the whole invention was a way to get an honest read on relative size without dragging the team back into the fantasy of exact hours. Points were the cure for fake precision. That's the part worth keeping in your head, because the failure mode is the cure turning back into the disease.

The day a point becomes a deadline

Here's where reality walks in. A stakeholder needs to know when something ships. Fair. So someone takes the points, multiplies by a velocity assumption, and a date drops out. Then the date gets repeated in a standup. Then it shows up in a status email. By Tuesday it's a commitment, and nobody remembers it started life as a rough guess about size.

The book says points feed a forecast. Reality says the forecast hardens into a deadline while you're not looking.

The question itself isn't the problem. “When will this be done” is a perfectly reasonable thing to ask. The problem is answering it by treating a size estimate as a time guarantee. You took a number that honestly said “this is big and a bit uncertain” and you reported it as “done in eight days.” You didn't forecast. You promised on the team's behalf. And the team feels it.

How to tell it's already happened on your team

You don't need a survey. The symptoms are loud once you know them.

Estimates only ever go up. Nobody sizes anything a one anymore, because last time a small number turned into a whip. Sizing a story takes longer than doing it, because the team is negotiating their own safety instead of estimating work. Velocity is suspiciously smooth, week after week, which isn't stability, it's people steering the number. And “we'll commit to that” starts replacing “we think it's about this big.”

Here's the uncomfortable truth. The moment points become deadlines, people stop estimating and start defending. The number stops describing the work and starts protecting the person who has to say it out loud. You didn't get better forecasting. You got padded guesses wearing a forecast's clothes.

The trade you didn't know you were making

When a size estimate becomes a deadline, you're not just risking a missed date. You're spending something that never shows up on a burn-down: the team's willingness to tell you the truth early.

Think about what a good estimate is for. It surfaces risk before the work starts. A developer who says “this one's a thirteen, there's a piece here I've never touched” is handing you a gift, a warning with time still on the clock to do something about it. But if that thirteen is going to be converted into a hard date and held against them, they learn the lesson fast: don't flag the unknown, pad the number quietly and hope. The risk is still there. You just don't hear about it until it's late.

That's the real bill. Not one slipped Friday. A team that stops telling you where the danger is, because telling you got expensive. You traded honest early signals for a tidy-looking plan, and tidy-looking plans are the ones that explode in the last sprint.

It's also why “just add buffer” doesn't fix it. Buffer hidden inside the points corrupts the estimate for everyone downstream. Buffer named openly as a forecast range keeps the estimate clean. Same caution, opposite effect, depending on whether you hid it in the number or put it in the date.

What to do when someone asks for a date anyway

You can't refuse to give dates. Stakeholders run real budgets and real dependencies on your timelines, and “we're Agile, we don't do dates” is how delivery people lose the room. The job isn't to dodge the date. It's to give a real forecast without poisoning the estimate that feeds it.

Four moves do most of the work.

Separate size from schedule, out loud. “This is about an eight in size. To turn that into a date I need our recent throughput and what else is in the sprint.” Now the estimate stays an estimate, and the date is clearly a separate calculation you can stand behind.

Give a range, not a single date. “Two to four weeks, most likely three” tells the truth about what you know. “Done the 14th” tells a story you can't back. A range isn't hedging. It's the honest shape of a forecast.

Name the uncertainty the points already captured. A thirteen isn't just “big.” It's “big and we're not sure.” Say the not-sure part instead of burying it. The unknowns don't vanish when you quote a clean date. They show up later as a surprise.

Re-forecast as you learn, don't re-promise. When new information arrives, move the forecast and say why. A forecast is allowed to change. A promise that keeps changing is just a run of broken ones.

Why this is the answer that sounds senior

Here's where it pays off past your own sprint. This exact distinction is something interviewers listen for, whether they could name it or not.

Ask a junior candidate how they use story points and you'll usually get the mechanics: planning poker, Fibonacci, the points roll up into velocity. All correct. All ritual. It tells the interviewer you've run the ceremony.

Ask someone with real reps and you get the purpose and the failure mode in the same breath: points give us relative size and a rough forecast; the risk is they get treated as deadlines, and once that happens estimates stop being honest, so I keep size and schedule separate. That answer tells the interviewer you've watched this go wrong and learned what to protect. That's the gap between knowing the framework and having judgment about it. The framework is the floor. This is the ceiling, and the ceiling is what gets the offer.

If you've never been in a room where a five quietly turned into a Friday, go put yourself in one. Run a real backlog for a side project, a volunteer team, a club. Size the work, watch a manager or your own anxiety try to convert it into a date, and practice holding the line between the two. That's a true story you'll be able to tell, and it's worth more than any definition.

The number was never the promise. It was a way to stay honest about what you didn't know yet. Keep it that way and it keeps working. Turn it into a deadline, and all you've built is a slower, more elaborate way to be wrong on schedule.