METHODOLOGY

Scrum

An agile framework that organises work into fixed-length sprints, with defined roles, events, and artifacts to keep a team delivering and inspecting in a tight loop.

Last reviewed: 2026-06-02 byKevin Riedl wiki β†—

Scrum has three roles, three artifacts, and a handful of events. The Product Owner decides what gets built and in what order. The Scrum Master removes blockers and protects the process. The developers build it. The artifacts are the product backlog (everything that might get built), the sprint backlog (what this sprint commits to), and the increment (what actually ships). The events are sprint planning, the daily standup, the sprint review, and the retrospective.

Where Scrum genuinely helps: teams that struggle with focus and visibility. The fixed sprint forces a real commitment, the review forces a real demo, and the retro forces the team to look at its own process instead of ignoring it. For a team that has never shipped on a cadence, Scrum is a useful scaffold.

Where it becomes theatre: when the events survive but the substance dies. A standup that is a status report to the manager. A review with no working software to show. A retro that produces the same three action items every fortnight and acts on none of them. Many “Scrum” teams are running the ceremonies and getting none of the value. If you are doing the meetings but cannot demo a working increment, you do not have Scrum, you have a meeting habit.

Wavect’s honest take: Scrum is a good starting framework and a bad religion. Keep the parts that create feedback and drop the parts that create overhead. Most mature teams drift toward something lighter, often closer to Kanban, once the discipline is internalised.

// FAQ

FAQs

FAQs

An agile framework that runs work in fixed-length sprints with three roles (Product Owner, Scrum Master, developers), three artifacts (product backlog, sprint backlog, increment), and four events (planning, standup, review, retro). The goal is a tight build-and-inspect loop, not the meetings themselves.
Scrum batches work into fixed sprints with a commitment and a review at each boundary. Kanban runs a continuous flow with WIP limits and no fixed iterations. Pick Scrum when a team needs the structure of a cadence to build delivery discipline. Pick Kanban when work arrives unpredictably or the team is mature enough to manage flow without the scaffolding.
When the ceremonies run but produce nothing. A standup that became a status meeting, a review with no demo, a retro that changes nothing. If you cannot show a working increment at the end of a sprint, the framework is theatre and you should fix the substance, not add more process.