Skip to main content
Scrum is the dominant agile framework in software product development. It organises work into short, fixed-length cycles called sprints, with a set of defined roles, ceremonies, and artefacts designed to keep teams focused and delivery predictable 🏉 It’s so widely adopted that for many teams “doing agile” and “doing Scrum” have become synonymous. That’s both a testament to its usefulness and part of why it gets misapplied.

​
The structure

Roles:
  • Product Owner - owns the backlog, defines priorities, represents the customer and business
  • Scrum Master - facilitates the process, removes blockers, coaches the team on Scrum
  • Development Team - self-organising, cross-functional team that does the work
Ceremonies:
  • Sprint planning - the team commits to a set of backlog items for the sprint
  • Daily standup - brief daily sync on progress and blockers
  • Sprint review - demo of completed work to stakeholders
  • Retrospective - team reflects on process and identifies improvements
Artefacts:
  • Product backlog - the ordered list of everything that might be built
  • Sprint backlog - the subset committed to in the current sprint
  • Increment - the working, potentially shippable product at the end of each sprint

​
What Scrum does well

The two-week heartbeat creates a useful forcing function. Teams have a regular moment to demonstrate working software, get feedback, and adjust. The retrospective builds a habit of continuous improvement. Sprint planning forces prioritisation 💡

​
Where it breaks down

Scrum assumes a stable team with clear priorities and well-understood work. When those conditions don’t hold, the ceremonies become overhead without benefit. The most common failure: treating Scrum as a delivery framework without running discovery in parallel. If the backlog is full of untested assumptions, running perfect sprints just ships the wrong thing faster. That’s the case for dual-track agile. Story points and velocity also attract the wrong kind of attention from management - teams end up optimising for velocity rather than outcomes, which is exactly the output trap Scrum was never designed to create 😅 Ryan Singer’s Shape Up is worth reading as a deliberate alternative to Scrum - Basecamp’s approach to longer cycles, fixed time/variable scope, and no daily standups. Lesson learned: the best Scrum teams I’ve worked with treated the ceremonies as tools, not rituals. They shortened standups when they weren’t useful, skipped planning when the work was clear, and used retros to actually change things - not just complain 🙌