Scrum is a lightweight framework for developing value through an adaptive, iterative approach to complex work. Understand 3 connected parts: the accountabilities, the events and the artefacts that make progress inspectable. A team is not using Scrum simply because it holds a daily meeting or places tasks on a board.
The primary reference here is the November 2020 Scrum Guide, whose HTML version identifies that edition. Keep the framework distinct from a tool vendor’s workflow or an older role description. The practical question for a delivery team is whether its goals, decisions and completed work remain clear enough to inspect and adapt.
Who is accountable for what in Scrum?
The Scrum Guide defines a Scrum Team with a Product Owner, Scrum Master and Developers. These are accountabilities within the framework, not necessarily job titles that describe every person’s wider employment responsibilities. Avoid turning them into a chain of handovers in which nobody owns the usable result.
The Product Owner is accountable for maximising product value and effective Product Backlog management. Developers are accountable for creating a usable Increment each Sprint, including the relevant quality and planning responsibilities. The Scrum Master is accountable for establishing Scrum as defined in the Guide and supporting the team’s effectiveness.
| Accountability | What to make visible in a project | Misunderstanding to avoid |
|---|---|---|
| Product Owner | Product Goal, ordering decisions and understandable backlog items | Treating every stakeholder request as an equal instruction |
| Developers | Sprint plan, quality and a usable Increment | Calling partly finished work complete because coding ended |
| Scrum Master | Support for the framework and removal of impediments to effectiveness | Reducing the role to scheduling meetings |
This is a practical summary; the Guide remains the authoritative definition. A local team may use supporting specialists or organisational processes, but those arrangements should not obscure the accountabilities or change the meaning of a completed Increment.
The Agile Manifesto principles provide related background, including working software, collaboration and responding to change. They are not a substitute for Scrum’s specific definition. Agile principles can inform many approaches; Scrum is one particular framework rather than a synonym for every flexible development process.
How do the backlog, Sprint and Increment connect?
Begin with the Product Goal and an ordered Product Backlog. A backlog is not valuable merely because it contains many requests. Its items should be understandable enough to discuss their relationship to the goal and to make sensible ordering decisions as more is learned.
Sprint Planning connects the work selected for the Sprint to a Sprint Goal and a plan. Do not treat the meeting as a promise that uncertainty has disappeared. The team needs enough clarity to begin and a way to adapt its plan while preserving the purpose of the Sprint.
The Sprint Backlog is more than a static assignment list. It makes the Sprint Goal, selected work and delivery plan visible. The Daily Scrum then supports inspection of progress towards that goal and adaptation of the plan. It should not become a performance recital aimed only at satisfying a manager.
An Increment must be usable and meet the Definition of Done. That distinction prevents incomplete testing, unresolved integration work or missing quality conditions from disappearing under a “development complete” label. A demonstration can help inspect work, but appearance alone does not establish that the agreed quality conditions have been met.
What evidence should a Sprint Review examine?
The Sprint Review inspects the outcome and considers future adaptations. It is not merely a slide presentation showing that everyone was busy. Relevant stakeholders need to understand what changed, what was learned and what that means for the next product decisions.
Use this original goal-to-evidence worksheet to prepare a review:
| Review field | Evidence to bring | Question it should answer |
|---|---|---|
| Product direction | Current Product Goal and relevant context | Why was this work worth doing? |
| Sprint purpose | Sprint Goal | What outcome guided the team’s choices? |
| Usable result | Increment meeting the Definition of Done | What can actually be used now? |
| Quality boundary | Relevant completed checks | What does Done mean for this result? |
| Learning | Observations, feedback and unresolved assumptions | What changed in our understanding? |
| Adaptation | Proposed backlog changes | What should happen next and why? |
| Limitations | Work or claims not established by the evidence | What must not be represented as finished? |
The worksheet is an original project aid, not an additional official Scrum artefact. Use it to make the existing framework’s evidence legible, not to create another approval bureaucracy. A concise review can be effective when the result and decisions are clear.
Keep incomplete work identifiable. If a feature cannot meet the Definition of Done, do not conceal the gap by presenting a carefully controlled path as a completed capability. Explain what remains and let the appropriate backlog and planning decisions follow from the actual state.
How do teams avoid Scrum becoming a meeting routine?
Distinguish the Sprint Review from the Sprint Retrospective. The review concerns the product outcome and future adaptation; the retrospective concerns improving quality and effectiveness in how the team works. Combining both into a general status meeting can leave neither purpose properly served.
Make impediments concrete. “Communication needs improvement” is hard to act on. “The team cannot test an integration because access responsibility is unclear” identifies a problem that someone can address. Record the next action without pretending the impediment is resolved merely because it appeared in meeting notes.
Avoid substituting activity measures for product evidence. A high count of completed tasks does not prove that the Increment is usable or that the Product Goal is closer. Explain the result in terms stakeholders can inspect, with supporting quality evidence and an honest account of uncertainty.
Use the framework consistently enough to learn from it. If local changes remove essential accountabilities, events or artefacts, do not assume the resulting process still carries the same definition. Describe the approach honestly and evaluate whether it supports the actual delivery problem.
For the application work that a delivery process supports, see web development. To explain a software project, get started with the product goal, current state and evidence of the hardest unresolved workflow.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.