Why the #Scrum Guide is “purposefully incomplete” (from the #Scrum Guide).
From Cambridge Dictionary:
“Purposefully: in a way that shows that you know what you want to do”
“incomplete: not having some parts, or not finished”
It’s a design choice. Not a limitation. Only the essential elements are defined (Scrum Theory, Scrum Values, Accountabilities, Events, and Artifacts), while everything else is left open to your context (e.g. tools, techniques, processes, workflows, routines, etc.).
Why?
Only the minimal structure is included to support empiricism and self-management. Here’s what Scrum defines… and what it deliberately leaves to your judgment:
- a Daily Scrum - not a Kanban board
- a Product Backlog - not a Product Roadmap
- a Scrum Master- not a Line Manager
- a Definition of Done - not a deployment pipeline
- …
That doesn't mean roadmaps, boards, line managers, or pipelines aren't valuable. They might be. But Scrum doesn't prescribe them—because your context, product, and people are different than anyone else’s.
If it’s not explicitly needed to support Scrum’s core purpose, it’s left out; on purpose.
Your context completes the framework.
Scrum gives you the scaffolding.
You get to design the house.
That’s not risky. That’s empowering.
This is where professional Scrum teams bring in their expertise and skills, such as:
- Engineering practices (e.g. TDD, CI/CD, pair programming…)
- Product techniques (Story Telling, Impact Mapping, OKRs…)
- Team agreements, conflict resolution models, planning styles, communication tools, etc.
Teams are expected to experiment and evolve their ways of working around the framework. It’s inherent to using the Scrum framework.
Take care though! When organizations try to “complete” Scrum with rigid rules, templates, and workflows, they often lose the very benefits Scrum is meant to bring:
- Learning slows down
- Decisions get delayed
- People check boxes instead of solving problems
The idea for the team isn’t to stay incomplete forever, but to complete the framework deliberately through experimentation, not prescription. To inspect and to adapt.
This is professional agility in action—and it only works because Scrum doesn’t lock you in.
Call to action:
What are you using today that isn’t in the Scrum Guide—but really helps? What might need to change based on what you've learned recently? Have you added structure that’s helping—or just extra weight?
I’d love to hear your thoughts in the comments below!
I hope you find value in these short articles and if you are looking for more clarifications, feel free to make contact.
Don't want to miss any of these blog posts? Have the “The Scrum Guide Explored” series weekly in your mailbox.
Wishing you an inspiring read and a wonderful journey.
Scrum on!
