A forecast is a decision aid with assumptions
A forecast expresses what may be possible given evidence and assumptions. It is not made certain by putting a date on a slide. In Sprint Planning, Developers can consider their past performance, upcoming capacity and the Definition of Done when forecasting what they can accomplish. A team-specific technique such as counting completed items can help a conversation, but Scrum does not prescribe one universal metric or estimation formula. Before comparing numbers, ask whether the underlying work and conditions are comparable. A smaller item count can mean a smaller scope, a larger item size, an unavailable person or another change; the number alone does not identify a cause.
Refinement improves the work being considered
Product Backlog refinement is an ongoing activity that breaks down and further defines items. It can add detail such as description, order and size. The purpose is to improve understanding sufficiently for useful decisions, not to create a second approval bureaucracy. An item that can be Done within one Sprint can become ready for selection. A team may choose a checklist as a local aid, but it should not call an external sign-off board a mandatory Scrum rule. If the item is still too large or unclear, a productive response is to investigate and decompose it rather than attach a ceremonial ready label.
Collaboration does not erase accountabilities
The Developers who will do the work are responsible for sizing. The Product Owner can help by explaining needs and trade-offs and remains accountable for effective Product Backlog management, including ordering. These responsibilities work together: useful sizing depends on understanding, and ordering benefits from information about risks and dependencies. Delegating research or facilitation does not transfer the Product Owner accountability to a committee. Likewise, stakeholder importance does not make a stakeholder the person assigning tasks to Developers. Make the decision being discussed explicit so that an invitation to collaborate is not misread as a transfer of accountability.
Worked example: a changed condition changes the conversation
A fictional team completed between five and seven similarly sized items in each of four recent Sprints. Two Developers will be unavailable next Sprint. A customer wants a guaranteed date for twelve remaining items. State the observed range, the changed capacity and the remaining uncertainty before discussing a revised forecast. The evidence is insufficient to derive an exact new date merely by dividing twelve by the old average. Investigate item readiness, dependencies and the available team capacity. This is an original application of empiricism; it does not claim that Scrum mandates item-count forecasting or that availability should be converted through a fixed formula.
Keep the Product Goal visible during refinement
An emergent backlog changes as the product and its environment become better understood. Refinement should help improve the product toward its Product Goal, rather than make every possible future request equally detailed. Ordering can consider value, risk, dependencies and what needs to be learned. Scrum supplies no universal percentage formula for these trade-offs. If the Product Goal itself is no longer valuable, make that issue visible instead of polishing items for a direction nobody supports. A team must fulfill or abandon one Product Goal before taking on the next; quiet accumulation of competing goals does not create focus.
Transfer check: distinguish evidence from a promise
A stakeholder requests a date supported by a neighboring team velocity chart, while the actual Developers have different work and upcoming capacity. Explain why that comparison does not establish a reliable commitment. Then describe one refinement action that would improve the current team understanding of a large item without introducing an invented mandatory Scrum event. In your answer, name who sizes, who remains accountable for ordering, which observation informs the forecast, and which uncertainty remains. Apply these distinctions in the practice cases before reading the feedback.
A Scrum Team has completed between five and seven similarly sized backlog items in each of its last four Sprints. Two Developers will be unavailable during the next Sprint. A stakeholder asks for a guaranteed date for twelve remaining items. What is the most defensible next conversation?
- Past performance can inform a forecast when the work and operating conditions are relevant, but the changed capacity is material information. Discuss that evidence, the remaining work and uncertainty instead of presenting a historical average as a guarantee. Scrum does not prescribe this item-count forecasting technique or a universal formula. This fictional conversation applies empiricism and the Planning guidance about considering past performance, upcoming capacity and the Definition of Done; it does not infer an exact revised date from insufficient data.
Compare the other answer choices
An average is not a guarantee, and applying it without accounting for the stated capacity change hides relevant uncertainty.
Preserving an outdated expectation does not make the forecast more reliable. New evidence should be made transparent and considered.
The Scrum Master does not replace Developers self-management with assigned individual quotas; the quota also does not establish a reliable forecast.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
The Scrum Guide — November 2020