Scrum: roles, artifacts, events
◈ 7 cardsThe Scrum team (product owner, Scrum master, development team), the three artifacts, and the four time-boxed events — and exactly who is allowed to change what.
A sprint is a time-box, not a deadline
Scrum is an agile process framework: a named set of roles, artifacts and time-boxed events that a team uses to turn a prioritised list of wants into short increments of running software. Calling it a framework rather than a method is precise and worth a mark — Scrum fixes who decides what and when the team meets, and deliberately says nothing about how you write code. Work proceeds in sprints, time-boxes of typically two to four weeks. The distinction that matters: a time-box is not a deadline. The date does not move; the contents may. If the work does not fit, the work changes, not the date.
Three artifacts, and exactly who may change each
The product backlog is a prioritised list of the features and requirements that would deliver business value. It is ordered by the product owner, it is never complete while the product is still evolving, and items can be added to it at any time. The sprint backlog is the subset of product backlog items the team has pulled into the current sprint, together with the plan for delivering them. It is fixed for the duration of the sprint: no new feature enters a sprint backlog unless the sprint is cancelled and restarted. The increment is the union of every backlog item completed in this sprint and in all previous ones — the running system, not a document about it.
Confusing the two backlogs is the single commonest way to lose marks on a Scrum question, and the fix is to remember what each one is for. The product backlog is where the future lives and is allowed to churn. The sprint backlog is a promise for a fortnight, and its stability is exactly what makes the promise worth anything.
Three roles
The product owner decides what is worth building. They rank the product backlog so the items nearest the top are the ones the stakeholders most need next, and they alone decide whether to end a sprint early or extend it. The development team — small, typically three to six people, self-organising and interdisciplinary — decides how much fits in the sprint, how it will be built, and when the increment is done and ready to demonstrate. The Scrum master facilitates: they run the daily meeting, remove the obstacles the team raises, coach the team, and help the product owner keep backlog items clear and well-formed. Note the negative space. The Scrum master does not assign work and does not set priorities. Writing that they do is the fastest way to show a marker you have never run a sprint.
Four events
Sprint planning happens before each sprint: the product owner states the goal for the increment, and the team selects the items to move into the sprint backlog and determines what can actually be delivered inside the time-box. The daily Scrum is a fifteen-minute meeting at the start of each workday in which every member answers three questions — what did you do since we last met, what is obstructing you, what will you do by the next meeting. It is a synchronisation, not a problem-solving meeting; problems raised are taken offline with only the affected people. The sprint review at the end demonstrates the increment to the product owner and selected stakeholders, who accept it or do not; work that is not accepted goes back to the product backlog and may reshape the next sprint. The sprint retrospective, held before the next planning meeting, asks what went well, what could be improved, and what the team commits to improving next time. It is the only event aimed at the process rather than the product, and it is the one teams quietly drop first — which is why teams stop improving.
Worked example — BorrowBox, sprint 6
The BorrowBox product owner is the depot manager's nominated representative. She orders the product backlog and, for sprint 6, states the goal: a member should never be surprised by what happened to their reservation. The team pulls three items — extend an active loan once, report a jammed locker door, and show a member why their reservation expired — and judges that a fourth, push notifications, will not fit.
On day four, marketing asks for push notifications anyway. Because nothing may be added to a sprint backlog mid-sprint, it goes into the product backlog and is ranked for sprint 7. The sprint ships on its date. At the review the extend-a-loan feature is rejected in ninety seconds: it extends the loan but not the locker's hold, so the door refuses the member at hour three. That item returns to the product backlog. The retrospective's finding is not about the feature at all — it is that the team's definition of done did not include the locker firmware, so an increment could be called complete while the physical half of the system disagreed with it. The team changes its definition of done. That is the shape of a working Scrum: the events keep catching things earlier than a milestone review would have.