What is Scrum? The Product Owner primer

By Nick Butler


Two Scrum team members discuss the backlog. What is Scrum? It's structured collaboration.

What is Scrum? Scrum is an Agile framework in which self-organising, self-contained teams work collaboratively and transparently to develop working solutions in regular iterations, inspecting and adapting as they go, in order to sustainably deliver maximum value.

Make a bigger impact by mastering the Product Owner role in Scrum

We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.

Buy the Guide now

Introducing Scrum for Product Owners

‘What is Scrum?’ is the first post in a series giving a practical introduction to Scrum for Product Owners. While it’s written for Product Owners, it’ll be useful for anyone with an interest in Scrum. Stakeholders, Scrum Masters and members of Development Teams will get a Product Owner’s view of Scrum. This will help you support your Product Owner to deliver the most value.

This series follows on from our Agile Project Kick-off Kit. The Kit shows you how to start a project, this new series looks at one way to run a project once it’s underway.

Although Scrum was created by and for software developers, it can be used in any field, to create pretty much any product or service.

This is Boost’s approach. Agile is about learning and adapting as you go, and this is what we’ve found works in the ten years we’ve been delivering Agile projects. We’ll explain where and why we sometimes vary from standard Scrum practice.

This first post puts Scrum into its wider context and summarises how and why it works. Understanding what underpins Scrum will help you make the best use of the framework.

What is Scrum — the detail

Scrum is a way for teams to work together so they deliver the most value, most efficiently.

Scrum is an Agile framework. It uses a set of roles, rules and tools to deliver working solutions in regular stages or iterations, with regular check-ins to inspect and adapt the work. These look and learn loops mean decisions are made with the best available information and the product and processes can be refined and improved. Collaborative, self-contained and self-organising teams give Scrum projects a sustainable rhythm that avoids the damaging end-of-project crescendos common to many Waterfall projects.

The Product Owner within a Scrum project shares the same goal as the Scrum framework itself: maximising the value delivered.

While Scrum is easy to learn, it’s hard to master.

“It’s a pretty lightweight framework,” says Boost’s Culture Lead Gavin Coughlan. “There’s not a lot to it, but it takes a lot of rigor and discipline to really make it work.”

Scrum is a way for teams to work together so they deliver the most value, most efficiently.

What is Scrum theory?

Scrum is based on the idea that decisions are better based on experience than guesswork. To this end, Scrum maximises opportunities for:

  • transparency
  • inspection
  • adaptation

Working in iterations lets you regularly inspect what you’re doing and adapt if necessary. When you combine this with a collaborative and transparent approach you make sure the right people have the right information at the right time so they can make the right decisions.

Scrum and Agile

Scrum is just one set of tools and techniques that help you work in an Agile way. Others include Extreme Programming, Kanban, Crystal and Lean.

Agile is a philosophy or a mindset, Scrum is a framework. Agile has values and principles, Scrum has roles and rules. You are Agile, you use Scrum.

You can think of it a bit like vegetarianism. A vegetarian might have values (animals are people too) and principles (don’t eat anything that moves). That’s like Agile. But when dinner time approaches they’ll rely on a recipe book. That’s like Scrum.

A great cook doesn’t need a recipe book. So it is with Agile and Scrum. Once the Agile mindset has become ingrained in the way you work you can start to experiment.

Gavin puts it like this:

“You can think of Scrum as a set of training wheels for people who are starting to work in an Agile way. It really forces a lot of the values and principles to get embedded in how you work on a day-to-day basis.

“It’s a good idea for people starting out to do it pretty much by the book. Once you’re a little bit deeper into it, then you can start to see what’s working really well for you or what’s not.”

Interestingly, while Agile encompasses Scrum, Scrum came first.

The History of Scrum and Agile

Former Top Gun, doctor and IT boffin Jeff Sutherland and developer, product manager and consultant Ken Schwaber unveiled Scrum in 1995. (Here’s Jeff Sutherland’s story of the history Scrum.)

The name comes from the game of rugby. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka used the Scrum analogy to describe new fast and flexible approaches to development.

The nineties saw a range of these approaches appearing. In 2001, 17 software gurus met in a ski lodge in Utah. They didn’t agree on much, but they did agree on what became the Agile Manifesto.

The Agile Manifesto

We could have just linked to the Manifesto, but adopting the Agile mindset makes such a difference that we’ve included it here in full.

“You can use Scrum without being aware of the Agile values and principles but it would be a mistake,” says Gavin. “You’ll probably see some benefits, but you won’t get the massive benefits that you should get if you actually focus more on the values and principles.”

If you’re not involved in development, each time you read the word “software” replace it with “solutions”.

