24 October, 2022

Scrum Guide: All You Want to Know about How to Deliver a Scrum Project

By Mike Clayton


Scrum is by far the most widely used Agile Methodology. And, whilst hardcore developers may have their concerns, its simplicity makes Scrum an excellent entry into Agile Project Management.

And luckily, The Scrum Guide is:

  • Authoritative – it’s written by the founders of Scrum
  • Easy to read – and available in over 30 languages
  • Short – at just 13 pages
  • Free – Download it here

So, why bother with a full article?

Great question. Partly because everyone has a different way of learning and understanding: my way of explaining Scrum may suit you better than others. And partly because a great way to understand something is to explain it to other people: and that’s what I am doing here!

Scrum Guide: All you want to know about how to deliver a scrum project

What We’ll Cover

In this article, I will explain Scrum in five chunks. But, for the practical stuff, it’s sections 2 and 3 that you should focus on:

  1. A Brief Introduction to Scrum: History and Intention
  2. Meet the Scrum Players: The Three Roles of Scrum
  3. The Scrum Process: Events, Artifacts, and Commitments
  4. The Principles that Underpin Scrum: Basis, Pillars, and Values
  5. Certification in Scrum: What are Your Options?

As you can see, I’ll keep it simple. And, if you have a copy of the Scrum Guide, you’ll see I am tackling it in a different, but complementary way.

A Brief Introduction to Scrum: History and Intention

In many parts of the world, the word ‘scrum’ immediately puts people in mind of the game of Rugby. And this is, indeed the origin of the name of this methodology. But, originally, the word scrum was used as a metaphor for how to deliver New Product Development. Its use for software development projects came later.

A New New Product Development Process

Hirotaka Takeuchi and Ikujiro Nonaka developed a new approach to Product Development, which they described in their 1986 Harvard Business Review article, ‘The New New Product Development Game’. In it, they described an approach to commercial product development that they called a rugby approach. Here, a single cross-functional team moves the process through a series of overlapping phases, passing the product back and forth through a series of iterations. In rugby, a scrum is used to restart play, as each team tries to get possession of the ball.

Takeuchi and Nonaka argued that their process would increase the speed and flexibility of product development.

The Scrum Software Development Approach

Ken Schwaber and Babatunde Ogunnaike were working at DuPont Research and the University of Delaware, researching ways to develop complex products, such as software. They concluded that high failure rates could be addressed by frequent inspection and adaptation, where requirements and progress are highly transparent to those doing the work.

In the early 1990s, both Schwaber and Jeff Sutherland, with his team, were developing this approach. Then, in 1995, they collaborated to create a paper describing their approach to software development, calling it Scrum. In 2001, they became contributors to and signatories of the Manifesto for Agile Software Development (the Agile Manifesto).

As well as contributing to the foundation of both the Scrum Alliance and Scrum.org and numerous books, Schwaber and Sutherland have collaborated continuously, since 2010, on the six versions of the Scrum Guide, The current version came out in 2020.

Purposefully Incomplete

The Scrum Guide defines the Scrum framework as ‘purposefully incomplete’. That is, it only defines the core elements we require, to implement Scrum. The rules of Scrum are intended as a guide to the kinds of relationships and interactions that will create an agile project that is both lean and empirically-based. It leaves it to practitioners to find detailed ways of working within the framework.

We will look at what Scrum means by ‘lean’ and ’empirically-based’, in the section on the principles that underpin Scrum.

Meet the Scrum Players: The Three Roles of Scrum

There are only three roles in a Scrum project. Together, they make up a Scrum Team:

  1. Development Team
  2. Product Owner
  3. Scrum Master

We will look at the part each plays.

The Scrum Team

Development Team

The Development team consists of the engineers who build the components of the final product or products. It is self-organizing and self-managing, and usually cross-functional, with all the skills and capabilities it needs.

This means there must be enough members to do all the work needed in each work period (a Sprint) but, to work effectively, the team must not be so big that communication and accountability are diluted. As a result, teams are usually of 8 or fewer (so the whole Scrum Team is 10 or fewer). If more than 8 developers are needed, the team should split into two or more teams.

The team needs to deliver value at each Sprint, so will work together to:

  • Create a plan for the sprint
  • Adapt the plan daily – at the Daily Scrums
  • Hold each other accountable
  • Estimate the size of each work unit
  • Deliver increments to the quality set out in the ‘Definition of Done’
  • Jointly inspect the increment they deliver with customers, users, and other stakeholders
  • Continuously learn from one-another to refine their working process

