What is Scrum? A product owner's guide to the framework
In January 1986, the Harvard Business Review ran an article by two Japanese professors, Hirotaka Takeuchi and Ikujiro Nonaka, called “The New New Product Development Game.” It looked at how companies like Honda, Canon, and Fuji-Xerox were building new products faster than their competitors.
None of those products was software. They were cars and copiers, among other things.
What Takeuchi and Nonaka noticed was that the fastest teams didn’t hand work from one specialist group to the next, like runners passing a baton. They worked as one small, cross-functional unit that moved the whole thing forward together. They compared it to a rugby team. In rugby, a scrum is the tight huddle where both packs lock together and push for the ball.
Seven years later, Jeff Sutherland read the article and used it to run a software team at Easel Corporation. In 1995 he and Ken Schwaber presented Scrum as a framework. Six years after that, both of them were in the room at Snowbird signing the Agile Manifesto.
So the best-known framework in software was named after a sports metaphor in a business magazine article about photocopiers. That’s roughly how naming works in our industry.
Agile and Scrum are not the same thing
They get used interchangeably, but they’re different kinds of thing.
Agile is a set of values and principles, written down in the 2001 Agile Manifesto. It says what to care about: individuals and interactions, working software, customer collaboration, responding to change. It doesn’t tell you what meetings to hold.
Scrum is a specific framework that puts those values into practice. It defines who is accountable for what and which events happen when. If Agile is the operating system on your phone, Scrum is one of the apps.
Scrum isn’t the only app. Kanban works under the same values with no sprints and no required roles. How Kanban fits with Agile and Scrum compares them.
The Scrum framework
The authoritative description of Scrum is the Scrum Guide, written by Schwaber and Sutherland. The current version is from 2020. It’s short, about 13 pages, and worth reading in full. What follows uses its terms.
Three accountabilities
The 2020 guide talks about accountabilities rather than roles. The change is deliberate. An accountability says who answers for an outcome. A job title can say whatever it likes.
The Product Owner is accountable for maximizing the value of the product. That means setting the Product Goal and owning the Product Backlog: what’s in it, what order it’s in, and making sure everyone understands it. The Product Owner is one person, not a committee.
The Scrum Master is accountable for the team’s effectiveness with Scrum. They coach the team and clear impediments out of its way. They are not the team’s manager.
The Developers are the people who build each Increment. The word covers everyone doing the work, programmers or otherwise. Earlier versions of the guide called this group the Development Team. The Developers decide how to turn backlog items into a working Increment.
Three artifacts, each with a commitment
Each artifact in the 2020 guide comes with a commitment that says what it’s for.
The Product Backlog is an ordered list of what’s needed to improve the product. Its commitment is the Product Goal, the long-term target the backlog is working toward.
The Sprint Backlog is the plan for the current sprint: the Sprint Goal, the backlog items chosen for it, and a plan for delivering them. Its commitment is the Sprint Goal.
An Increment is a concrete step toward the Product Goal. Each one adds to all the Increments before it and has to be usable. Its commitment is the Definition of Done, the quality bar that decides whether work counts as finished at all.
Five events
Everything in Scrum happens inside the Sprint, a fixed-length period of one month or less. The other four events happen inside it.
- Sprint Planning starts the sprint. The team decides why the sprint is valuable, what can be done, and how.
- The Daily Scrum is a 15-minute meeting for the Developers to check progress toward the Sprint Goal and adjust the plan.
- The Sprint Review is a working session with stakeholders to inspect the Increment and decide what to do next.
- The Sprint Retrospective closes the sprint. The team looks at how it worked and picks improvements for the next one.
For how to actually run these without wearing the team out, see Agile sprints: how to run one.
The pillars and values in the Scrum Guide
Scrum is built on empiricism, the idea that you learn by doing and decide based on what you observe. The guide names three pillars that make that work. Transparency means everyone can see the real state of things. Inspection means someone is actually looking. Adaptation means that when they find a problem, something changes.
It also names five values: commitment, focus, openness, respect, and courage. Courage is the one people skip. It’s the one a product owner needs most, usually when saying no to a stakeholder.
The “principles of Scrum” you’ll see elsewhere
An earlier version of this post listed “the five principles of Scrum.” There are six, and they’re not in the Scrum Guide. We regret the rounding.
The list comes from the SBOK Guide published by SCRUMstudy, a separate certification body. It’s still a useful way to think about Scrum, so here it is, correctly counted:
- Empirical process control. Decisions come from what the team observes, not from the original plan. If the last two sprints showed the estimate was wrong, the next plan changes.
- Self-organization. The team decides who does what and how. People given ownership of the how tend to care more about the result.
- Collaboration. The Product Owner, Scrum Master, Developers, and stakeholders work together throughout, not in handoffs.
- Value-based prioritization. The most valuable work goes first. For a product owner that includes work other features depend on, which may not look valuable on its own.
- Time-boxing. Every event has a fixed maximum length. The sprint’s time-box forces decisions and gives a regular rhythm for feedback.
- Iterative development. The product is built in repeated cycles, each one informed by what the last one taught you.
What Scrum asks of a product owner
Most of what makes Scrum work or fail for a product owner comes down to the backlog.
The Scrum Guide says the Product Backlog is ordered, not prioritized. The difference sounds pedantic until you try it. A prioritized backlog can have twelve things marked “P1.” An ordered one can’t. Something has to be first, something has to be thirteenth, and you’re the person who decides which.
That’s also where Scrum pays you back. Because the team delivers a usable Increment every sprint, you see real progress on a fixed rhythm instead of a percentage in a status report. You can change direction at the next Sprint Planning without throwing away months of work. And because every sprint ends with something stakeholders can react to, you find out you’re wrong earlier, when it’s still cheap.
The trade is that you have to be available. The Developers will have questions every day, and the Sprint Review only works if you’re willing to reorder the backlog based on what you heard.
An ordered backlog you can see the shape of
A backlog is a list, and lists hide context. Story 40 and story 41 might belong to completely different parts of what the user is trying to do, and nothing in the list tells you that. We wrote about this in backlog management with user story mapping.
We plan our own work in CardBoard, on user story maps. The steps a user takes run across the top. Under each step sit the stories, ordered top to bottom. Horizontal lines cut the map into slices, one per release. The slice at the top is what’s next.
That turns “order the backlog” into something the whole team can look at together. You can see when the next slice covers every step thinly, which is usually what you want, and when it covers one step in great detail and skips the others.
If your team runs sprints in Jira or Azure DevOps, link the cards to their work items. Title and status stay in step both ways, so the map keeps up with the sprint without anyone copying anything.
The Product Goal goes at the top. The first slice goes under it. The rest is ordering, and ordering is the job.