Estimation
32 bites tagged Estimation — interview questions with model answers, and 60-second explainers.
Estimate and de-risk an ambiguous initiative
Decompose into phases that front-load learning, run spikes to retire risk, communicate estimates as ranges tied to milestones. estimating under uncertainty. giving a single precise date for work you do not yet understand.
Constructing a design system ROI formula
ROI equals (benefits minus cost) over cost; benefits from time saved, defect reduction, and faster onboarding; gather data via analytics and tickets. Whether you can frame the system as an investment.
Quantifying migration cost for a major release
Pre-release, scan codebases for affected usages and estimate engineer-hours; post-release, track actual upgrade lead time and effort. Whether you can estimate and measure migration effort.
Build an opportunity-sizing model before building
Locate the affected funnel step, estimate addressable population times a bounded conversion lift times value per user, then sanity-check against a realistic ceiling. quantifying upside before investing.
Pushing back on a costly, low-value feature
Estimate cost in engineer-weeks, size the expected value, frame it as cost-per-unit-of-value, then propose a cheap experiment to test the hypothesis first. whether you can challenge scope with evidence, not opinion.
Swap Velocity for PBI Count in Sprints
Scrum.org's Story Points Detox Plan swaps velocity for PBI count charts using existing sprint data. Teams often find item counts more stable for forecasting than story points.
What technical steps estimate effort to build a competitor's missing feature?
Tests whether you decompose unknown scope before guessing timelines. A strong answer covers: reverse-engineering the user flow, mapping integration points, sizing unknowns, and validating with a spike.
How should the team handle an oversized user story in Sprint Planning?
Split it vertically with the Product Owner, swarm the top slice, and renegotiate scope rather than overcommitting. Protecting the Sprint Goal when a story is too big. Proposing overtime or horizontal splits.
Why do teams use story points instead of hours or days?
Define against a baseline; explain they absorb uncertainty so velocity stabilizes for planning. You know points mean relative effort and complexity, not time. Equating points to hours or using them to rank individuals.
How would you estimate a cross-cutting initiative in PI Planning?
Tests decomposition of cross-cutting work into team enablers with visible dependencies. Good answer: teams estimate own slices in normalized points, map dependencies on the ART board, and reserve IP buffer.
What root causes and retrospective fixes address chronic sprint overcommitment?
Tests systemic diagnosis over blaming the team. Check capacity math, refinement quality, psychological safety, and stakeholder pressure; propose velocity-guided planning, capacity recalculation, and better refinement.
How do you handle a story that's too large for a sprint?
Tests your ability to apply agile principles pragmatically. A great answer prioritizes the Sprint Goal, collaborates with the PO to vertically slice the story into smaller valuable pieces, and then re-plans the sprint backlog.
How would you create a probabilistic forecast for 40 stories?
This tests your ability to use statistical methods for forecasting. A great answer explains how to use historical throughput in a Monte Carlo simulation to generate a probability distribution of completion dates, not a single point estimate.
How would you use a spike to de-risk a story?
Tests your use of Agile spikes for de-risking, not for building features. A good answer defines the goal, sets a strict time-box, and clarifies the deliverable is knowledge (e.g., a POC), not production code. A red flag is merging spike code into main.
Explain story points vs. time-based estimation.
This tests your grasp of Agile philosophy. A good answer defines points as relative effort (complexity, volume, risk), contrasts this with the pitfalls of time, and links it to predictable team velocity. A red flag is mapping points directly to hours.
Estimating Cross-Team Initiatives in PI Planning
This tests your ability to lead multi-team estimation. A good answer covers decomposing work, bottom-up team estimates, mapping dependencies, and synthesizing a risk-assessed plan. A red flag is a single top-down estimate that ignores team capacity.
How does a team forecast work for a Sprint?
This tests if you know the Developers own the forecast, not the PO or SM. A good answer cites past performance, current capacity, and the Product Backlog as inputs. A red flag is saying the Product Owner dictates the work.
How do you provide a probabilistic forecast for completing 25 stories?
This tests your ability to move beyond single-date estimates to probabilistic forecasting. A good answer outlines using historical cycle times in a Monte Carlo simulation to generate a range of dates with confidence levels.
How would you create a probabilistic forecast for a backlog?
This tests your grasp of probabilistic forecasting over single-date estimates. A good answer explains using historical throughput to run a Monte Carlo simulation, then presenting a range of dates with confidence levels (e.g., 50%, 85%).
How do you use a spike to de-risk a story?
This tests your ability to use agile spikes for targeted de-risking, not just vague research. A strong answer defines the specific question the spike will answer, proposes a strict time-box, and lists concrete deliverables like a decision or a better estimate.
Explain story points and why they're used over time-based estimates
Tests your grasp of relative vs. absolute estimation. Define story points as a relative measure of effort, complexity, and uncertainty. Explain they foster team consensus and provide a more stable velocity than time-based estimates.
Estimating large, cross-team initiatives in PI Planning
Tests your ability to facilitate collaborative estimation. Break the initiative into features for teams to estimate, then use an ART board to map dependencies. A red flag is providing a single, top-down number without team input.
Handling a High-Cost, Low-Value Feature Request
Tests your ability to influence product using data and lean principles, not just technical objections. Quantify cost in engineer-weeks, ask for value metrics, then propose cheaper experiments (e.g., a fake door test).
How do you fix a team that consistently overcommits?
This tests diagnosing systemic process failures. A great answer investigates root causes like stakeholder pressure, then proposes using historical velocity, tracking actual capacity, and improving backlog refinement.
Get Estimation bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.