Estimation & Decomposition
How an analyst estimates delivery — hours vs story points, timeline estimation, planning poker and relative sizing, estimation under uncertainty, and POC vs MVP vs prototype.
6 questions
SeniorDesignVery commonA sponsor stops you in the hallway: 'Roughly how long will the new loyalty module take?' No requirements exist yet — you have a one-line idea, no agreed scope, and no team-capacity data, but the sponsor wants a number for a board deck next week. As the analyst, explain what you tell them now, what you refuse to commit to, and how you will produce a defensible estimate. Address the cone of uncertainty, giving a range versus a single date, and the work that must happen before any commitment.
A sponsor stops you in the hallway: 'Roughly how long will the new loyalty module take?' No requirements exist yet — you have a one-line idea, no agreed scope, and no team-capacity data, but the sponsor wants a number for a board deck next week. As the analyst, explain what you tell them now, what you refuse to commit to, and how you will produce a defensible estimate. Address the cone of uncertainty, giving a range versus a single date, and the work that must happen before any commitment.
Give a rough order-of-magnitude range, never a single date, and label it an early guess. The cone of uncertainty is widest now — an estimate can be off several-fold — so commit only to discovery: eliciting and decomposing scope. Promise a firmer number afterwards.
Common mistakes
- ✗Blurting a single date that hardens into a commitment you cannot meet
- ✗Refusing any answer instead of giving a labelled rough range
- ✗Quoting early estimates as firm, ignoring the cone of uncertainty
Follow-up questions
- →How would you communicate the range so it is not heard as a promise?
- →What discovery work most narrows the cone before you commit?
JuniorTheoryCommonHow does estimating in story points differ from estimating in hours, and what does a point measure?
How does estimating in story points differ from estimating in hours, and what does a point measure?
Hours estimate absolute effort — how long work takes one person. Story points estimate relative size — how big an item is versus others, combining complexity, effort and uncertainty. Points are unitless and stay stable whoever works; velocity gives a forecast.
Common mistakes
- ✗Treating a story point as a fixed synonym for a set number of hours
- ✗Thinking points measure business value rather than relative size
- ✗Forecasting dates straight from points without team velocity
Follow-up questions
- →Why do points stay stable across the team while an hours figure does not?
- →How does velocity turn a point total into a delivery date?
MiddleTheoryCommonWhich estimation techniques does an analyst use in practice, and how do you choose one?
Which estimation techniques does an analyst use in practice, and how do you choose one?
Expert judgment — an experienced person estimates directly. Analogy — sizing against a similar past item. Three-point/PERT — optimistic, likely and pessimistic combined into a weighted mean. Planning poker — team consensus. Pick the technique by data and stakes.
Common mistakes
- ✗Believing every estimate must be a single exact number, never a range
- ✗Using three-point/PERT as a plain average instead of a weighted mean
- ✗Picking a technique by seniority rather than by data and stakes
Follow-up questions
- →How does three-point estimation (PERT) weight its three inputs?
- →When would you prefer analogy over planning poker, or the reverse?
MiddleTheoryCommonWhat is the difference between a PoC, a prototype and an MVP, and when do you build each?
What is the difference between a PoC, a prototype and an MVP, and when do you build each?
A proof of concept (PoC) checks whether a risky idea is technically feasible — throwaway. A prototype models look and flow to validate UX — disposable. An MVP is the smallest shippable product delivering value and market feedback. Each targets technical, design and market risk.
Common mistakes
- ✗Shipping a PoC or prototype to production instead of discarding it
- ✗Treating an MVP as a buggy half-product rather than the smallest valuable one
- ✗Building an MVP to test feasibility, which is a PoC's job
Follow-up questions
- →Why should a PoC and a prototype be treated as throwaway?
- →How do you decide the minimal scope that still makes an MVP viable?
SeniorDesignCommonYou estimated a feature at three sprints. The team is now finishing sprint five and it is still not done; the sponsor asks why and whether to keep going. During delivery the scope crept, a dependency slipped, and two stories turned out larger than sized. As the analyst, describe what you do now: how you re-forecast honestly, what you tell the sponsor, and how you decide whether to cut scope, extend, or stop. Do not just promise 'two more sprints' without evidence.
You estimated a feature at three sprints. The team is now finishing sprint five and it is still not done; the sponsor asks why and whether to keep going. During delivery the scope crept, a dependency slipped, and two stories turned out larger than sized. As the analyst, describe what you do now: how you re-forecast honestly, what you tell the sponsor, and how you decide whether to cut scope, extend, or stop. Do not just promise 'two more sprints' without evidence.
Stop defending the old number. Re-estimate the remaining work from actual velocity, not the original plan. Diagnose why it slipped — scope creep, mis-sizing, a dependency. Then give the sponsor an honest range with options: cut scope, extend on the forecast, or stop.
Common mistakes
- ✗Promising 'two more sprints' with no re-forecast from actual velocity
- ✗Blaming the team or hiding the slip instead of diagnosing causes
- ✗Re-estimating from the original plan rather than the remaining work
Follow-up questions
- →How does actual velocity give a more honest remaining forecast?
- →How would you frame the cut-scope, extend, or stop options to the sponsor?
MiddleTheoryOccasionalHow does planning poker work, and why do the team's estimates converge?
How does planning poker work, and why do the team's estimates converge?
Each estimator privately picks a card from a Fibonacci-like scale for one item, then all reveal at once. A wide spread triggers discussion where high and low explain their reasoning. The team re-votes until values cluster; convergence comes from shared information, not averaging.
Common mistakes
- ✗Averaging the votes instead of discussing and re-voting
- ✗Revealing cards in turn, letting the first number anchor everyone
- ✗Reading the card as a deadline rather than relative size
Follow-up questions
- →Why is a Fibonacci-like scale used instead of a linear one?
- →What do you do when the team cannot converge after several rounds?