Product Owner

The Product Owner’s focus is on people, not tasks. And, in particular, on the needs of customers, users, and other stakeholders. Their job is to understand what these stakeholders want and need, and to turn them into specifications for specific functionality, called Stories.

They record this work requirement in a ‘Product Backlog’, which they maintain. They are responsible for the quality of the descriptions it contains and the transparency of these needs to the stakeholders and the rest of the Scrum Team. It is from the Product Backlog that the team creates value for the sponsoring organization. So, in a real sense, the Product Owner is responsible for maximizing the value that the Scrum Team delivers.

To support this responsibility, the Product Owner will:

  • Develop and communicate the product goal and specific requirements
  • Create and maintain the Product Backlog, and bring order to its contents
  • Ensure transparency and understanding of users’ requirements
  • Represent their users, customers, and other stakeholders

Scrum Master

The Scrum master is also focused on people. But, in their case, it is on the members of the Scrum Team. They facilitate the Scrum Process, to deliver the project as efficiently and effectively as possible. This means being the source of knowledge and advice on the Scrum process, and the principal problem-solver for managerial and process challenges. They must ensure that the whole team understands and follows the Scrum Process and will manage the five ‘Scrum Events’.

In doing this, the Scrum Master will:

  • Establish and maintain the Scrum process
  • Serve the team as its coach and mentor, remover of impediments, maintainer of focus, monitor of timing, and facilitator of a positive environment and successful events
  • Serve the Product Owner in Backlog management and refinement (Backlog Grooming), planning, and stakeholder engagement

The Scrum Process: Events, Artifacts, and Commitments

In describing the Scrum Process, we need to be aware that Scrum has:

  • 3 Artifacts
    these are the three types of work the Scrum Team delivers. Each one has a Commitment…
  • 3 Commitments
    Each Artifact has a Commitment to provide specific information that will help the project remain transparent and maintain its focus on what matters most.
  • 5 Events
    These are where the team can inspect its artifacts and adapt them is needed. They create transparency, so the whole Scrum Team (and stakeholders) can have a shared understanding of status.

We will see these Events, Artifacts, and Commitments as we work our way through the Scrum Process. I shall represent it as a 5-step process. We can illustrate that process with a simplified diagram…

The Scrum Framework

In the illustration, the Events are indicated with stars, the Artifacts with the letter A, and their Commitments with the letter C.

Step 1: Product Backlog

The first Scrum Artifact is the Product Backlog.

The Product Backlog is an ordered list of work that the Development Team will carry out to either improve the product or create new components or functionality. It is the single source of requirements for the Scrum team and their stakeholders.

Creating and maintaining the Product Backlog is the responsibility of the Product Owner, who will liaise with customers, users, and other stakeholders to understand and document their requirements – often in the form of User Stories. We have a video, What are Epics, User Stories, and Story Points?

However, it is the Development Team who are responsible for estimating the size (sizing) of each piece of work – that is, how much effort it will take. They will use techniques like Planning Poker or T-shirt sizing.

The Product Backlog contains the Scrum Team’s commitment to the Product Goal, which is the final future state of the product. This is what the team must fulfill to deliver the value the organization needs. The stories within the backlog define what it will take to meet that goal.

Step 2: Sprint Planning

This is the first Scrum Event.

Sprint Planning initiates the Sprint itself – the primary event (and ‘heartbeat’) of Scrum. In Sprint planning, the team will answer questions like:

  • Why will this Sprint be valuable?
    That is, what is the Sprint Goal?
  • What can we deliver in this Sprint?
    That is, which elements of the Product Backlog?
  • How will we do the work?
    …to meet our Definition of Done.

Typically Sprint Planning events are timeboxed at around 2 hours.

The outcome will include the second Scrum Artifact, the Sprint Backlog.

The Sprint Backlog will contain:

  1. Sprint Goal
    – which answers the question ‘Why?’
  2. Backlog items selected for this Sprint
    – which answers the question ‘What?’
  3. A plan for delivery of the Sprint Backlog items
    – which answers the question ‘How?’

The Sprint Backlog is developed by and for the Scrum Team. The team’s commitment within the Sprint Backlog is the Sprint Goal

Step 3: The Sprint

This is the second Scrum Event.

