Understanding and Applying the Scrum Framework
The skeleton you must be able to reason with
Scrum is a lightweight framework for addressing complex adaptive problems while delivering value. It rests on empirical process control - transparency, inspection, adaptation - and is upheld by the Scrum Values: commitment, focus, openness, respect, courage. The Scrum Team is one self-managing, cross-functional unit of typically ten or fewer people with three accountabilities: Product Owner (value and the Product Backlog), Scrum Master (team effectiveness and the framework being enacted), and Developers (creating the Increment).
Three artifacts each carry a commitment: the Product Backlog commits to the Product Goal, the Sprint Backlog to the Sprint Goal, and the Increment to the Definition of Done. Five events provide cadence: the Sprint (a container of one month or less), Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
Traps that show up in questions
- Treating the Sprint Review as a demo or an approval gate. It is a working session to inspect the Increment and adapt the Product Backlog.
- Believing the Scrum Master assigns work or gates decisions. The Scrum Master coaches, facilitates and removes impediments.
- Thinking the Daily Scrum reports to the Product Owner. It is for Developers to inspect progress toward the Sprint Goal and replan.
- Assuming scope is frozen. Scope may be clarified and renegotiated with the Product Owner as more is learned; the Sprint Goal should not be endangered.
- Forgetting that only the Product Owner may cancel a Sprint, and only if the Sprint Goal becomes obsolete.
Rule of thumb
When a question asks who decides, map it to accountability: what and why → Product Owner; how and when → Developers; process and effectiveness → Scrum Master. Applying this rule resolves most scenario items quickly and consistently.