Scrum
Scrum is “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems” [1]. It works by fixing the time — a Sprint of a month or less — and letting the scope inside it settle, then inspecting the result and adapting before the next one.
It is deliberately incomplete. The Guide describes Scrum as “a container for other techniques, methodologies, and practices”: it tells you when to inspect and who is accountable, and says nothing about how to design, test or deploy.
1. The framework in one pass
After the 2020 Guide [1]. Epics and user stories are dashed because neither word appears in it.
A Scrum Team is one team with three accountabilities and no sub-teams: the Product Owner, accountable for maximising value and for the Product Backlog; the Scrum Master, accountable for the team’s effectiveness and for the framework being understood; and the Developers, accountable for a usable Increment each Sprint [1].
Inside each Sprint sit four events — Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective — and three artefacts, each of which carries a commitment that makes it checkable:
| Artefact | Commitment |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
The commitments are the part most often dropped, and the part that does the work. A backlog with no Product Goal is a list; an Increment with no Definition of Done cannot be said to be finished, only stopped.
2. What adopting it actually changes
Scrum’s cost is rarely the ceremonies. It is the commitment structure. A team moving to Scrum from a pull-when-free discipline moves to committing to a Sprint Goal and holding scope stable within the Sprint — and an environment of genuinely changing priorities is what makes that hard, not the length of the stand-up.
Example — a support team asked to adopt Scrum. A team handling interrupt-driven maintenance adopts two-week Sprints. The Sprint Goal is agreed on Monday; on Tuesday a production incident consumes two developers for three days. The Sprint Goal is now unreachable, and the team has a choice between abandoning it and pretending. Repeat that fortnightly and the commitment becomes ceremonial. Rubin’s advice for exactly this case is to use Kanban instead — “Scrum is not well suited to highly interrupt-driven work” — and to run both in one organisation where the work genuinely differs [2].
That is the question to ask before adopting Scrum: is our work predictable enough to hold a goal still for a Sprint?
3. The immutability clause, and the argument about it
The Guide is explicit that Scrum is not a menu: “The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum” [1].
Set against that, the empirical picture is that almost nobody adopts a method whole. Hybrid approaches “have become reality for nearly all companies” and are “neither planned nor designed but emerge from the evolution of different work practices” [3], and customising the agile approach is one of eleven named success factor categories in the largest review of large-scale transformations [4].
The sharpest form of the objection comes from inside the agile literature rather than from its critics: Abrahamsson and colleagues make straightforwardness — a method being easy to learn and to modify — one of four properties that make a method agile [5]. On that definition a framework forbidding modification scores badly on its own family’s terms.
This handbook does not resolve that. Both positions are citable and the disagreement is real: read choosing a framework with both in hand.
How solid is this?
- Interested party. The Guide is a normative document written by the framework’s owners and distributed by organisations that certify people in it [1]. That is provenance rather than an accusation, but it is a definition and a claim, not evidence.
- Editions differ, so say which one you mean. This page uses the 2020 Guide; the 2016 edition had a separate Development Team inside the Scrum Team and worded immutability more broadly — “Scrum’s roles, artifacts, events, and rules are immutable” [6]. Course material written before 2020 will use the older roles.
- Kuhrmann is 69 respondents, self-selected and European, surveyed in 2016. Quote its percentages as of 69 respondents; its own 19.6%/83.9% split does not sum to 100. It shows hybrids are used, not that they work better — there is no outcome data [3].
- Dikert is mostly experience reports — roughly 90% by its authors’ own count, and they state they “decided not to make quantitative interpretations” [4].
- Abrahamsson’s four criteria are proposed, not validated: there is no instrument and no scoring behind them [5].
Acknowledgments
This page adapts material from lectures by Eduardo Miranda and David Root [7] on software project management.
References
- K. Schwaber and J. Sutherland,“The Scrum Guide.” Nov. 2020. [Online]. Available: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
- K. S. Rubin,Essential Scrum: A Practical Guide to the Most Popular Agile Process. in Addison-Wesley Signature Series (Cohn). Addison-Wesley Professional, 2012. [Online]. Available: https://innolution.com/essential-scrum
- M. Kuhrmann et al.,“Hybrid Software Development Approaches in Practice: A European Perspective,” IEEE Software, vol. 36, no. 4, pp. 20–31, 2019, doi: 10.1109/MS.2018.110161245.
- K. Dikert, M. Paasivaara, and C. Lassenius,“Challenges and Success Factors for Large-Scale Agile Transformations: A Systematic Literature Review,” Journal of Systems and Software, vol. 119, pp. 87–108, 2016, doi: 10.1016/j.jss.2016.06.013.
- P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta,“Agile Software Development Methods: Review and Analysis,” VTT Technical Research Centre of Finland, VTT Publications 478, 2002.
- K. Schwaber and J. Sutherland,“The Scrum Guide.” 2016. [Online]. Available: https://scrumguides.org/
- D. Root,Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.