That said, the term ‘Sprint’ is often also used to refer to the set of five Scrum events in one cycle.

But the Sprint itself is a fixed length (‘timeboxed’) period of work for the Development Team. Most commonly it will be two weeks. This will be long enough to make a meaningful increment but short enough to be able to inspect that increment and adapt to new observations. During the Sprint, the team will clarify the scope and refine the definitions within the backlog. They may also their plan and work process. But they would not normally change the Sprint Goal.

Within the Sprint is a cycle of Daily Scrums.

This is the third Scrum Event.

At each daily Scrum, the team will inspect their progress towards the Sprint Goal. If they need to, they will adapt their work or the Sprint Backlog, to ensure they maintain focus on the Sprint Goal. If this means adjusting the scope of their work, they will negotiate this with the Product Owner.

Typically Daily Scrum events are timeboxed at around 15 minutes and will be held at the same time, in the same place, every day of the Sprint.

We have a video: How to Hold a Daily Stand-up Meeting.

Step 4: The Sprint Review

This is the fourth Scrum Event.

At the end of the Sprint, the Development Team will have created their Increment – a substantive addition to the value of the product. Before the Scrum Team can declare the Increment to be ‘Done’, they must expose it to inspection and scrutiny by their users, customers, and other stakeholders. This is at an event called a Sprint Review. It is also sometimes referred to as a ‘Showcase’.

At the Sprint review, stakeholders inspect the team’s work to determine its fitness for purpose, against the Definition of Done. They will determine whether they need the team to make any further adaptations, in a future Sprint. The review is also a chance to:

  • Discuss progress
  • Review the Product Backlog
  • Determine the next set of priorities

Typically Sprint Review events are timeboxed at around 1 hour.

The outcome will be the third Scrum Artifact, the Increment

An Increment is a tangible contribution to the final product – and thus clear progress towards the Product Goal. The users must consider it to be usable. Each Sprint can deliver one or multiple increments and these must meet their commitment: their Definition of Done.

The Definition of Done is a checklist of criteria that the increment must meet, to satisfy the users’ requirements and therefore for them to consider it usable.

Step 5: Sprint Retrospective

This is the fifth Scrum Event.

Once the team has delivered the Increment (or Increments), they will meet to review their work together. This event is called a Sprint Retrospective. The discussion includes the whole Scrum Team – but only the Scrum Team. They look for ways to work more effectively and efficiently in the next Sprint. Their discussion will include:

  • team dynamics
  • individual performance
  • development and management processes
  • tools and methods

The outcome should include tangible actions the team can take to make the next Sprint better than the last.

Typically Sprint Retrospective events are timeboxed at around 1 hour.

…and Repeat.

At the end of a Sprint, the team returns to the Product Backlog and starts the next cycle with another Sprint Planning Event. This continues until the Product Owner – on behalf of the customers, users, and other stakeholders – determines that the incremental value that another Sprint can deliver no longer exceeds the cost of the work.

A Full Scrum Project

The Principles that Underpin Scrum: Basis, Pillars, and Values

The Scrum Methodology is built around two bases:

  1. Lean Thinking
    This is a principle that has a strong focus on what is essential and an equal priority for eliminating waste.
  2. Empiricism
    This is a principle that what we can most confidently rely upon is the knowledge that we gain from experience and direct observation. In this sense, Scrum shares much common ground with the scientific method.

Three Empirical Pillars

Scrum has three pillars of empiricism, which we can see represented in the five Events.

  1. Transparency
    All work must be visible to the whole Scrum Team and their stakeholders. This allows anyone to inspect, understand, and critique the work…
  2. Inspection
    We must inspect all the work we do, and we must inspect it often. This allows us to detect problems, and detect them as soon as possible. And this means we can adapt accordingly…
  3. Adaptation
    If we find problems or deviate from our Sprint or Product Goals, we need to make changes. And the sooner we can do this, the better.

You should be able to see these principles in each of the five Events. As a result, in facilitating them, the Scrum Master needs to ensure that they always provoke change if there is a chance to increase the value the team can deliver.

Five Scrum Values

To support this, Scrum encourages team members to adopt and work to five values:

  1. Commitment
    …to achieve the Product Goal and the Sprint Goals, and to support each other in doing this
  2. Focus
    …on the work they need to do to meet the Sprint Goal in the most effective way
  3. Openness
    …about the work we are doing and openness to feedback and challenges that can improve our individual and team performance
  4. Respect
    …for fellow team members, their capabilities, and their ability to focus on their own portion of work
  5. Courage
    …to do what is right (rather than what is expedient) and to pursue the difficult questions and take on the tough challenges

