Agile, Scrum & Sprints

Agile is a way of working that delivers in small, fast iterations with frequent feedback, instead of disappearing for a year and unveiling a finished product nobody got to react to along the way. The bet behind it is simple: you’ll be wrong about some things, so it’s better to find out in two weeks than in twelve months. Ship a little, learn, adjust, repeat.

Scrum is the most common framework for actually doing Agile. Work runs in fixed-length cycles called sprints, and each sprint pulls its tasks from a prioritised list called the backlog. If Agile is the philosophy, Scrum is the concrete routine most teams follow day to day — with a set rhythm of meetings (often called “ceremonies”) that keep everyone in sync.

The sprint cycle

A sprint is a short, fixed window of work — two weeks is typical, though some teams run one or three. The length stays constant, which is what gives the team a steady, predictable heartbeat. Each sprint runs through the same loop.

1. Plan — the team pulls the highest-priority items from the backlog and commits to what it can realistically finish this sprint. Not everything; just what fits.
2. Build with daily standups — the team does the work, checking in briefly each day to stay coordinated.
3. Review (the demo) — at the end, the team shows finished work to stakeholders and gathers feedback.
4. Retrospective — the team reflects on how it worked and picks one or two things to improve next time.

Then the loop starts again. Over many sprints, the product grows in visible, reviewable increments rather than one big risky reveal.

The ceremonies, plainly

A standup is a short daily check-in — ideally ten or fifteen minutes, often literally standing up to keep it brief. Each person covers three things: what I did yesterday, what I’m doing today, and what’s blocking me. It’s a sync, not a status report to a manager, and it’s not the place to solve problems — those get taken “offline” afterward with the people involved.

A review demos finished work to stakeholders. The emphasis is on done and usable, not slideware. It’s where the people who care about the product get to react while there’s still time to act on it.

A retrospective (or “retro”) is different from all the others: it improves the process, not the product. The team asks what went well, what didn’t, and what to change. A healthy retro produces one or two concrete experiments, not a long list of complaints nobody acts on.

Who runs it

Scrum has three roles, and confusing them causes a lot of friction.

• The Product Owner owns the priorities — they decide what’s most important and keep the backlog ordered. They answer “what should we build next?”
• The Scrum Master owns the process — they remove blockers, protect the team from distractions, and keep the ceremonies useful. They are not the team’s boss.
• The team owns the work — they decide how to build it and how much fits in a sprint.

Sprints trade certainty about the far future for fast feedback in the near future. You can’t promise exactly what ships in six months, but you’ll never be six months wrong.

How to use it

Even if you’re not on a Scrum team, the vocabulary is everywhere, so use it precisely. If someone asks for a status, the standup format — done, doing, blocked — is a clean way to answer. If you keep hitting the same problem, raise it in the retro, not in frustrated side conversations; that’s literally what the meeting is for. And if you’re tempted to drop a “small” new request straight onto the team, route it through the Product Owner and the backlog instead — that’s how priorities stay honest and the team stays sane.

Spot the sprint ceremony

Read each meeting and decide which Scrum ceremony it is, then tap a card to flip it and check your answer.

Sort the sprint roles and terms

Drag each responsibility or definition into the correct Scrum role or concept — or tap an item, then tap a category. Hit Check placement when you’re done.