Agile Values

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximising the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge from self-organising teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour.

Scrum Team members collaborating. Agile values individuals and interactions over processes and tools.

The Scrum Guide

What is Scrum? Well, Scrum is what the Scrum Guide says it is. The Guide is Scrum’s evolving gospel. If what you’re doing doesn’t match what’s in the guide, it’s not Scrum. It doesn’t mean it won’t work though.

Scrum Values

“When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” – The Scrum Guide

Because Scrum is strongly collaborative, it works best when everyone has a shared set of Values guiding the way you work. You can expand on these by developing your own Team Charter.

Scrum Roles

“The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.” – The Scrum Guide

Jeff Patton sums up the aims of each role like this:

  • Product Owner: Build the right product
  • Development Team: Build the product right
  • Scrum Master: Help everyone keep the process working effectively

It took me a while to get to grips with the fact there’s two teams: the Development Team and the wider Scrum Team including the Product Owner and the Scrum Master. Both teams are self-organising and cross-functional. It’s not unusual for people to move from one role to another (in established teams with a strong Agile mindset anyway).

So as Product Owner you are an integral part of the Scrum team, not just a client writing cheques and checking Gantt charts.

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

Product Owner

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” – The Scrum Guide

As Product Owner, you’re the voice of the business and voice of the customer. You bring the product vision and strategy. You show the team ‘why’, they show you ‘how’.

The Product Owner manages the Product Backlog, the prioritised list of everything that is known to be needed in the product.

You’re available to answer questions and clarify requirements and you check the work in progress to ensure it’s getting the project closer to achieving its outcomes.

To do this you need your organisation at your back. You need the time and authority to make prompt decisions.

Development Team

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.” – The Scrum Guide

The Development Team is:

  • Self-organising: No one assigns tasks to team members and only they decide what is achievable each Sprint, and how it is achieved.
  • Cross-functional: It has all the skills needed to do the work. Ideally team members are also cross-functional. This helps stop specialists becoming bottlenecks.
  • A single unit: There are no sub-teams and even if individuals have specialities, the whole team shares accountability for all work.

Scrum Development Teams are motivated to deliver because they’re empowered to make a shared commitment to the work they’ll do.

Development Teams work best when there’s between five and nine people, all working in the same location. Otherwise communication can suffer.

They also work best when the Product Owner knows the product well, and communicates this knowledge responsively and decisively. To learn more, check out The Product Owner’s guide to working with developers.

Scrum Master

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.” – The Scrum Guide

The Guide calls the Scrum Master a servant-leader. Other frameworks call them Agile Coaches. They help the whole Scrum Team by making sure they follow the Scrum framework and are embedding the Agile values and principles in their process. Additionally, they help those outside the Scrum Team understand how they can most effectively work with the team (code for keeping their sticky beaks out of the Sprint).

They make sure everything that’s needed is in place, clear blocks to progress and help all roles work together well.

The Scrum Master is the Scrum expert so, as Product Owner, if you need help with Scrum, turn to the master.

Scrum Events

The events (sometimes called ceremonies) of Scrum are designed to maximise the benefits of face-to-face communication, maintain transparency and lock in regular opportunities to look and learn (to “inspect and adapt” in Scrum lingo).

Sprint icon.

The Sprint

“A time-box of one month or less during which a “Done”, usable, and potentially releasable product Increment is created.” – The Scrum Guide

In Scrum your work loops round in a repeating pattern of iterations called Sprints. Each Sprint is the same length and is structured in the same way, with the same events occurring each time.

Sprint planning icon.

Sprint Planning

“The work to be performed in the Sprint…This plan is created by the collaborative work of the entire Scrum Team.” – The Scrum Guide

Who: Development Team, Product Owner and Scrum Master.

Sprint Planning decides what can be delivered this Sprint and how this will be done.

The Development Team runs through items from the Product Backlog in priority order, choosing those they can commit to completing in the upcoming Sprint. Neither Product Owner nor Scrum Master can tell the team what to commit to. The Scrum Team fleshes the items out (they become the Sprint Backlog) and agree on a Sprint Goal.

At Sprint Planning the team will quiz the Product Owner if they need any clarification. Making the requirements clear is a key way Product Owners ensure the right product is built.

Daily Scrum icon.

Daily Scrum

“The Daily Scrum is a 15-minute time-boxed event for the Development Team…At it, the Development Team plans work for the next 24 hours.” – The Scrum Guide

Who: Development Team (at Boost we aim to have the Product Owner and Scrum Master there too, keeping them in the loop).

The Development Team coordinate the upcoming day’s work at the Daily Scrum (a.k.a. daily stand-up).

