Scrum in Practice: Roles, Artifacts, and Events
The most widely adopted Agile framework, and notably, one with no "project manager" role at all.
Intermediate
TopNotchNote
Notes that matter
scrum as a concrete framework
Scrum is the most widely used concrete implementation of Agile values — work happens in fixed-length iterations called sprints (commonly one to four weeks), structured by a small, deliberately defined set of roles, artifacts, and events.
the three roles
- Product Owner — owns the product backlog and decides what gets built and in what order; the single point of accountability for the value delivered.
- Scrum Master — a servant-leader who facilitates the process, removes impediments, and coaches the team on Scrum itself; has no authority over what gets built.
- Developers — the self-organizing, cross-functional team that decides how the work gets done.
Notably, there's no "project manager" role in Scrum by name — the responsibilities that role traditionally covers are split across these three. In practice, many organizations still layer a PM function around a Scrum team for things Scrum itself doesn't define, like budgeting, cross-team dependencies, or stakeholder management beyond the immediate product.
the three artifacts
| Artifact | What it is | Owned by |
|---|---|---|
| Product Backlog | Ordered list of everything that could be built | Product Owner |
| Sprint Backlog | Items pulled into the current sprint, plus a delivery plan | Developers |
| Increment | The sum of everything completed so far, meeting the Definition of Done | The whole team |
The Definition of Done is a shared, explicit checklist for what "done" actually means — tested, reviewed, deployed, whatever the team agrees on. Without it, "is this actually finished?" becomes a recurring argument instead of a settled question.
the five events
- Sprint — the fixed-length container itself; the sprint goal doesn't change mid-sprint, which protects the team from constant re-prioritization.
- Sprint Planning — deciding what will be done this sprint and roughly how.
- Daily Scrum — a short (~15-minute) daily sync focused on progress toward the sprint goal — a check-in among the team, not a status report upward to a manager (see effective meetings for what happens when this drifts into full status updates).
- Sprint Review — demoing the increment to stakeholders and gathering feedback, which feeds back into the product backlog.
- Sprint Retrospective — the team's own process-improvement meeting, held at the end of every sprint.
a short example
A small team building a customer-facing analytics dashboard runs two-week sprints. The Product Owner prioritizes the backlog around what customers ask for most. During sprint planning, the team pulls in enough items to reasonably fill the sprint. A blocker surfaces at the daily scrum on day three — a dependency on another team's API — and the Scrum Master helps clear it that same day rather than letting it sit. At the sprint review, stakeholders see working charts and ask for one tweak; instead of derailing the current sprint, it goes into the backlog for next time. The retrospective afterward surfaces that one item's estimate was badly off, which the team factors into how they estimate similar work going forward.
practical notes
Protecting the sprint from mid-flight changes is a feature, not bureaucracy — it gives the team a stable, predictable unit of focus instead of constant re-planning. A "Scrum" that lets stakeholders add new work into an active sprint whenever they feel like it isn't really Scrum; it's standup meetings wearing sprint-shaped names.