Walk me through Scrum as the Guide defines it: the accountabilities, the events, the artefacts, and what each event is for.

Short answer

Scrum defines three accountabilities (Product Owner, Scrum Master, Developers), five events inside the Sprint container, and three artefacts each carrying a commitment. Each event exists to force one specific inspect-and-adapt decision, and most workplace practices sit outside the framework entirely.

Use the Scrum Guide as the boundary of the answer. The Scrum Guide defines accountabilities, events, artefacts, commitments, and the empirical purpose behind them; it does not prescribe story points, Jira statuses, or a status-report daily. Scrum events matter because each Scrum event creates inspection and adaptation at a different level: daily plan, sprint plan, product direction, or process improvement. That is why the Scrum Guide treats Scrum events as working sessions rather than status ceremonies.

Three accountabilities, not roles

Since the 2020 revision the Guide calls them accountabilities, and the change of word is substantive: they describe what someone is answerable for, not a job title. One Scrum Team holds all three, is typically ten people or fewer, and has no sub-teams or internal hierarchy — the separate "Development Team" that earlier versions described inside the Scrum Team was deliberately removed.

The Product Owner is accountable for maximising the product's value and for Product Backlog management: what is on it, how items are expressed, and above all the order. The Guide is explicit that this is one person rather than a committee, and that others may influence the ordering only through them. It carries the most weight in practice, and a team whose Product Owner will not order the backlog is not suffering a facilitation problem.

The Developers are everyone committed to creating a usable Increment each Sprint, regardless of specialism — testers, designers and operations people are Developers in this sense. They own the Sprint plan, instilling quality by adhering to a Definition of Done, adapting the plan daily towards the Sprint Goal, and holding one another accountable as professionals.

The Scrum Master is accountable for the team's effectiveness and for establishing Scrum as the Guide describes it. Note that the accountability is effectiveness, not activity: it covers coaching and causing impediments to be removed, and it does not include assigning work, appraising people, or reporting on individuals.

Five events, each with one job

The Sprint is itself an event and contains the other four. It is one month or less and a new one starts immediately after the previous ends, with no gap. Its purpose is bounded risk: whatever else goes wrong, you lose at most one Sprint.

Event	Timebox (one-month Sprint)	The decision it forces
Sprint Planning	8 hours	Why this Sprint matters (the Sprint Goal), what can be done, and how — producing the Sprint Backlog
Daily Scrum	15 minutes	Whether today's plan still gets the team to the Sprint Goal, and what to change if not
Sprint Review	4 hours	Whether the Increment and the market have moved such that the Product Backlog should change
Sprint Retrospective	3 hours	Which single change to how the team works goes into the next Sprint

Timeboxes shorten proportionally for shorter Sprints, and the numbers are maxima rather than targets. Give the purposes rather than the durations if you only have time for one; every candidate recites durations.

Two purposes are routinely misstated. The Daily Scrum belongs to the Developers and exists for them to re-plan; it is not a status report to the Scrum Master, and the three familiar questions were removed from the Guide in 2020 precisely because they had turned it into one. The Sprint Review is a working session in which stakeholders inspect real software and the backlog is adapted as a result — the Guide explicitly warns against limiting it to a presentation. A demo that changes nothing on the backlog has performed the ceremony and skipped the event.

Three artefacts, three commitments

The 2020 Guide pairs each artefact with a commitment, and the pairing is the part worth knowing. The Product Backlog commits to a Product Goal, a single objective the team is working towards. The Sprint Backlog commits to the Sprint Goal, the Sprint's one objective and the reason the Sprint Backlog is a plan rather than a task list. The Increment commits to the Definition of Done, a formal description of the quality required for work to count as complete and genuinely releasable.

Each commitment exists to make its artefact inspectable against something. A backlog with no Product Goal can be assessed for length but not coherence. A Sprint with no Sprint Goal cannot be renegotiated intelligently, because there is no criterion for which scope may be dropped — and the Guide does allow scope to be renegotiated with the Product Owner during a Sprint, just not changes that endanger the Sprint Goal. Where the organisation publishes a Definition of Done, every team must meet it as a minimum and may add to it.

Distinguishing the framework from your workplace

This is where the question discriminates, because most candidates have only ever seen one local variant. None of the following are in the Guide: story points, velocity, burndown or burnup charts, planning poker, a Definition of Ready, backlog grooming as a scheduled meeting, Sprint Zero, hardening Sprints, scrum-of-scrums, and the three daily questions. Product Backlog refinement is mentioned, but as an ongoing activity rather than a sixth event.

Saying so is not pedantry, and the strong version separates the harmless from the damaging. Story points and planning poker are conventions many teams find useful; they are simply not framework. A Definition of Ready is more dangerous, because it creates a gate that can stall an item indefinitely and reintroduces a handoff the framework removed. Hardening Sprints are a flat contradiction: if an Increment needs a Sprint of stabilisation afterwards, the Definition of Done is fictional and every previous Increment was mislabelled.

Where weak answers come apart

The recitable parts here are the accountabilities, the event list and the timeboxes, all available to anyone who read a course deck on the train. What separates a practitioner is saying what breaks when an element is missing, specifically and causally. No Sprint Goal, so scope cannot be renegotiated and the team either ships everything late or drops something arbitrary. No Definition of Done, so the Increment is not releasable, so the Review inspects a slide rather than software, so the backlog is adapted on speculation. No ordered backlog, so Planning becomes a contest about which stakeholder is loudest.

That chain is why the Guide insists the framework is irreducible: its elements cannot be omitted selectively without rendering it useless. Every event is a feedback loop, and removing one leaves the loops downstream running on stale information.

Give each element a purpose and a failure mode. The list you can look up in twenty minutes; the consequences are what interviewers are listening for.

---

© 2026 Preptima. Originally published at preptima.com.