What Is Scrum
Scrum is a specific, concrete framework (three roles, four ceremonies, three artifacts), not a general word for working in short cycles.
Scrum is a framework, not a philosophy
Scrum is a defined way of organising a team's work into fixed-length iterations called sprints, usually one to four weeks, each ending with something usable and a look back at how the work went. It predates the word "agile" by several years, but became the most common way teams put agile values into practice after those values were written down in 2001.
What makes Scrum a framework rather than just "working in sprints" is that it's specific about who does what. It names three roles, prescribes four recurring events, and defines three artifacts that carry information between them. Change any of those and you're running something Scrum-inspired, which is fine, just not Scrum itself.
Three roles, three distinct jobs
Scrum deliberately splits responsibility for what gets built from responsibility for how the team works.
Owns the backlog and decides what gets built and in what order, based on value to the business or users. One person, one voice: a backlog with two owners quietly stops being a priority list.
Owns how the team works, not what it builds: runs the ceremonies, removes obstacles, and protects the sprint from being reshaped mid-flight by outside requests. Not a manager of the people on the team.
The people doing the work, collectively responsible for the sprint's output, regardless of job title. A cross-functional team here is one that rarely needs to hand work outside itself to finish something.
The four ceremonies
Sprint planning
At the start of each sprint, the team pulls work from the top of the backlog and commits to what it believes it can finish by the sprint's end. This is a forecast made by the people doing the work, not a target assigned to them from outside, and the distinction matters more than it sounds.
Daily scrum
A short daily check-in, traditionally fifteen minutes, where the team synchronises on what's happening and surfaces anything blocking progress. It isn't a status meeting for anyone outside the team; reporting upward is a different conversation that shouldn't consume this one.
Sprint review
At the end of the sprint, the team demonstrates what was actually finished to stakeholders and gathers reaction. "Finished" here means usable, not "code complete." The review is where an optimistic definition of done gets corrected in public.
Sprint retrospective
Immediately after the review, the team looks at how it worked, not what it built, and picks one or two concrete changes for the next sprint. A retrospective that produces a long list nobody revisits is theatre; a retrospective that changes one specific habit is doing its job.
The three artifacts
The product backlog is the full, ordered list of everything that might be built, owned and prioritised by the Product Owner. The sprint backlog is the slice of it the team committed to this sprint, plus the plan for delivering it. The increment is the sum of everything finished so far, in a state that could genuinely be released, whether or not it actually is.
Velocity, how much a team typically completes per sprint, usually measured in story points or item counts, isn't one of the three formal artifacts, but it's the number that makes Scrum's rhythm useful for forecasting rather than just for pacing.
A fourth thing worth naming, though it's a commitment rather than an artifact: the definition of done. Every item in the sprint backlog is measured against the same shared checklist (tested, reviewed, deployable) so "finished" means the same thing regardless of who did the work. Teams that skip this find their sprint review full of items that are done except for the parts nobody agreed counted as part of "done."
Scrum theatre: the signs
- Sprint commitments are assigned to the team rather than made by it
- The daily scrum has become a status report to a manager who isn't on the team
- Scope changes land inside a sprint that already started, routinely and without discussion
- Retrospective actions from three sprints ago are identical to this sprint's
- Nobody can say the team's actual velocity without checking
- "Done" means something different depending on who's describing the item
Any one of these is common and survivable. Several at once usually means the ceremonies are being run for their own sake rather than for what they're meant to produce.
Where the tool fits
Scrum's value depends on the sprint boundary and the velocity number both being trustworthy. A commitment nobody actually tracked, or a velocity nobody actually measured, makes every ceremony built on top of it a guess dressed up as a process. ShipSprint calculates delivery forecasts from a team's own measured velocity as sprints complete, rather than from a plan someone typed in at the start, and logging a day's hours takes about five seconds next to the task just finished, small enough that it actually happens, which is the only kind of tracking that produces numbers worth forecasting from.
Common questions
Two weeks is the most common default, mainly because it balances a useful feedback frequency against the overhead of running four ceremonies every cycle. One week suits fast-moving product work; four weeks suits teams whose work genuinely takes that long to show something meaningful. Whatever length is chosen, keeping it fixed matters more than the exact number.
Not necessarily a full-time, title-holding one on a small team. But the role's responsibilities still need to be done by someone, or the ceremonies drift and the sprint stops being protected from mid-flight scope changes. On small teams it's common for the role to rotate or sit alongside another job.
No. Agile is a set of values from 2001; Scrum is one specific, concrete framework, with named roles and defined ceremonies, for putting those values into practice. A team can hold agile values without running Scrum's ceremonies, and can run Scrum's ceremonies without actually holding agile values.
The mechanics scale down fine. A three-person team can run all four ceremonies. What often doesn't scale down is the overhead: four separate meetings a sprint can be a large share of a small team's week. Many small teams keep the artifacts and the rhythm but compress or combine the ceremonies.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required