Scrum Explained: Roles, Events, Artefacts and Failure Modes

Scrum is a framework for delivering in fixed-length iterations with three roles, five events and three artefacts. It is deliberately small — it tells you almost nothing about how to build software, and everything about how to inspect and adapt at a regular cadence.

Its popularity is also its problem. Because the mechanics are easy to adopt, a great many organisations run all of them while the underlying idea — a team that decides its own commitment and adjusts based on evidence — never arrives.

The three roles#

Product Owner. Decides what is built next and in what order, and is accountable for the value delivered. The role fails in one particular way: a product owner who must escalate every decision turns the team's cycle time into their approval time.

Scrum Master. Responsible for the process working and for removing impediments. Done well, most of the job is outside the team — chasing the environment that is unavailable, the dependency team that is unresponsive, the approval step nobody can explain. Done badly, it becomes meeting administration.

Developers. Everyone who builds the increment. They decide how the work is done and how much they take on. If either of those decisions is made for them, the framework is not operating.

The five events#

Sprint. A fixed period, typically one to four weeks. Fixed is the important word: moving the end date to fit the work destroys the feedback the cadence exists to produce.

Sprint Planning. What can be delivered and how. The output is a goal and a plan, not a list of tickets sized to fill capacity exactly.

Daily Scrum. Fifteen minutes for the developers to coordinate toward the sprint goal. It is not a status report to a manager — that is the single most common corruption, and it turns a planning event into a defensive one.

Sprint Review. Show working software to stakeholders and get real feedback. Not a demo of slides, and not an approval gate.

Sprint Retrospective. How the team works, and what to change. Its value is entirely in whether anything changes as a result.

The three artefacts#

Product Backlog. Ordered, with the top items ready to work on. An unordered backlog of six hundred items is a graveyard, not a plan.

Sprint Backlog. What the team has taken on and how it intends to approach it.

Increment. Something that actually works, meeting an explicit definition of done. Where "done" means "developed but not tested", the sprint is producing a claim rather than an increment, and the untested remainder accumulates until it becomes a phase nobody planned.

The failure patterns#

Standup as status report. A manager attends, each person reports to them, the team stops coordinating and starts justifying. The event still happens daily and has become worthless.

Commitment imposed from outside. The team is told what will be in the sprint. Estimates then become negotiation, quality becomes the flexible variable, and the framework's feedback loop is disconnected.

Velocity as a target. The moment it is a performance measure it inflates, reliably and without anybody deciding to cheat. Story points are a planning aid for one team, meaningless between teams, and actively harmful as a goal.

Retrospectives with no actions. Same three issues raised each fortnight, nothing changes, attendance becomes reluctant. A retrospective that produces one owned, dated action is worth ten that produce discussion.

A weak definition of done. The most expensive failure on this list. Testing, review, documentation and deployment deferred out of "done" build an invisible backlog that surfaces as a hardening phase, which is the thing sprints were meant to eliminate.

Sprints that are really mini-waterfalls. Analysis in week one, build in week two, testing squeezed into the last day. The calendar changed; the process did not.

No product owner authority. Priorities set by committee, decisions taking days, the team blocked mid-sprint waiting for an answer that will arrive after it ends.

Is scrum the right choice?#

Scrum suits work that can be planned in iterations toward a goal — feature development, product work, projects with a definable increment.

It suits interrupt-driven work poorly. A team handling support, incidents and unpredictable requests will fail its sprint commitment regularly through no fault of its own, and the framework will generate guilt rather than information. Kanban fits that shape far better, and moving is a sensible decision rather than an admission of failure.

Teams with mixed work often run a hybrid: a flow-based system with a planning cadence and a retrospective. That is legitimate, provided it is chosen deliberately and the retained parts are actually practised.

How to tell whether it is helping#

• Does the team finish what it starts, most sprints, without a scramble?
• Does the sprint review change the backlog? If stakeholders never redirect anything, they are being informed rather than consulted.
• Do retrospective actions get done?
• Is the increment genuinely releasable at the end of each sprint?
• Does anyone outside the team look at velocity?

The last one is diagnostic. Velocity leaving the team is nearly always the start of the numbers becoming fiction.

A realistic starting point#

Two-week sprints. A written definition of done that includes tested and deployable. A product owner who can decide without escalating. A goal for each sprint, expressed as an outcome rather than a list of tickets. One retrospective action per sprint, owned and dated, reviewed at the next.

Then leave it alone for three months before adjusting the mechanics. Most teams change the process before the process has had a chance to expose the real constraint.

FAQ#

How long should a sprint be?#

Two weeks suits most teams: long enough to finish something meaningful, short enough that being wrong is cheap. One week suits fast-changing priorities and creates real planning overhead. Four weeks weakens the feedback loop enough that many teams drift back toward phases.

What if we do not finish everything in the sprint?#

Move the unfinished work back to the backlog and re-decide its priority. Do not extend the sprint; the fixed boundary is what produces the information. Consistently finishing far less than planned is data about planning or interruptions, and it is worth the retrospective rather than the guilt.

Can one person be scrum master and product owner?#

It is a poor idea. The roles pull in opposite directions — one advocates for scope and value, the other for sustainable process — and combining them means whichever pressure is loudest that week wins. In small organisations it happens; be aware of what is being traded.

Do we need story points?#

No. Many effective teams forecast by counting stories, having found that once items are broken down to a similar size, the count predicts as well as points and provokes fewer arguments. Points are a tool, not a requirement of the framework.

How do we handle bugs and support in a sprint?#

Reserve capacity for it explicitly rather than pretending it will not happen. If unplanned work routinely exceeds the reservation, the team's work is flow-shaped and a sprint commitment is the wrong instrument.

Should the whole organisation adopt scrum?#

Scrum describes how a delivery team works. Scaling it across an organisation is a much larger change to funding, governance and dependencies, and the frameworks that claim to do so vary considerably in how well they hold up. Start by making one team genuinely effective and fixing the constraints that exposes.

Is a certification worth it?#

As an introduction to the vocabulary, sometimes. It is not evidence of capability, and an organisation full of certified people can still run every event without any of the underlying behaviour. Judge by whether the increment is releasable and whether retrospectives change anything.

Related Articles#

See Agile for the principles underneath, Kanban for the flow-based alternative, and Lessons Learned for capturing what retrospectives surface at project scale.

What else is coming for Scrum