LEARN. PRACTICE. GROW.1. Distinguish framework and local practice
A team uses three questions at the Daily Scrum, points for estimation, and a Ready checklist. These practices may help, but their presence does not prove Scrum and not all are required by the November 2020 guide. The Daily should support inspecting progress toward the Sprint Goal and adapting the plan within its timebox. Developers choose a structure that fulfills that purpose. A checklist should be inspected when it blocks learning without benefit. When comparing guide versions, avoid carrying old prescriptions forward as current rules. Record separately what the framework requires, what the organization requires, and what the team has chosen to try.
2. Classify quality and availability
For a fictional product, the Definition of Done requires integration and recovery tests. The organization also defines production change windows. If all Done conditions are met and the window is a separate availability control, the increment can be Done while still awaiting production. If recovery remains undemonstrated, experimental installation authorization does not make the item meet the Definition of Done. These situations may look similar on a calendar but have different quality evidence. Present the applicable standard, demonstrated state, and operational decision separately. Do not use administrative approval to turn incomplete work into a usable increment or assume Scrum removes external controls.
3. Preserve cadence without hiding work
A two-week Sprint ends with two unfinished items. Adding days to finish the list changes the fixed duration and hides useful forecast information. Retain the planned end and clearly represent the usable increment and work that still does not meet Done. The team can learn about dependencies, item size, or capacity interrupted by incidents. The Sprint Goal helps discuss outcomes beyond a task list, but does not permit calling work complete when it fails quality. Use learning in subsequent planning and process improvement. Changing the length of future Sprints should be a conscious choice, not a retroactive extension intended to improve reporting.
4. Reduce dependencies through safe learning
Cross-functionality means that the team collectively has the skills needed to create value; it does not require everyone to master every specialty. Nevertheless, always relying on one person for certificate renewal or failure analysis can create waiting and fragility. A local experiment combines supported execution, explanation of decisions, and later validation by another person in a safe environment. Assess demonstrated capability, not attendance at training alone. Where work combines support and projects, expose interruptions affecting availability rather than treating historical velocity as a fixed promise. Reducing dependency requires learning and organization; changing work’s point labels creates neither skills nor time.
5. Inspect the product with its users
Four new features do not prove that operators can find the first batch failure faster. At the Review, use a usage case to observe the actual diagnostic workflow. Ask where information is lost, what the user expected, and which outcome remains unachieved. Insufficient training is one possible hypothesis, alongside an unsuitable interface or incomplete data; do not choose the cause before observing. The Product Owner uses this learning in product and backlog management. The Scrum Master can remove barriers to direct contact between users and Developers while keeping relevant decisions transparent. Collaboration need not wait for the next event when a question prevents current work.
6. Design an improvement that can be evaluated
The team decides to try earlier dependency review for two Sprints. Define the initial condition, the change, and the signal to observe. For example, record environment-approval waiting time, request count, and changes in complexity. If total waiting falls from 18 to 6 hours but the request count also changes, the difference alone does not demonstrate causal effectiveness. Inspect cases and look for unwanted effects, such as work transferred to another team. The guide allows improvements to be included in the Sprint Backlog; it does not impose the older rule of a mandatory item every Sprint. Experiment results should guide the next adaptation without turning a local metric into a universal rule.
Fictional example: item A meets Done and awaits a production window; item B has experimental authorization but lacks a required rehearsal. A is Done; B is not yet Done. Authorization and quality are presented separately.
Common pitfalls
Treating Ready or points as framework obligations, confusing installation with Done, extending a Sprint to hide work, and using feature counts as proof of value.
Related topics: Integrated quality and release decisions · Forecasting, capacity, and daily adaptation
Keep purpose, quality, forecast, and authorization distinct. Inspect local practices using evidence and use feedback to improve the product and collective capability.
Reference: The Scrum Guide · PSM I; Scrum Guide November 2020; no public numbered exam revision