Explain story points vs. time-based estimation.

WHAT THIS TESTS: This question tests your understanding of the core philosophy behind agile estimation. The interviewer wants to see if you grasp why abstracting effort away from time leads to better team dynamics and more realistic long-term planning. It's a check for practical experience, not just textbook definitions. They are listening for your ability to articulate the trade-offs between relative and absolute estimation.

A GOOD ANSWER COVERS: A strong answer has four parts. First, define story points as a unitless, relative measure of effort that combines three factors: complexity, volume of work, and risk or uncertainty. Second, explain that they use a non-linear scale like Fibonacci (1, 2, 3, 5, 8) to reflect that uncertainty grows exponentially with size. Third, contrast this with time-based estimates, highlighting their flaws: they vary between engineers, humans are poor at absolute estimation, and they are often misinterpreted as commitments. Finally, connect story points to their primary benefit: enabling a team to calculate a reliable average velocity (points per sprint), which is crucial for long-range forecasting.

COMMON WRONG ANSWERS: The most common red flag is mapping points directly to time, for example, "a story point is about half a day's work." This completely defeats the purpose of abstraction and is a sign of a junior or waterfall mindset. Another mistake is focusing only on complexity and ignoring the other components of effort (volume and risk). Finally, an answer that doesn't mention velocity or forecasting misses the key strategic value of using story points. Debating endlessly between a 5 and an 8 is also a sign of misunderstanding the goal, which is quick consensus, not perfect precision.

LIKELY FOLLOW-UPS: Be ready for "How does a new team start using story points?" (Answer: They pick a small, well-understood task, call it a '2', and estimate everything else relative to that). Also, "What do you do if a story is too big, like a 21 or 40?" (Answer: It must be broken down into smaller, estimable user stories). Expect questions about handling unstable velocity and its root causes.

ONE CONCRETE EXAMPLE: A team consistently completes about 30 points per two-week sprint. Their velocity is 30. The product owner has a new epic estimated at 90 points. You can confidently forecast that this epic will take approximately three sprints, or six weeks, to complete (90 points / 30 points per sprint). This is a forecast, not a guarantee, but it's far more reliable for roadmap planning than summing up individual hour-based estimates.