Why do teams use story points instead of hours or days?

WHAT THIS TESTS: This question probes whether you understand estimation as a forecasting tool rather than a commitment device. Interviewers want to see that you grasp why relative sizing works better than absolute time guesses for knowledge work, and that you know story points are a team-level abstraction that accounts for complexity, risk, and effort together. They also care that you can articulate why hours fail in practice.

A GOOD ANSWER COVERS: A strong response moves through four ideas in order. First, define a story point as a unitless, relative measure of effort, complexity, and uncertainty, typically anchored to a small baseline story the team already completed. Second, explain that because points are relative, a team can converge on a stable velocity over several sprints, which makes capacity planning and release forecasting possible without guessing hours for every task. Third, contrast this with hours or days, which vary wildly by who does the work and create false precision; a senior engineer might finish a task in four hours while a junior needs two days, but the story point value stays constant because the work itself did not change. Fourth, note that points help surface scope creep when a story is re-estimated mid-sprint, whereas hour estimates tend to get silently padded instead of discussed.

COMMON WRONG ANSWERS: The biggest red flag is mapping points directly to hours, such as claiming one point equals four hours of work. Another failure mode is saying points exist to hide deadlines from business stakeholders; that signals cynicism and misses the forecasting value. Treating points as individual productivity scores is also dangerous because it incentivizes gaming the metric and destroys the collaborative calibration process. Finally, insisting that points are unnecessary because you can just break everything into same-sized stories shows inexperience; real backlogs contain inherently different-sized chunks of work.

LIKELY FOLLOW-UPS: An interviewer might ask how you handle a team whose velocity is fluctuating wildly, which tests whether you know to inspect for unclear acceptance criteria, external dependencies, or scope changes rather than blaming the metric. They may also ask what to do when leadership demands a date, which is a chance to show how you translate velocity ranges into probabilistic forecasts using historical variance. Another common follow-up is how you estimate spikes or non-coding work, which reveals whether you treat the estimation framework as flexible or dogmatic.

ONE CONCRETE EXAMPLE: Suppose a team picks a simple login bug fix as their three-point baseline. They later encounter a feature requiring a new API integration, unknown rate limits, and updated frontend validation. The team might estimate that story as eight points because it carries more complexity and risk than the baseline, even though no one knows yet whether the coding time will be six hours or sixteen. After three sprints, the team averages thirty completed points per sprint. When the product owner asks how long the remaining sixty-point backlog will take, the team can say roughly two sprints plus or minus one, based on historical variance, without ever converting points to hours.