Top 30 Estimation Interview Questions and Answers
30 multiple-choice questions on Estimation, drawn from 30 bites out of the 32 tagged Estimation on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
According to the article, under what condition is a PBI count metric likely to be more stable for forecasting than story point velocity?
Show the answer
Answer: a · When the product backlog items are already relatively uniform in size
The article explicitly warns that if PBI sizes vary wildly, a straight count may mislead more than velocity, so relative uniformity is the key condition for reliable forecasts. Running both metrics in parallel is the recommended adoption strategy, not the condition that makes the count metric itself more stable.
Question 2 of 30
During Sprint Planning, who is ultimately accountable for deciding how many Product Backlog items are selected for the Sprint Backlog?
Show the answer
Answer: c · The Developers, because they are the ones who will be doing the work.
The Developers are solely accountable for selecting the amount of work for a Sprint, as they have the best insight into their capacity and the effort required. While the Product Owner prioritizes the work ('what'), they do not dictate how much is taken on ('how much').
Read the full bite: How does a team forecast work for a Sprint?
Question 3 of 30
Which approach best describes how a Scrum team forecasts work for a Sprint?
Show the answer
Answer: b · The Developers' selection of Product Backlog items, informed by past performance, current capacity, and the Sprint Goal.
The card emphasizes that Developers make the forecast, considering the Product Backlog, past performance, current capacity, and the Sprint Goal. Distractors incorrectly suggest a top-down mandate from a Product Owner or Project Manager, or an over-reliance on a single metric like velocity.
Read the full bite: How does a team forecast work for a Sprint?
Question 4 of 30
Which sequence best describes a disciplined approach to estimating a competitor's feature you must reverse-engineer?
Show the answer
Answer: a · Reverse-engineer visible flows, identify gaps in your architecture, categorize work by risk, and produce a ranged estimate with a validation spike.
Option A matches the card's required process: reverse-engineer externally, map gaps onto your architecture, categorize risk, and validate with a spike before committing to a range. Option B is wrong because it reverses discovery order and uses a single point; Option C wrongly assumes you need competitor source code; Option D ignores integration cost by focusing only on UI.
Read the full bite: What technical steps estimate effort to build a competitor's missing feature?
Question 5 of 30
A Scrum Team blames poor estimates for missed sprint goals, treats velocity as a target, and faces stakeholder pressure for more output. What systemic intervention should the Scrum Master prioritize?
Show the answer
Answer: b · Recalculate net capacity before planning, enforce a definition of ready, and treat historical velocity as a forecasting guide rather than a goal
Recalculating true capacity, enforcing a definition of ready, and using velocity as a planning guide address the systemic root causes of overcommitment. Hours-based tasking is tempting because the team blames estimates, yet it merely adds precision without fixing refinement quality, psychological safety, or stakeholder pressure.
Read the full bite: What root causes and retrospective fixes address chronic sprint overcommitment?
Question 6 of 30
When a Scrum team consistently overcommits, which approach best addresses the underlying systemic issues?
Show the answer
Answer: a · Facilitate a retrospective to analyze historical velocity, track actual capacity, and improve backlog refinement processes.
The correct approach focuses on systemic process improvements and data-driven insights, such as analyzing historical velocity and improving refinement, rather than blaming individuals or imposing top-down mandates. Conducting individual performance reviews (Option D) is a major red flag as it incorrectly attributes a systemic issue to individual performance.
Read the full bite: How do you fix a team that consistently overcommits?
Question 7 of 30
When opportunity-sizing an idea that improves a funnel step, what bounds the maximum possible impact?
Show the answer
Answer: a · The gap between the step's current conversion rate and a perfect 100 percent for the affected segment
The ceiling is the unconverted headroom at the affected step for the addressable segment, since you cannot recover users who already convert. The whole user base, build effort, and experiment count do not set the impact ceiling.
Read the full bite: Build an opportunity-sizing model before building
Question 8 of 30
What is the main reason Planning Poker requires team members to reveal their estimates simultaneously?
Show the answer
Answer: b · To prevent any single individual's initial estimate from influencing others' independent judgment.
The card explicitly states that simultaneous reveal "prevents one person's opinion from influencing everyone else" and "forces independent thought first," directly addressing groupthink. Option D is a tempting distractor, but the process aims to discuss and understand differing estimates, not simply eliminate them, to uncover hidden complexities.
Read the full bite: Planning Poker: Avoid Groupthink in Estimates
Question 9 of 30
According to the card, what is the primary negative consequence of converting story points directly to hours in relative sizing?
Show the answer
Answer: d · It undermines the abstraction of complexity and introduces a false sense of precise time-based commitment.
The card explicitly states that converting points to hours "destroys the psychological safety and abstraction that makes relative sizing effective, turning points into just another word for hours." This defeats the purpose of relative estimation by reintroducing a misleading focus on absolute time. Option C is incorrect because velocity can still be tracked, but its meaning changes from relative effort to absolute time, which is the problem.
Read the full bite: Relative Sizing: Estimate Effort, Not Hours
Question 10 of 30
When a Product Manager proposes a feature with high estimated engineering cost and unvalidated user value, what is the most effective initial approach for a senior engineer?
Show the answer
Answer: c · Quantify the engineering effort in business terms, clarify the product hypothesis and success metrics, then propose a small, cheaper experiment to validate the core assumption.
The most effective approach is to act as a strategic partner by quantifying costs in business terms, understanding the product's value hypothesis, and proposing lean experiments to de-risk the investment. Simply blocking the request or vaguely estimating without offering a path forward demonstrates a lack of strategic thinking and collaboration.
Read the full bite: Handling a High-Cost, Low-Value Feature Request
Question 11 of 30
What is the strongest first move when you think a proposed feature costs too much for its value?
Show the answer
Answer: a · Quantify cost and expected value, then propose a cheap experiment to test the hypothesis
Senior engineers make the trade-off explicit and de-risk it with a cheap test, rather than vetoing, building silently, or escalating before there is evidence.
Read the full bite: Pushing back on a costly, low-value feature
Question 12 of 30
What most improves the accuracy of a pre-release migration cost forecast?
Show the answer
Answer: c · Scanning consumer repos for affected usages and weighting by per-change complexity
Counting real affected usages and weighting by complexity grounds the forecast in the actual codebase. Treating every change as equal-cost ignores that a behavioral change is far pricier than a prop rename.
Read the full bite: Quantifying migration cost for a major release
Question 13 of 30
What most strengthens the credibility of a design system ROI figure with finance stakeholders?
Show the answer
Answer: c · Defining explicit variables, sourcing data, and presenting a conservative range
Explicit, sourced variables and a conservative range let finance stress-test the model, which builds trust. Omitting costs or inflating savings makes the number indefensible the moment it is scrutinized.
Read the full bite: Constructing a design system ROI formula
Question 14 of 30
For realistic roadmap planning, why is "effective capacity" prioritized over "design capacity"?
Show the answer
Answer: b · It accounts for non-feature work and operational overhead, reflecting actual available time.
Effective capacity explicitly subtracts time spent on non-feature work (like meetings, bugs, on-call) from the ideal design capacity, providing a realistic measure of time available for new projects. Option A is incorrect because the card explicitly states capacity planning is not for micromanaging individual performance.
Read the full bite: Roadmap Capacity Planning: Ideal vs. Reality
Question 15 of 30
When estimating a large, cross-team initiative during PI Planning, which approach is most effective?
Show the answer
Answer: b · The initiative is broken into features, teams estimate their assigned work, and dependencies are mapped on the ART board to create a sequenced plan.
The most effective approach involves decomposing the initiative, having teams estimate their specific features, and critically, mapping dependencies on the ART board to create a sequenced forecast. Simply summing individual team estimates (Option A) is a common mistake as it ignores the impact of dependencies on the overall timeline.
Read the full bite: Estimating large, cross-team initiatives in PI Planning
Question 16 of 30
When estimating a cross-cutting initiative during PI Planning, which approach best ensures realistic commitments while preserving team ownership?
Show the answer
Answer: b · Decompose the initiative into team-owned enablers, estimate locally in normalized points, visualize dependencies on the ART board, and reserve IP iteration capacity for integration.
Decomposing the initiative into team-owned enablers with normalized estimates and visible dependencies follows the SAFe principle that the people who do the work plan the work, while reserving IP capacity buffers integration risk. Letting an architect dictate a single top-down estimate is a common anti-pattern because it strips ownership and ignores local complexity.
Read the full bite: How would you estimate a cross-cutting initiative in PI Planning?
Question 17 of 30
After individual teams have estimated their work for a cross-team initiative, what is the most critical next step to create a realistic overall plan?
Show the answer
Answer: d · Mapping dependencies between teams on a program board to visualize the critical path and identify bottlenecks.
The correct answer is mapping dependencies, as this visualizes the critical path and reveals the true timeline and risks. Simply summing points (a tempting distractor) ignores that dependent work is sequential, not parallel, leading to an unrealistic plan.
Read the full bite: Estimating Cross-Team Initiatives in PI Planning
Question 18 of 30
A team adopts story points for estimation instead of hours. What is the primary benefit they seek?
Show the answer
Answer: d · To foster team consensus on the relative size of work, considering effort, complexity, and uncertainty for better forecasting.
The primary benefit of story points is to encourage team-wide discussion and create a shared understanding of the relative effort, complexity, and uncertainty of work, leading to more stable velocity and improved long-term forecasting. Option B describes a common misconception, as story points are designed to abstract away from direct time conversions.
Read the full bite: Explain story points and why they're used over time-based estimates
Question 19 of 30
What makes story points more useful than hour estimates for long-term release forecasting?
Show the answer
Answer: a · Points are relative and let velocity stabilize, enabling capacity planning without per-task time guesses.
Story points are a relative, unitless measure that lets team velocity stabilize, enabling forecasting without false precision from per-task hour guesses. Option D is tempting but wrong because treating points as a fixed calendar-day ratio directly contradicts their purpose of absorbing uncertainty and differing individual speeds.
Read the full bite: Why do teams use story points instead of hours or days?
Question 20 of 30
What is the primary strategic benefit of using story points for estimation instead of hours?
Show the answer
Answer: a · They enable the calculation of a stable team velocity, which allows for more reliable long-range forecasting.
The core purpose of story points is to abstract effort into a relative unit, allowing a team to calculate its average velocity. This velocity is crucial for long-range forecasting. Directly mapping points to hours is a common anti-pattern that negates this benefit.
Read the full bite: Explain story points vs. time-based estimation.
Question 21 of 30
Which characteristic best defines an effective agile spike for de-risking a story?
Show the answer
Answer: b · It is a time-boxed investigation to answer a specific question and yield actionable knowledge.
An effective spike is defined by its strict time-box, its focus on answering a specific question, and its goal of yielding actionable knowledge to reduce risk for a subsequent story. Option A describes a common misconception where a spike is mistakenly used to begin feature development rather than gather knowledge.
Read the full bite: How do you use a spike to de-risk a story?
Question 22 of 30
When a team uses a spike to investigate a technically uncertain user story, what is the primary goal and expected outcome?
Show the answer
Answer: a · To gain enough knowledge to provide an accurate story point estimate, with the deliverable being a recommendation or a throwaway proof-of-concept.
The primary purpose of a spike is to reduce risk and uncertainty, enabling the team to accurately estimate the work. The deliverable is knowledge, not production code, so the most tempting distractor is incorrect because spike code should be thrown away, not merged.
Read the full bite: How would you use a spike to de-risk a story?
Question 23 of 30
To create a reliable forecast for completing 40 stories, which method best incorporates the team's historical delivery variability?
Show the answer
Answer: d · Run a Monte Carlo simulation using historical weekly throughput to generate a distribution of probable completion dates.
A Monte Carlo simulation is the correct method because it uses the full range of historical throughput data to model thousands of possible future outcomes, thus accounting for variability. Calculating a simple average provides a single-point estimate that ignores the reality of delivery variation.
Read the full bite: How would you create a probabilistic forecast for 40 stories?
Question 24 of 30
To provide a probabilistic forecast for a 40-story backlog of similarly-sized items, which approach is most effective?
Show the answer
Answer: a · Gather historical weekly throughput data, run a Monte Carlo simulation by randomly sampling from this data, and present completion dates with associated confidence levels (e.g., 50%, 85%).
The most effective approach for a probabilistic forecast involves using historical throughput data with a Monte Carlo simulation to generate a range of completion dates with associated confidence levels. Option C provides only a single, deterministic estimate, ignoring variability, while Option D uses story points which are less appropriate for similarly-sized items where throughput is a more direct measure.
Read the full bite: How would you create a probabilistic forecast for a backlog?
Question 25 of 30
How should a senior engineer respond when asked to estimate a large, ambiguous AI initiative with many unknowns?
Show the answer
Answer: d · Front-load a risk-retiring spike, give a range tied to milestones, and re-estimate as unknowns resolve
Decomposing by risk, expressing a range, and re-estimating after a spike is honest and lets stakeholders plan. A single date is false precision, refusing to estimate is unhelpful, and silent padding hides the very uncertainty leadership needs to see.
Read the full bite: Estimate and de-risk an ambiguous initiative
Question 26 of 30
A team realizes a story is too large to complete mid-sprint. What is the most effective way to handle this while upholding agile principles?
Show the answer
Answer: c · Split the story vertically into smaller, testable increments of user value and re-prioritize the sprint with the Product Owner.
Vertical slicing ensures a valuable, 'Done' increment is delivered, aligning with the Sprint Goal. Splitting horizontally by technical layers is a common anti-pattern that creates dependencies and delivers no user value until all parts are complete.
Read the full bite: How do you handle a story that's too large for a sprint?
Question 27 of 30
During Sprint Planning, the team discovers a story is too large for the Sprint. What is the most appropriate response?
Show the answer
Answer: c · Work with the Product Owner to vertically slice the story, swarm the highest-value piece, and move excess scope back to the backlog
Vertically slicing the story with the Product Owner preserves end-to-end user value and allows the team to deliver a working increment while protecting the Sprint Goal. Horizontal splitting is tempting because it parallels technical specialties, but it delays integration and demoable value until the very end, violating the principle of vertical increments.
Read the full bite: How should the team handle an oversized user story in Sprint Planning?
Question 28 of 30
For which scenario would Monte Carlo forecasting be LEAST suitable?
Show the answer
Answer: d · A newly formed team that lacks any historical data on its task throughput.
The card explicitly states that Monte Carlo forecasting is ineffective for "teams with no historical data" because the simulation has nothing to sample from. Options A, B, and D describe ideal conditions or desired outcomes for using this method.
Read the full bite: Monte Carlo Forecasting: Probabilities, Not Promises
Question 29 of 30
To provide a reliable probabilistic forecast for completing 25 stories, which method is most effective?
Show the answer
Answer: d · Conduct a Monte Carlo simulation using historical cycle times to generate a distribution of possible completion dates and report confidence levels.
The most effective method involves using historical cycle times in a Monte Carlo simulation to generate a distribution of outcomes, allowing for probabilistic forecasts with confidence levels. Options A and B rely on single-point estimates (story points or simple averages) which do not account for the inherent variability and risk, while option A is less robust than a data-driven simulation.
Read the full bite: How do you provide a probabilistic forecast for completing 25 stories?
Question 30 of 30
What is the most appropriate use of Agile velocity within a development team?
Show the answer
Answer: d · To forecast the amount of work a team can realistically commit to in upcoming sprints.
Velocity's primary purpose is to enable reliable forecasting and planning, helping teams commit to a realistic amount of work. It should not be used to compare teams, measure individual productivity, or as a target to be gamed, as these misuses undermine its value.
Read the full bite: Agile Velocity: A Forecasting Tool, Not a Target
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.