The Scrum Guide Explained: Roles, Events and Artifacts

Scrum is often summarised in a few words, so it helps to go back to the source. The Scrum Guide is the official definition of Scrum, written by Ken Schwaber and Jeff Sutherland and published on scrumguides.org. This article summarises the current edition, the 2020 Scrum Guide (the site presents it as a direct port of the November 2020 version), in terms that finance, operations and HR professionals can use: who does what (the roles), what happens when (the events) and what gets produced (the artifacts and commitments). Where we add practical advice, we label it as ours. If you are choosing between Scrum and other approaches first, our overview of agile project management sets the wider context.

What Scrum is

The Scrum Guide defines Scrum as a lightweight framework that helps people, teams and organisations generate value through adaptive solutions for complex problems. In outline, as the guide describes it, a Product Owner orders work for a complex problem into a Product Backlog, the Scrum Team turns a selection of that work into an Increment of value during a Sprint, and the Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

The guide says Scrum rests on empiricism, meaning knowledge comes from experience and from making decisions based on what is observed, and on lean thinking, which reduces waste. Its three pillars are transparency, inspection and adaptation. One of its sentences is worth remembering: "Inspection without adaptation is considered pointless." The guide also names five values: commitment, focus, openness, respect and courage.

The guide says the Scrum framework is purposefully incomplete and that the framework, as outlined, is immutable. It says that changing the core design or ideas of Scrum, leaving out elements, or not following its rules hides problems and limits the benefits of Scrum. That does not stop teams adding their own practices around it, but it does mean "we do Scrum" should mean the elements are actually there.

The Scrum Team and its accountabilities

The guide says Scrum defines three specific accountabilities within the Scrum Team. The team itself is a small, cross-functional, self-managing unit. The guide says it is typically ten or fewer people, with one Scrum Master, one Product Owner and Developers, and that "within a Scrum Team, there are no sub-teams or hierarchies".

• Developers are the people committed to creating any aspect of a usable Increment each Sprint. The guide makes them accountable for the Sprint Backlog, for following the Definition of Done, for adapting their plan each day toward the Sprint Goal, and for holding each other accountable. In a finance setting, "Developers" simply means whoever does the work, which might include accountants, analysts and system specialists.
• The Product Owner is accountable for maximising the value of the product and for effective Product Backlog management, including the Product Goal, clear backlog items, ordering and transparency. The guide says the Product Owner is one person, not a committee.
• The Scrum Master is accountable for establishing Scrum and for the Scrum Team's effectiveness. This includes coaching, removing impediments and keeping events positive and within their timeboxes. The guide describes Scrum Masters as true leaders who serve the Scrum Team and the larger organisation.

The five events

The guide describes the Sprint as a container for all the other events. Sprints are fixed-length events of one month or less, and a new Sprint starts immediately after the previous one ends. Only the Product Owner has the authority to cancel a Sprint. Within the Sprint there are four more events:

• Sprint Planning answers why the Sprint is valuable (the Sprint Goal), what can be done this Sprint, and how the chosen work will get done. The guide timeboxes it to a maximum of eight hours for a one-month Sprint, and says that for shorter Sprints the event is usually shorter.
• The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. Developers inspect progress toward the Sprint Goal and adjust the Sprint Backlog.
• The Sprint Review is where the Scrum Team presents the results of its work to key stakeholders. The guide gives its purpose as inspecting the outcome of the Sprint and determining future adaptations, calls it a working session that the team should avoid limiting to a presentation, and sets a maximum of four hours for a one-month Sprint.
• The Sprint Retrospective is where the team plans improvements to quality and effectiveness, and it concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint.

The guide's timeboxes for Sprint Planning, Sprint Review and the Sprint Retrospective are maximums for a one-month Sprint. A fifteen-minute Daily Scrum is a fixed length, but the longer events are limits stated for a one-month Sprint.

Artifacts and their commitments

Each of the three artifacts has a commitment that enhances transparency and focus against which progress can be measured. The guide says these commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders:

• Product Backlog and its commitment, the Product Goal. The backlog is an emergent, ordered list of what is needed to improve the product. The Product Goal describes a future state of the product that can serve as a target for the team to plan against.
• Sprint Backlog and its commitment, the Sprint Goal. It contains the Sprint Goal (why), the Product Backlog items selected for the Sprint (what) and an actionable plan for delivering the Increment (how). The Sprint Goal is the single objective for the Sprint.
• Increment and its commitment, the Definition of Done. An Increment is a concrete stepping stone toward the Product Goal, and the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The guide says work cannot be considered part of an Increment unless it meets the Definition of Done. For a team working on, say, a reporting improvement, that is a prompt to agree in advance what "done" means: tested, reviewed, documented, signed off by whoever must approve it. What counts as done is for the team and its organisation to decide.

Using Scrum outside software: our suggestions

The guide's examples and vocabulary come from product work, but the definition refers to complex problems generally. These are our suggestions for non-software teams, not statements from the guide:

• Be honest about fit. Scrum is described as suited to complex problems. Routine, repeatable work such as a fixed monthly close checklist may be better managed in other ways.
• Name the Product Owner. The guide says the Product Owner is one person, not a committee.
• Keep Sprints short enough to adapt. The guide's upper limit is one month; choose a length that lets you inspect and adjust.
• Watch for governance overlap. If your organisation has formal approval gates, agree how Sprint Reviews feed into them. Our guide to agile finance transformation projects discusses finance-specific considerations.

If you want to know where Scrum training and certification fit alongside other project management routes, our comparison of project management qualifications in Dublin is a starting point. This article does not cover certification content, fees or pass rates.

Learnsignal's offices are off Baggot Street in Dublin, and we offer in-person training from there. For current details, see our CPD pages.

Frequently asked questions

How long can a Sprint be?

The Scrum Guide says Sprints are fixed-length events of one month or less.

How many people are in a Scrum Team?

The guide says a Scrum Team is typically ten or fewer people, made up of one Scrum Master, one Product Owner and Developers.

Is the Product Owner a committee?

No. The guide states that the Product Owner is one person, not a committee.

Which edition of the guide does this article follow?

The 2020 Scrum Guide on scrumguides.org, which the site describes as a direct port of the November 2020 version. Check the site for any newer edition.

Can we change parts of Scrum to suit our team?

The guide says changing the core design or ideas of Scrum, leaving out elements, or not following its rules hides problems and limits benefits. Teams can add practices around it, but should be clear about what is Scrum and what is not.

In short: three accountabilities, five events and three artifacts with commitments, used as the guide describes them.