Simple Scrum

I think of Scrum as something almost impossibly simple that frequently gets over-complicated.  It is the over-complication that tends to cause so much misunderstanding, leading to poor application. The following description of Scrum is intended to capture the spirit of simplicity.

---

Scrum is a framework for improving the way people do their work, or as defined on the Scrum Alliance site “a team-based framework to develop complex systems and products”.  Scrum uses an iterative process where each iteration (aka sprint) is kept as short as sensibly possible, keeping to an even rhythm as it pulses through planning, execution and reflection.  This strict, rhythmical, time-boxing aspect of Scrum provides an uncanny ability to unearth organizational dysfunction.

Scrum specifies three roles (ScrumMaster, Product Owner and Team), requires a prioritized list of work items, a goal for every sprint, and a simple way of measuring progress.  Scrum uses timeboxed ceremonies to plan, to inspect/adapt on a daily basis, and to inspect/adapt on a sprint basis.

A clear distinction is kept between the “What” (the goal) and the “How” (the pathway). All parties maintain a continuous focus on the “Why”. Scrum requires clear focus, commitment and complete transparency at all levels; it embraces, or emphasizes certain human-centric values including (but not limited to) trust, integrity, courage and respect.

Roles
The Scrum Master is a servant leader to the team and a change agent within the wider organization.  The Product Owner is the main voice of the customer, establishing a compelling vision and using a process of continuous prioritization to get there.  The Team are a self-organized, cross-functional, empowered group who do the work, collaborating with the Product Owner as needed.

Artifacts
A backlog of requests, or goals is always maintained.  It contains all the stuff (we think) we’d like the product or service to do, at any given moment in time.  It is a living list, in a continuous state of flux yet always in a prioritized order, which will change over time.  Items in the backlog always focus on the “What”. The sprint commitment is a subset of this backlog, sometimes broken down into work-tasks, which will describe the “How” of the product. Scrum requires simple metrics, e.g. measures of work remaining, or business value delivered.  The metrics should be used to measure truth — not to measure success or failure.  Only measures of truth can be trusted not to incite quick-fix behavior in a team

Ceremonies
The Team and PO meet before the start of each sprint to plan the work. The Team commits to prioritized items of work that have “well-formed outcomes” (the goal) and are expected to deliver finished, realeasable product to meet those criteria at the end of the sprint.  How they do their work (the pathway) is solely their own concern.  Every workday the team members meet around a visual metrics board (e.g. taskboard) to align with one-another and request and offer support. At the end of each sprint the completed work is reviewed by stakeholders and consumers, and adaptations suggested. Following the review the team members reflect on their process, seeking ways to improve and making commitments to change. Every Sprint produces an improved product or service and a more effective process.

This is more or less the description of Scrum that has been there since the first Scrum book was published in 2003.  I have removed it from its software context, dropped some terms in order to keep the focus on the underlying principles and attempted to condense it to its essence.  I have neither added nor removed anything.

written, 20-09-2009
minor edits, 01-01-2010
minor edits, 16-01-2017

A complementary post is available here: Scrum Roles — an abstraction.

If you enjoyed this article, you may also like the book of essays:
The People’s Scrum: Agile Ideas for Revolutionary Transformation.