Scrum explained: roles, events and a usable sprint example

Scrum is a framework for developing products through short cycles of usable work, feedback and adjustment. A cycle is a Sprint, lasting a month or less. The team works towards a goal and produces a usable addition to the product, called an Increment.

Imagine a warehouse team asking for a stock-hold feature. Quality staff need to block suspect stock, and pickers need to see that it cannot be dispatched.

The developers finish a screen labelled “Hold stock”. Their tickets are closed. But a picker can still scan the held stock onto an order. The screen works; the intended outcome doesn't.

The 2020 Scrum Guide, written by its creators, is the source for the framework terms below.

Start with the product goal and the sprint goal

Our fictional team maintains a warehouse application. Its Product Goal is to help staff dispatch the right stock with fewer manual checks. The Product Backlog is the ordered list of possible work towards that goal.

For a two-week Sprint, the team agrees a narrower Sprint Goal: pickers can identify and avoid stock held for quality review.

That goal connects the screen, picking rule and stock status. It also helps the team decide what can wait. A dashboard of historical holds might be useful later, but it isn't needed to make this first workflow usable.

Scrum is one way to work within an agile approach. The agile, waterfall and hybrid comparison explains the wider delivery choice. Scrum does not remove the need to plan dependencies, costs or releases.

Scrum roles: who is accountable for what?

Accountability	Framework purpose	In this fictional team
Product Owner	Maximise product value and order the Product Backlog	Decides which warehouse need deserves attention first
Developers	Create a usable Increment and adapt their plan	Build and test the hold workflow together
Scrum Master	Help establish Scrum and improve team effectiveness	Helps resolve an access delay and improve how the team works

Scrum.org explains that Developers means the people doing the product work, not only programmers. This example includes testing and design skills in the team. The Product Owner is one person; warehouse stakeholders still contribute knowledge and feedback.

The team needs a route to Quality when a hold rule is unclear. Quality still needs to agree the rules for holding and releasing stock.

Scrum events: follow one two-week sprint

All five events appear in the map. The Sprint contains the other four; they are not five separate delivery phases.

During Planning, the team selects work it expects to complete and makes a plan. That plan changes when the team discovers that one scanner receives an old stock status.

At the next Daily Scrum, Developers inspect progress towards the goal and adjust their work. They arrange an interface check that afternoon. They do not have to wait for tomorrow's meeting to fix the problem.

At the Review, warehouse and Quality staff try the working result and discuss what should change next. Scrum.org describes the Review as a collaborative working session. A slide saying “12 tickets complete” offers little to inspect.

The Retrospective concerns how the team worked. Here, it leads to arranging test-scanner access before the next Sprint. The Review examines the product result; the Retrospective examines how the team worked.

Backlogs, increments and the Definition of Done

Scrum's three artifacts each have a commitment: Product Backlog with Product Goal, Sprint Backlog with Sprint Goal, and Increment with Definition of Done. The Sprint Backlog contains selected work and the Developers' plan for achieving the goal.

The Definition of Done sets the quality standard for the Increment. For our example, assume it includes integrated tests, permission checks, relevant user instructions and a working picking path. A hold screen alone would not meet it.

A particular item's acceptance criteria might say that stock on hold cannot be added to a dispatch. Those criteria describe the expected behaviour of that item. They do not replace the product's wider quality standard. Scrum.org distinguishes that item-level practice from Done.

The requirements traceability example shows how to retain the link from a requirement to its test evidence.

A completed sprint is not a promise of benefits

Suppose the feature meets Done and is usable. The Review can reveal that staff also need a reason code when releasing a hold. The Product Owner can then prioritise that work alongside other needs.

A usable Increment can be released before the Sprint ends. The Sprint Review is not a release gate; normal operating approvals still apply to the actual service.

The feature also needs someone to track whether suspect stock is being stopped correctly in use. Fewer picking errors would be an operating result to measure, not a benefit proved by finishing the Sprint. The benefits realisation note covers that next step.

Before the next Planning session, ask someone to walk the complete stock-hold journey. If held stock can still be dispatched, fix the gap in the workflow and its Done checks before treating the feature as complete.

Sources and example notes

• Schwaber, K. and Sutherland, J. The Scrum Guide, November 2020. Accountabilities, events, artifacts and commitments.
• Scrum.org. Developers, Definition of Done and acceptance criteria, accountabilities and quality boundaries.
• Scrum.org. What is a Sprint Review?, stakeholder inspection and adaptation.

The warehouse, team arrangements and feature are fictional.