On this page
Something that works every few weeks
With Scrum you see something that works every few weeks, instead of a product after a year that no longer fits. What you learn then changes the order of what comes next.
The Scrum Guide, the official text by its creators, calls it a lightweight framework, not a full method. It says who decides what, which moments are fixed and which lists you keep. How you do the work itself is left open. A Scrum team is small, typically ten people or fewer.
Scrum belongs to agile, the wider movement that got its own manifesto in 2001. Agile is the attitude; Scrum is one way to put it into practice.
A 1986 article and the Scrum Guide that followed
- 1986An article in Harvard Business ReviewHirotaka Takeuchi and Ikujiro Nonaka publish The New New Product Development Game in January: making new products takes speed and flexibility, not just quality, low cost and differentiation.
- 1995Schwaber and Sutherland present ScrumKen Schwaber and Jeff Sutherland co-present Scrum at OOPSLA, a software development conference.
- 2001The Agile ManifestoFrom 11 to 13 February, 17 people meet at Snowbird, Utah, among them representatives of Scrum. They write the manifesto for agile software development.
- 2010The first Scrum GuideSchwaber and Sutherland put the rules in one short document, revised several times since.
- 2020The November versionOne team instead of a team within a team, three accountabilities, a Product Goal and under 13 pages. It is still the current version.
Three accountabilities, five events, three artifacts
The accountabilities. The Product Owner decides what comes first and keeps the list of work; that is one person, not a committee. The Scrum Master guards the way of working and clears what blocks the team. The Developers build, test and deliver.
The events. The sprint itself lasts a month or less, most often two weeks. It opens with Sprint Planning: what do we build, why, and how. Every day there is a 15-minute Daily Scrum. At the end the team shows what it made in the Sprint Review, and looks at its own way of working in the Sprint Retrospective. For a one-month sprint, planning, review and retrospective take at most eight, four and three hours; shorter for a shorter sprint.
The artifacts. The Product Backlog is the ordered list of everything the product still needs, under a Product Goal. The Sprint Backlog is what the team takes on this sprint, with a Sprint Goal. The Increment is the part that is done, against a Definition of Done agreed in advance.
One two-week sprint
A two-week sprint, day by day
Week 1
- MonDaily 15 min
- TueDaily 15 min
- WedDaily 15 min
- ThuDaily 15 min
- FriDaily 15 min
Week 2
- MonDaily 15 min
- TueDaily 15 min
- WedDaily 15 min
- ThuDaily 15 min
- FriDaily 15 min
Who
- Product Owner: decides what comes first
- Scrum Master: guards the way of working
- Developers: build the increment
When
- The sprint itself, a month or less
- Sprint Planning
- Daily Scrum, 15 minutes
- Sprint Review
- Sprint Retrospective
What
- Product Backlog, with the Product Goal
- Sprint Backlog, with the Sprint Goal
- Increment, with the Definition of Done
Every sprint ends with something that works and that you can show. What you learn in the review changes the order for the next sprint.
A wholesaler and an outside team, sprint by sprint
Take a wholesaler in Rotterdam that has a customer portal built by a development team in Ghent. Three developers do the work, the wholesaler's operations manager decides what comes first, and one of the developers guards the process. A sprint lasts two weeks, and everyone meets on a video call.
What that costs in time, with events kept short as suits a small team: two hours of planning, nine Daily Scrums of fifteen minutes, an hour of review and an hour of retrospective. That is six and a quarter hours per person per sprint, about 8 percent of eighty working hours. The operations manager, as Product Owner, spends less: planning and review, three hours every two weeks, plus questions in between. Those three hours are the best spent of the project: working software every two weeks, in time to change course.
What a small company keeps without the full ceremony:
| Part of Scrum | Full Scrum | The light version | What you lose if you drop it |
|---|---|---|---|
| Sprint | One to four weeks, fixed rhythm | Two weeks, fixed rhythm | Without rhythm everything slips to "next week" |
| Product Owner | One person, close to full time | The owner or one fixed decision-maker, a few hours a sprint | Without one, the team builds on instinct |
| Daily Scrum | 15 minutes a day | For a team of two: a written update a day | Little, if the team is small and sits together |
| Sprint Review | With stakeholders, up to four hours | An hour's demo with the people who use it | You only hear at the end what does not work |
| Retrospective | After every sprint | A quarter of an hour each sprint, or monthly | The same mistakes keep coming back |
| Scrum Master | A separate accountability | A developer who takes it on | Blockers stay where they are |
| Definition of Done | Fixed in advance | A short list: tested, on staging, shown | Half-finished work counts as done |
If an agency or a nearshore team builds your software, you are the Product Owner, whether anyone calls it that or not. That is the main thing Scrum teaches: one person owns the order, and that person sees the result every two weeks. Start with an MVP and an ordered list from your requirements specification, measure what each sprint delivers as you would with an OKR, and run every review with the people who will really use the software: that is where you see whether the UX holds.
Where it does not fit
Scrum is made for work you cannot fully know up front: a new product, software that still has to grow. For work that runs the same each time, such as a website on a known structure or setting up a standard package, it adds little; a plan with milestones will do. A team of one needs no Daily Scrum. And Scrum does not settle whether to buy a package or build; you decide that first, with build vs buy software and the question whether a SaaS is enough.
If you first need to know whether an idea works, start with a proof of concept or an MVP and continue in sprints after that. And reserve some time in every sprint for clean-up, or technical debt piles up sprint after sprint.
About sprints, roles and fixed prices
What is the difference between agile and Scrum?
Agile is the wider way of thinking: work in small steps, deliver often and adjust to what you learn. Scrum is a concrete framework to do that, with fixed accountabilities, events and lists. You can work agile without Scrum, but Scrum is always agile.
What is a Scrum Master?
The person who makes sure the team works by Scrum and clears what holds it back: a decision that does not come, a dependency on another team, meetings that overrun. Not a project manager handing out tasks; the team chooses who does what.
What is Scrum in project management?
A way to run a project in fixed sprints instead of one long plan. Scope is not fixed up front; the order is, and it is reviewed every sprint. That suits software and product work better than a building project with a fixed design.
Do I need certified Scrum people on my project?
Not necessarily. A certificate shows someone knows the Scrum Guide, not that they deliver. Ask instead for a fixed sprint length, a demo every sprint and a Definition of Done in writing.