Explain story points and why they're used over time-based estimates

WHAT THIS TESTS: This question assesses your practical understanding of agile estimation techniques. The interviewer is looking for more than a textbook definition. They want to know if you grasp why story points exist: to move teams away from the false precision and individual pressure of time-based estimates (hours/days) and towards a collaborative, relative sizing model that improves long-term predictability. It tests your ability to articulate the benefits of abstracting effort.

A GOOD ANSWER COVERS: A good answer covers four key points. First, define story points as an abstract, unitless measure of the total effort required for a user story, encompassing complexity, the amount of work, and risk or uncertainty. Second, explain that they are a relative measure, meaning a 2-point story is roughly twice the effort of a 1-point story. Third, detail the benefits: they force team-wide conversation to reach a shared understanding (unlike solo hour estimates), they account for non-coding activities (testing, meetings, deployment), and they lead to a more stable team velocity over sprints, which improves long-term forecasting. Finally, contrast this with time-based estimates, which are often inaccurate, vary wildly between developers, and can be used as a performance management weapon.

COMMON WRONG ANSWERS: The biggest red flag is creating a direct conversion between story points and time (e.g., "1 point equals 4 hours" or "an 8-point story is a week of work"). This completely misses the point of abstracting away from time. Another mistake is describing them only as a measure of "complexity" without including the concepts of effort and uncertainty. A weak answer also fails to explain why they are better for forecasting and team alignment than just using hours.

LIKELY FOLLOW-UPS: "How would you introduce story points to a team that has only ever estimated in hours?" "What do you do when a product manager asks you to convert the team's velocity into a delivery date?" "What happens if the team's velocity is highly unstable sprint over sprint?" "Describe the process of a planning poker session."

ONE CONCRETE EXAMPLE: Imagine a team has two stories. Story A is a simple UI text change. Story B involves a complex database migration with unknown risks. The team might agree Story A is a "1" because it's well-understood and low effort. They might estimate Story B as an "8" not because it will take 8 times longer, but because it has high complexity and significant uncertainty that needs to be accounted for. If they used hours, a junior engineer might estimate Story B at 40 hours while a senior estimates it at 16. Story points force them to discuss the why behind the number and agree on a relative size (the "8") that captures the shared understanding of the risk and complexity, regardless of who does the work.