Scrum definition
Scrum is an Agile framework for developing products in short, fixed-length iterations called sprints, usually one to four weeks long. A small cross-functional team, guided by a product owner and a Scrum master, plans a sprint goal, builds a usable increment, reviews it with stakeholders and reflects on how to improve before the next sprint.
How does Scrum work?
Scrum, defined by Ken Schwaber and Jeff Sutherland in the Scrum Guide, organizes work around a product backlog: an ordered list of everything the product might need. At the start of each sprint, the team selects the highest-priority items it can complete, agrees a sprint goal and plans the work. During the sprint, the team meets briefly each day to coordinate. At the end, it demonstrates a working increment and holds a retrospective on its process.
The fixed rhythm creates regular inspection points. Stakeholders see real progress every sprint, priorities can change between sprints without disrupting work in progress, and problems in the process surface quickly instead of accumulating unnoticed for months. This cadence also gives the team a natural moment to adjust scope when priorities shift.
Scrum roles, events and artifacts
The framework is intentionally small. The Scrum Guide defines three accountabilities, five events and three artifacts, and leaves engineering practices, tools and estimation techniques to the team. That minimalism makes Scrum easy to learn, but it also means teams must add good technical practices themselves for it to work well.
- Product owner: maximizes product value and orders the backlog.
- Scrum master: coaches the team and removes impediments.
- Developers: everyone who builds the increment, including testers and designers.
- Events: the sprint, sprint planning, daily scrum, sprint review and retrospective.
- Artifacts: product backlog, sprint backlog and the increment, each with a commitment.
Example of a Scrum sprint
A team building a clinic booking app runs two-week sprints. In sprint planning, the product owner presents the top backlog items: online payment for appointments and SMS reminders. The team commits to a goal of letting patients pay when booking. Over the sprint, developers build the payment flow, write tests and deploy to staging. At the review, clinic staff try the feature and ask for receipts by email, which the product owner adds to the backlog. The retrospective identifies slow code reviews as a bottleneck.
Common Scrum mistakes
Many teams practice Scrum in name only. Daily scrums become status reports for managers, sprint reviews become slide presentations instead of hands-on demos, and retrospectives produce the same complaints every sprint without any change. Another frequent problem is a product owner without real authority, who cannot make priority decisions and has to escalate everything.
Teams also overload sprints, carry unfinished work forward repeatedly, or skip the definition of done, so increments are not truly releasable. Scrum works best with stable teams, a clear product owner, a strict definition of done and engineering practices such as automated testing and continuous integration.
Scrum vs Kanban
Kanban has no sprints or prescribed roles. Work flows continuously across a board with limits on work in progress, which suits support, maintenance and operations teams with unpredictable incoming requests. Scrum suits product development where planning in increments helps. Nexzem's delivery teams typically use Scrum for new product builds and Kanban for ongoing support engagements.