At Boost we structure them so the Development Team answer three “inspect and adapt” questions:

  • What did I do yesterday that helped us meet the Sprint Goal?
  • What will I do today to help us meet the Sprint Goal?
  • Do I see anything that blocks me or the team from meeting the Sprint Goal?

For a Product Owner this is a great chance to see the progress that’s being made.

Sprint review icon.

Sprint Review

“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.” – The Scrum Guide

Who: The Scrum Team and anyone else the Product Owner invites, such as stakeholders, subject matter experts or actual users.

The Sprint Review lets the Product Owner test that the product meets both business and user needs, and is a chance to build internal buy-in.

The Sprint Review starts with a demo of the working features created during the Sprint. It’s not a slideshow presentation, it’s the actual product in action. This allows for hands-on interaction and meaningful feedback.

Based on what the Product Owner learns in the Review, they’ll be able to adjust the features and priorities in the Product Backlog.

Sprint retro icon.

Sprint Retrospective

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” – The Scrum Guide

Who: Development Team, Product Owner and Scrum Master

At the end of each Sprint, the retro is a chance to take a look at what is working well and what can be improved. The Scrum Master runs the retro, making sure it stays within its timebox and comes up with actionable ways the team can work better.

Where the Sprint Review inspects the product, the retrospective inspects the process.

When the Product Owner models the Scrum Values of commitment, courage, focus, openness and respect, they help make retros as effective as possible.

Scrum Artifacts

“Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.” – The Scrum Guide

Scrum has three artifacts: The Product Backlog, the Scrum Backlog and the Increment.

Product backlog icon.

Product Backlog

“The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.” – The Scrum Guide

As Product Owner, this is your baby. You choose what goes in, order it with the highest priorities — and the most detail — at the top, update it as new information comes in, and make sure the whole team always has access to it. You do this with constant input from stakeholders, subject matter experts, customers and the Scrum Team. However, the final decisions are yours.

Sprint backlog icon.

Sprint Backlog

“The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.” – The Scrum Guide

Created at Sprint Planning, the Sprint Backlog is the team’s trackable to-do list for that Sprint. Following the planning meeting, everyone has a shared understanding of all the work involved. The plan includes enough detail that you can track progress, and more detail emerges as tasks are completed. You track progress on a board or tool that is visible to the whole Scrum Team.

At Boost we usually detail the Sprint Backlog as User Stories.

As Product Owner, you can’t assign Development Team members to particular pieces of work. They make their own choices about what they work on.

Increment icon.


“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” – The Scrum Guide

The Increment is what you get when you add the results of the Sprint to the product created by all the previous Sprints.

As with concepts like “minimum viable product” or “potentially shippable product”, the idea of a “Done” Increment is to make sure Scrum focuses on delivering working solutions. The Sprint loop needs to deliver something you can look at and learn from.

The Increment must:

  • be usable so the Product Owner can check it (even if they aren’t going to release it)
  • meet the Scrum Team’s Definition of Done
  • be a step toward the Product Vision.

The Definition of Done spells out the whole Scrum Team’s shared understanding of what it means for a story to be finished.

This case study on reducing work in progress shows the benefits of getting stories to Done.

The Scrum process at a glance

What is Scrum process diagram. Shows the roles, meetings artifacts and workflow of Scrum.
Having looked at the ‘what’ and ‘why’ of Scrum, our next posts will focus more on ‘how’. We’ll look in detail at the Product Owner role, and how you can be most effective. You’ll get practical tips to help you make the most of events and artifacts of Scrum, and how to best work with the Development Team, Scrum Master and the various stakeholders outside the Scrum.

The Product Owner Primer

  1. What is Scrum?
  2. Six signs of a successful Scrum Team
  3. Making multiple Product Owners work in Scrum: A case study
  4. Working with stakeholders in Scrum
  5. Product discovery for Scrum Product Owners
  6. User stories in Scrum
  7. The Scrum Product Owner role summarised

Make a bigger impact by mastering the Product Owner role in Scrum

We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.

Buy the Guide now

Agile training

In New Zealand and keen to get to grips with Scrum and the Agile mindset? Check out our Agile training:

Agile Professional Foundation certification, Wellington, NZ – two-day ICAgile course

Introduction to Agile methodology, Wellington, NZ – free two-hour workshop

Agile Accelerator team assessment – Agile review and action plan

What is Scrum — where to learn more

The Scrum Guide

Jeff Patton’s Agile development and Scrum quick reference one-pager

Lyssa Adkins – The Scrum Framework (in 10 minutes) on YouTube

Mike Cohn’s summary of Scrum

Scrum: A breathtakingly brief and Agile introduction

Make a bigger impact tomorrow

Talk to us today