Certification in Scrum: What are Your Options?

The two principal Scrum organizations are the Scrum Alliance and Scrum.org. Each has its own Scrum certification courses and exams.

Scrum Alliance

Scrum Alliance offers 15 certifications:

  • Scrum Master track
    Three tiers of Scrum Master certification, starting with CSM: Certified Scrum Master
  • Product Owner track
    Three tiers of Product Owner certification, starting with CSPO: Certified Scrum Product Owner
  • Developer track
    Three tiers of Developer certification, starting with CSD: Certified Scrum Developer
  • Agile Leadership track
    Three tiers of Agile Leadership certification, starting with CAL-E: Certified Agile Leadership Essentials
  • Guide level certifications
    Three tiers of coaching and training certification, starting with CTC: Certified Team Coach

The entry point for Project Managers is CSM: Certified Scrum Master. This is the qualification Alex Allen recommends in my interview with her: Introduction to Agile Scrum Project Management – with Alexis Allen | Video (see below, at the foot of the article).

Certified Scrum Master (CSM)

I recommend the GreyCampus CSM course. It is an introductory course for anyone who wants to fill the role of Scrum Master or Scrum team member. It will give you an in-depth understanding of Scrum and how to apply it to guide your team and organization.

As a Scrum Master, you help your team perform at their highest level. A Scrum Master protects their team from distractions and is an expert on Scrum values, principles, and practices. Scrum Masters must be people-oriented, with a high level of emotional intelligence, and a passion for helping their team members thrive.

With the GreyCampus course, you get:

  • Live, online, instructor-led training
  • Be ready to take the EXIN Agile Scrum Master certification
  • 5 star rating from over 5,000 students
  • Scrum Alliance Membership
  • 16 Scrum Education Units (SEUs), applicable if you hold another Scrum Alliance credential
  • 16 PMI PDUs
  • 2 attempts to take the CSM exam

Click here to learn more about the GreyCampus CSM course.

Scrum.org

Scrum.org offers 12 certifications:

  • Scrum Master track
    Three tiers of Scrum Master certification, starting with PSM I: Professional Scrum Master I
  • Product Owner track
    Three tiers of Product Owner certification, starting with PSPO I: Professional Scrum Product Owner I
  • Developer track
    One tier of Developer certification, PSD: Professional Scrum Development
  • Agile Leadership track
    Two tiers of Agile Leadership certification, starting with PAL: Professional Agile Leadership
  • Three special topic certifications
    • SPS: Scaled Professional Scrum
    • PSK: Professional Scrum with Kanban
    • PSU: Professional Scrum with User Experience

The entry point for Project Managers is PSM I: Professional Scrum Master I.

Professional Scrum Master (PSM I) and Professional Scrum Product Owner (PSPO I)

I recommend the Management Plaza PSM I and PSPO I exam preparation courses. With the mPlaza resources, you get:

  • The largest available bank of questions (285 questions)
  • Helpful explanations for each question
  • Fully compatible with the PSM I or PSPO I exam (rather than just being random questions about Scrum)
  • Fully updated for the 2021 version of the PSM I or PSPO I exam and 2020 edition of the Scrum Guide
  • An affordable exercise to minimize your chance of failing in the real exam
  • You can take as many simulated exams as you like for a year from the date of your purchase.

Click here to learn more about the mPlaza PSM I preparation.

Click here to learn more about the mPlaza PSPO I preparation.

Ethics Statement

I am an affiliate of mPlaza and GreyCampus. I have evaluated courses from both of these providers and I consider them all to be of the highest quality – provided by deep Project Management experts. 

If you buy a course or product through one of my links, they will make a standard payment to me. This will not affect the cost to you, nor your rights in any way. You are their customer and they will look after you.

What is Your Experience with Scrum?

I would love to hear your thoughts and question about Scrum. And, of course, I will always respond to any comments you make below.

Learn More

I interview Scrum Master and IT Project Manager, Alexis Allen about Scrum:

Never miss an article or video!

Get notified of every new article or video we publish, when we publish it.

Mike Clayton

About the Author...

Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Never miss an article or video!

     Get notified of every new article or video we publish, when we publish it.

    >