Scrum is a lightweight framework for running agile product development in fixed-length iterations called sprints, with a small set of defined roles, events, and artifacts.
The idea
Work is pulled from a prioritized backlog into short, fixed-length sprints (commonly one to four weeks). A small set of roles keeps the process light: the Product Owner owns the backlog and priorities, the Scrum Master facilitates the process and removes blockers, and the Development Team builds the increment. A handful of recurring events — sprint planning, a daily stand-up, a sprint review, and a retrospective — give the team a regular rhythm to plan, inspect, and adapt.
When to use it
- Product development where requirements are expected to evolve
- Teams that benefit from a regular cadence of planning and review
- Work that can be broken into a prioritized backlog of shippable increments
How to apply it
- Build and prioritize a product backlog.
- Plan a sprint by pulling a slice of backlog items the team commits to finishing.
- Hold a short daily stand-up to surface blockers.
- Review the completed increment with stakeholders at the end of the sprint.
- Run a retrospective to adjust the team’s own process before the next sprint.
Watch out for
- Running the ceremonies without the underlying discipline of inspect-and-adapt turns Scrum into empty ritual
- A Product Owner who isn’t actually available to clarify priorities stalls the whole process
- Sprints that run too long lose the fast-feedback benefit Scrum is built around
Related models
- Agile — the broader philosophy Scrum implements.
- Waterfall — the sequential approach Scrum and agile react against.
- Kaizen — the retrospective borrows this continuous-improvement idea.
Sources
Ken Schwaber and Jeff Sutherland, The Scrum Guide.