By Nick Butler
Tags: Agile
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.
‘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.
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 based on the idea that decisions are better based on experience than guesswork. To this end, Scrum maximises opportunities for:
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 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.
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.
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”.
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.
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.
“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.
“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:
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 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.
“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:
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.
“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.
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).
“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.
“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.
“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:
For a Product Owner this is a great chance to see the progress that’s being made.
“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.
“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.
“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.
“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.
“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.
“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:
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.
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.
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.
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
Jeff Patton’s Agile development and Scrum quick reference one-pager
Lyssa Adkins – The Scrum Framework (in 10 minutes) on YouTube
