Lesson 2 — Scrum Roles, Events, and Artefacts¶
At a glance
- Module: 04 — Agile, Scrum & Lean Delivery
- Level: Intermediate
- Estimated time: 40 minutes
- Example project: the LMS
Learning objectives¶
By the end of this lesson you should be able to:
- Describe Scrum's three accountabilities and what each is responsible for.
- List Scrum's five events and explain the purpose of each.
- Describe the three artefacts and the commitment attached to each.
- Explain how the roles, events, and artefacts reinforce one another, and identify common failure modes when one is removed.
Prerequisites¶
Introduction¶
Scrum is the most widely used agile framework. It is deliberately small: three accountabilities, five events, and three artefacts, defined in the Scrum Guide maintained by Ken Schwaber and Jeff Sutherland.
The point of learning the details is not to memorise a ceremony list. It is to see that the parts depend on each other — remove one and the others stop working. Most failed "Scrum adoptions" are actually the removal of one part while keeping the vocabulary of the rest.
1. The three accountabilities¶
Scrum defines accountabilities rather than job titles, because one person may hold more than one in a small team.
| Accountability | Responsible for |
|---|---|
| Product Owner | Maximising product value; managing and ordering the Product Backlog |
| Scrum Master | Establishing Scrum as practised; helping the team and organisation improve |
| Developers | Creating the Increment each Sprint; self-managing the work |
Two things are commonly wrong. The Product Owner is not a committee — if three people give conflicting instructions to the team, ordering has failed. And the Scrum Master is not a project manager with a new title; the role is about the effectiveness of the process, not about assigning work.
2. The five events¶
| Event | Purpose | Time-box guide |
|---|---|---|
| Sprint | The container for all other events; a fixed period producing an Increment | One month or less |
| Sprint Planning | Decide why, what, and how for the Sprint | A few hours |
| Daily Scrum | Inspect progress toward the Sprint Goal; re-plan the day | 15 minutes |
| Sprint Review | Inspect the Increment with stakeholders and adapt the backlog | A few hours |
| Sprint Retrospective | Inspect how the team worked and choose improvements | A few hours |
The Sprint Review is a working session, not a demonstration for approval. The Retrospective is where process improvement happens; a team that skips it will repeat the same problems indefinitely.
3. The three artefacts and their commitments¶
Each artefact has a commitment — the thing that gives it purpose.
| Artefact | Commitment | What it is |
|---|---|---|
| Product Backlog | Product Goal | The ordered list of what is needed to improve the product |
| Sprint Backlog | Sprint Goal | The selected work for this Sprint, plus the plan to deliver it |
| Increment | Definition of Done | The usable step toward the Product Goal produced each Sprint |
The Definition of Done is the most quietly powerful item. It is the team's shared statement of what "finished" means, and without it "done" quietly becomes "the code compiles".
LMS (illustrative)
For the LMS, a weak Definition of Done might be "feature implemented". A useful one might be: tested against stated acceptance criteria, reviewed by one other developer, accessible to the agreed standard, and deployed to the staging environment. The difference shows up at the Sprint Review, when "done" either means usable or does not.
4. Why the parts depend on each other¶
- Without a Product Owner, the backlog has no order, so the highest-value work may be last.
- Without a Sprint Goal, the team is a task queue, and the Daily Scrum has nothing to inspect.
- Without a Definition of Done, the Increment is not usable, so the Review cannot produce feedback — and the whole feedback loop that justifies Scrum is gone.
Removing any one of these does not make Scrum lighter; it removes the mechanism that made the framework work.
Key terms¶
| Term | Meaning |
|---|---|
| Product Owner | The accountability for maximising product value and ordering the backlog |
| Scrum Master | The accountability for Scrum being understood and enacted effectively |
| Developers | Those who create the Increment each Sprint |
| Sprint | A fixed period of one month or less containing the other events |
| Product Backlog | The ordered list of what is needed to improve the product |
| Increment | The usable step toward the Product Goal produced in a Sprint |
| Definition of Done | The shared statement of what "finished" means for the Increment |
| Time-box | A maximum duration for an event |
Worked example¶
Task: plan one two-week Sprint for the illustrative LMS, showing how each artefact and event is used. Dates and estimates are invented for illustration.
Step 1 — Set the Product Goal. "By the end of the term, teaching staff can publish materials and students can submit assignments, without email." Everything in the backlog is ordered against this.
Step 2 — Hold Sprint Planning. The Product Owner brings an ordered backlog. The team chooses the top items that fit the Sprint, and writes a Sprint Goal: "Assignments can be submitted and graded end to end for one pilot course."
Step 3 — Produce the Sprint Backlog. The selected items plus the plan to deliver them: submission form, file storage, grading view, and the notification email. Items are estimated, not assigned.
Step 4 — Agree the Definition of Done. Tested against acceptance criteria, reviewed, accessible to the agreed standard, and deployed to staging. Without this step, "done" is ambiguous by the end of week two.
Step 5 — Work the Sprint. A 15-minute Daily Scrum each day inspects progress toward the Sprint Goal and re-plans the day. When the file storage turns out to need a security review, the team raises it immediately rather than at the Review.
Step 6 — Sprint Review. The pilot course instructor submits and grades an assignment in staging. Feedback changes the backlog: the ordering view is less useful than expected, and the notification email should be configurable.
Step 7 — Retrospective. The team notices the security review was discovered late, and agrees to check for review requirements during Sprint Planning. That is a specific, owned change — which is what a retrospective is for.
Common misconceptions¶
“The Scrum Master is the project manager”
A project manager assigns and coordinates work. The Scrum Master works on the system — helping the team self-manage and helping the organisation stop obstructing them.
“The Product Owner decides everything”
The Product Owner orders the work and owns the value. The team decides how the work is done. Confusing the two either removes the team's autonomy or leaves nobody accountable for value.
“Sprint Review is a demo for sign-off”
It is a working session to inspect the Increment with stakeholders and adapt the backlog. An approval meeting produces no feedback, which removes the reason for holding it.
Practical activity¶
Plan one Sprint for an example project.
- Write a Product Goal in one sentence.
- Write a Sprint Goal that serves it.
- Choose the work that fits one Sprint and order it.
- Write a Definition of Done of four to six checkable statements.
- List what you expect each of the five events to produce.
What "good" looks like: a Definition of Done you could actually check, and a Sprint Goal that would still make sense if one of the selected items were swapped.
Self-assessment¶
- Why is the Definition of Done the artefact-commitment most worth getting right?
- What breaks if the Product Owner is absent, or is a committee?
-
A team holds all five events but never produces a usable Increment. Which part of Scrum has actually failed, and why?
-
Apply it — mobile banking app. A team describes its work as Scrum. The engineering manager assigns the day's tasks at the daily meeting; the product owner is a business analyst who takes her instructions from a steering committee and has not attended a review in three months; and “done” means the code is merged to the main branch.
Hint: A strong answer ties each problem to the accountability or artefact commitment it breaks, and says what fails as a consequence.
Show answers
- Because it is the shared definition of "finished". Without it, work in progress accumulates, the Increment is not usable, and the Sprint Review cannot produce real feedback — so the feedback loop that justifies the framework disappears while the ceremonies continue.
- Ordering fails. The backlog loses its single ordering authority, so conflicting instructions reach the team, the highest-value work may not be prioritised, and nobody is accountable for value. In practice the team absorbs the conflict through informal work, which is worse.
- The Definition of Done, and with it the Increment. The events are happening but nothing usable results, so the Review cannot generate feedback and the team cannot inspect real progress. The ceremonies have been retained while the mechanism they serve has been removed.
- Three separate mechanisms are broken. Product Owner: ordering is delegated to a committee and the PO never attends the Review, so the value of the Increment is never inspected by the person accountable for it. Developers: a manager assigning the day's tasks removes self-management, which turns the Daily Scrum into a status report upward instead of a plan for the next day. Definition of Done: “merged” omits testing and acceptance, so the Increment is not releasable — the team can meet every Sprint Goal while nothing ships, which is how a “Scrum” team ends up with a release at the end anyway. Fixing the DoD alone will not help: the artefacts, events, and accountabilities reinforce each other, so the ordering decisions have to move back to the PO at the same time.
Summary¶
- Scrum defines three accountabilities: Product Owner (value), Scrum Master (effectiveness), Developers (the Increment).
- Five events structure the work; the Review inspects the product and the Retrospective inspects the process.
- Three artefacts each carry a commitment — Product Goal, Sprint Goal, and Definition of Done.
- The parts reinforce each other; removing one leaves the vocabulary intact and the mechanism gone.
Further learning¶
- Lesson 3 — Kanban and Work-in-Progress Limits.
- The Scrum Guide by Ken Schwaber and Jeff Sutherland, available at scrumguides.org — the definitive short definition, revised periodically.
- Standards & Further Reading.
Next¶
Continue to Lesson 3 — Kanban and Work-in-Progress Limits.