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: byKevin Riedl wiki ↗

Scrum is one implementation of agile principles, with 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, usually written as user stories), 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.

Worked example of the overhead trap: a five-person team adopts Scrum by the book and ends up with sprint planning, a daily standup, a backlog refinement session, a sprint review, and a retro every two weeks. On a team that size, that ceremony load can eat the better part of a day a week per person, and the planning precision it buys is wasted because a five-person team already knows what everyone is doing. The framework was designed to coordinate teams that had lost that visibility; imposing all of it on a team that never lost it is pure tax. The fix is not to abandon the feedback loops (keep the demo and the retro) but to drop the coordination ceremonies that are solving a problem you do not have.

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

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.