LEARN. PRACTICE. GROW.Empiricism, values, and improvement
Scrum organizes learning and value creation around complex problems. Empiricism uses observations to decide: transparency makes the state understandable, inspection reveals differences, and adaptation changes work in response. In a reconciliation service, compare usable capability with the goal and decide the next step. The values are commitment, focus, openness, respect, and courage. Reporting a quality failure requires openness and courage; listening to its discoverer demonstrates respect. Incremental construction and iterative review can bring feedback earlier, limit investment in a wrong hypothesis, and expose integration problems sooner. Removing the review loses contact with outcomes; removing the retrospective removes a regular opportunity to improve collaboration. Connect these choices with customer collaboration, responding to change, human interaction, and working software in the Agile Manifesto.
The team and its decisions
The Product Owner directs value and the Product Backlog; Developers plan and perform work to create a usable increment; the Scrum Master helps establish Scrum and improve team effectiveness. At the start of an integration, the PO explains the business need, Developers assess a feasible slice, and the Scrum Master helps expose dependencies. A cross-functional team collectively has the necessary skills without requiring every person to master everything. Self-management means internally deciding who does what, when, and how. It can reduce waits for external task assignment, bring decisions closer to those who understand the work, and increase learning across specialties. Security constraints and external authorities remain: the team must clarify how to work with them.
Cadence and duration choices
A Sprint has a fixed duration of one month or less, and the next starts immediately afterward. Work during that interval should advance the goal and create usable value. Choose duration with feedback speed, uncertainty, and the ability to finish a useful slice in mind. A six-week external dependency does not authorize a six-week Sprint; address the dependency and seek a slice that fits the cadence. A timebox limits discussion cost, encourages preparation and focus, and establishes a predictable inspection point. It does not justify pretending a decision has been made when essential information is missing. Record the missing information, owner, and next step without automatically extending the event or lowering quality.
Events: purpose, participants, and limits
Sprint Planning starts the Sprint: the whole Scrum Team collaborates on why, what to select, and the delivery plan. Others may be invited to advise. Its maximum is eight hours for a one-month Sprint. The Daily Scrum is a 15-minute event for Developers each working day, inspecting progress toward the Sprint Goal and adapting the plan; the PO and Scrum Master participate as Developers if actively working on Sprint Backlog items. The Sprint Review brings the Scrum Team and relevant stakeholders together near the end to inspect outcomes and environmental changes and decide future adaptations; its maximum is four hours for a one-month Sprint. The Sprint Retrospective ends the Sprint: the Scrum Team seeks better quality and effectiveness, within three hours for a one-month Sprint. Planning, Review, and Retrospective are usually shorter for shorter Sprints; no mandatory mathematical division follows. Refinement is ongoing work, not another formal event.
Artifacts and observable commitments
The Product Backlog is an ordered, emergent, transparent list of work needed to improve the product; its Product Goal directs the intended evolution. The Sprint Backlog contains the Sprint Goal, selected items, and plan: it is visible, updated during the Sprint, and managed by Developers. The Sprint Goal maintains coherence as work details change. An Increment is usable, adds to previous increments, and is verified to work with them; the Definition of Done establishes the quality reference. In a batch service, the task board is not the increment, and an hours report does not demonstrate usable value. Ask the team to show the completed flow and quality evidence. The three commitments support inspection; they are not three manager-approval documents.
Refinement and plan adaptation
Refinement can split an item, clarify its description, and discuss size and order. A useful description explains the need; order indicates its position among choices; size helps Developers assess capacity. Spending time on refinement reduces ambiguity before selection and exposes dependencies before they become urgent. It does not require complete specifications for the entire future. If an API behaves differently than expected, Developers update the Sprint Backlog and collaborate with the PO to renegotiate scope while preserving the Sprint Goal. The goal does not change merely to accommodate new tasks: it maintains shared purpose. If it becomes obsolete, the PO may cancel the Sprint. New observations can also change Product Backlog ordering; emergent does not mean disorganized.
Quality that evolves without hiding work
A Sprint may produce multiple increments. A capability meeting the Definition of Done can be delivered before the Review, subject to applicable operational conditions; the Review is not a mandatory release approval. The Definition of Done can evolve with learning and organizational requirements. Making a recovery test mandatory requires planning how to satisfy it and exposing outstanding work; it does not permit lowering quality during the Sprint or silently reclassifying failures as Done. Teams on the same product need a common Definition of Done to interpret completion consistently and verify integration of their results. At handover, use consistent evidence for builders and support staff. Adapted teaching and original examples based on the November 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland, available under CC BY-SA 4.0. https://creativecommons.org/licenses/by-sa/4.0/
An integration failure calls for plan adaptation and visible outstanding work while retaining the goal and quality criteria.
Common pitfalls
Treating the Review as release approval; changing the goal to fit more work; confusing a one-month maximum with a fixed four weeks.
Related topics: Transparency, quality, and accountabilities · Events that lead to adaptation
Keep purpose, usable state, and adaptation decisions visible; choose techniques that respect the framework.
Reference: The Scrum Guide · CSM learning objectives January 2022 (formatted February 2024), current linked syllabus; Scrum Guide November 2020; no numbered exam revision published