Agile Delivery interview questions: sprint planning and execution

Backlog refinement in Scrum is the ongoing activity of adding detail, estimates, and ordering to upcoming Product Backlog items so they are ready for Sprint Planning. The Scrum Guide treats it as a continuous activity rather than a fixed meeting, with the Developers deciding how it is carried out.

Sprint Planning in Scrum determines what work the Scrum Team can deliver in the upcoming Sprint and how that work will be accomplished. The Product Owner proposes the Sprint Goal and highest-priority backlog items, and the Developers decide how to build them.

In Scrum Sprint Planning, the Scrum Team first agrees on the Sprint Goal, then selects the Product Backlog items it can complete, and finally plans how to deliver that work. This follows the event's three topics: why the Sprint is valuable, what can be done, and how the chosen work will get done.

Backlog refinement in Scrum includes adding detail and acceptance criteria to upcoming items, estimating them, and splitting large items into smaller ones that fit a Sprint. Committing to a Sprint Goal belongs to Sprint Planning, and demonstrating the Increment belongs to the Sprint Review.

In Scrum sprint planning, story points measure relative size and complexity rather than hours, and planning poker reveals estimates simultaneously to reduce anchoring. The Developers forecast what they can deliver, not the Product Owner alone, and velocity is a planning aid rather than a manager's target for comparing teams.

Items near the top of a product backlog should be refined into smaller, more detailed pieces than items further down. Top items are expected to be pulled into an upcoming Sprint, so they need enough detail and a size that fits within one Sprint. Lower items can stay coarse until their priority rises.

I would start by replacing the two-hour open-ended meeting with a fixed 90-minute refinement session held once a week, capped at about 8% of team capacity, looking one to two sprints ahead. Before anything enters that window, every new request goes through the product owner, who ranks it against the existing list; stakeholders no longer post directly into the sprint channel. For the stale third of the backlog, I would run a one-time sweep: any item untouched for six months is either re-validated by its owner in the next refinement or archived, so the ranked list shrinks to what the team can realistically deliver.

Readiness is a checkable Definition of Ready applied when an item is pulled into a sprint, not a label on the whole backlog. An item is ready when it has written acceptance criteria, its dependencies and blockers are named with owners, it has an agreed estimate, and a single owner is assigned. Items that fail the check stay in refinement rather than entering the sprint. Oversized items are split into vertical slices, each delivering observable behavior and sized to fit within one sprint.

When an item has a technical unknown that prevents a credible estimate, the team schedules a time-boxed spike, usually one to two days, with a written output such as a chosen approach or a list of risks. The spike result then feeds the item's readiness check, so the team stops estimating through uncertainty.

Finally, I would track three measures in the sprint review: carry-over rate, which I expect to drop from about 40% toward under 15% over a few sprints; the share of committed items that met the readiness checklist at planning, which should approach 100%; and the age distribution of the backlog, which should show no untouched items older than the pruning threshold. I would review these every sprint and adjust the readiness checklist or the refinement time-box if the numbers don't move.

Refinement should not let this story into the sprint as-is, because it fails the Definition of Ready: it has no estimate and unclear acceptance criteria. The product owner and team should clarify the acceptance criteria together, and the team should try to estimate it. Since the unknown API behaviour makes estimation impossible, the team should create a time-boxed spike to investigate the integration, then re-refine the story with the findings. If the story is still too large after that, it should be split into smaller stories before it is considered for planning.

On my previous team, roughly four of every ten sprint items were carried over, and planning sessions regularly stalled because stories lacked acceptance criteria or were too large to finish in one sprint. I reviewed the last six sprints of tickets and found that most carryover came from stories that had been pulled into planning without refinement. I proposed a short definition of ready: each story needed testable acceptance criteria, a size under a set threshold, and named dependencies. I also split any story estimated above that threshold during refinement, not during planning. To get buy-in, I sat with the product owner before the first session and showed the carryover data, then agreed to trial the change for three sprints. The product owner pushed back that the criteria would slow down discovery, so we exempted spike stories and reviewed the criteria at the end of the trial. Over the next three sprints carryover fell from about 40 percent to about 15 percent, and planning time dropped by roughly a third. Looking back, I did not measure engineer effort in refinement, so I could not tell whether the saved planning time was offset by extra refinement time. Next time I would track refinement time alongside planning time from the start.

The mean-based division returns one point estimate with no confidence attached. It assumes the average rate holds every sprint and ignores the spread (SD of 12), so it cannot say how likely the release is to land by sprint 10 versus sprint 12. The technique is a Monte Carlo forecast: repeatedly resample the team's historical per-sprint throughput (drawing with replacement) and, for each simulated run, count how many sprints are needed to finish 400 points. Across thousands of runs this yields a distribution of completion dates, and the team commits to a percentile (for example, the date met in 85% of runs).