Agile, scrum, sprints, standups, retros, and roadmaps

Join any product team on a Monday morning and you will meet a calendar full of strangely named meetings.

You will see standup, sprint planning, retro, and the backlog refinement you met two lessons ago.

They all descend from one idea with a complicated reputation, and this lesson decodes the whole calendar: what each meeting is, who attends, what literally happens inside it, and what it produces.

What is agile?

AgileConcept · lights on your mapagileA 2001 manifesto that became the industry’s default philosophy: ship small, learn from what ships, replan without shame. The word has since been worn down into a corporate buzzword; the ideas underneath are still real, and the rituals in this lesson are their machinery. is a philosophy of building software in small increments with constant feedback, adjusting as you learn.

That is abstract, so watch the same feature get built two ways.

The old way, called waterfall: the coffee company spends three months writing a complete specification for delivery, then six months building all of it (scheduling, tracking, coupons, multi-café routing) before unveiling the finished thing. Customers try it once. Almost nobody wants scheduled delivery; they wanted faster pickup. Nine months and the budget are gone.

The agile way: the team ships the two-week MVP from two lessons ago (one café, same-day slots). Within a month, the data shows the same truth: low delivery demand, constant requests for faster pickup. The team changes direction, eight months earlier and vastly cheaper.

Waterfall was not stupid. It came from physical engineering, where changing a half-built bridge is ruinously expensive, so planning everything first is wisdom. Software’s material is different, and code can be reshaped continuously. So the cheapest way to learn what to build is to ship a slice and watch.

That is agile’s entire bet: small slices, shipped early, corrected constantly. It is Module 1’s input-processing-output pattern bent into a circle (ship, observe, adjust), and the MVP discipline is its child.

The idea was crystallized in 2001 as a short manifesto. Since then, “agile” has also become a buzzword meaning everything and nothing. So judge teams by their feedback loops, not their vocabulary.

What are scrum and kanban?

Agile is a philosophy, not a procedure. It does not tell a team what meetings to hold. In practice, teams adopt one of two working systems.

ScrumConcept · lights on your mapscrumAgile with a metronome: work is promised, built, and shown to a fixed beat, with the ceremonies hung off the cycle. Choose it when work arrives as plannable features; its sibling kanban suits work that arrives as surprises. organizes work into a repeating heartbeat: a fixed cycle (usually two weeks) with a committed goal, wrapped in a standard set of recurring meetings. Practitioners call them ceremonies (the Scrum Guide’s official word is events). Being on a scrum team feels like a rhythm: plan on Monday, sync daily, demo at the end, reflect, repeat.

KanbanConcept · lights on your mapkanbanAgile without the calendar: a standing board, a cap on how much may be in flight, and one rule: finish something, then take the next thing. Support and infrastructure teams live here, where the next task is whatever just caught fire. has no cycles at all. Work is a continuous flow across a board of columns, and each engineer pulls the next ticket when they finish the last:

The board’s defining rule is the WIP limit, the “(limit: 3)” on the Doing column. No matter how much is waiting, only three tickets may be in progress at once. Recognize the wisdom? It is Module 10’s back pressure, applied to humans. Starting everything means finishing nothing, so the column itself says “slow down, I’m full.”

Which system fits which team? Feature teams that plan in cadences tend scrum-ward. Interrupt-driven teams (support, infrastructure, anything that gets paged) tend kanban-ward because a two-week commitment means little when tomorrow’s work arrives by surprise. In practice most teams blend the two, and wars have been fought over less.

What is a sprint?

Scrum’s heartbeat cycle is the sprintConcept · lights on your mapsprintScrum’s unit of time: commit to a bundle of tickets, build for the fixed window, show the result. Schedules get discussed in counts of these, which is why “next sprint” lands as a distance, not a date.. Each one is a fixed work cycle, usually two weeks, with a name or number and a goal.

Make it concrete. Sprint 14 at the coffee company:

• Goal: customers can schedule a delivery (the MVP slice)
• Committed tickets: the slot picker, the fee display, and COFFEE-482’s acceptance criteria from two lessons ago

Every sprint has the same four-beat shape:

1. Sprint planning (first morning, about an hour): the team pulls tickets from the backlog into the sprint and agrees on the goal. “Commit” is the operative word. This is a promise about the next two weeks.
2. The work itself — the branches, PRs, and merges of this module’s first arc, punctuated by daily standups.
3. Sprint review (last day): the team demos what shipped to stakeholders. Working software, not slideware.
4. Retro (right after): the team examines its own process.

The commitment explains a piece of culture. Mid-sprint additions get resisted, politely but firmly. The sprint boundary is scope’s bodyguard, holding lesson 11.4’s scope creep at a two-week door. New work goes to the backlog and waits for the next planning.

Culturally, sprints are how scrum teams tell time. “That’ll be next sprint” means “roughly two to four weeks away,” and every PM learns to hear it as a unit of distance.

What is a standup?

The standupConcept · lights on your mapstandupThe team’s daily pulse-check, named for the old trick of standing up so it stays short. Beneath the ritual is one purpose: nobody stays stuck a whole day without the team knowing. When it drifts into reporting-to-the-boss, it has failed. is the daily meeting, and the one most worth understanding in detail because you may be standing in one soon.

The logistics first:

• Who: the whole team (engineers, the PM, often the designer). Typically five to ten people.
• When: every workday, same time, usually morning.
• How long: ten to fifteen minutes, hard stop. The name is the enforcement mechanism: classically everyone stands because nobody filibusters on their feet.
• What happens: going around the circle, each person takes about thirty seconds to answer the same three questions: what did I do yesterday, what am I doing today, what is blocking me.

Here are three standup turns, verbatim:

Now consider the design behind it. The first two questions keep the team loosely aware of each other’s work, which is useful but not the point. The entire point is question three.

Last lesson taught you what a blocker is. The standup is the machinery that finds them fast. Because the whole team answers the question every single morning, no blocker stays hidden longer than one day. Sam’s Quebec problem surfaced while it was hours old. Without the ritual, it might have quietly cost a week.

The choreography has one rule, and the transcript shows it:

Name the blocker in the meeting; solve it after the meeting.

The blocker gets named and an owner attaches to it. Then the meeting moves on within thirty seconds. The actual solving happens afterward, with only the people needed. A standup that stops to solve things dies for all its bystanders.

Equally important is what a standup is not:

• Not a status report to management. The audience is the team, speaking to each other as peers. Nobody is performing progress for a boss.
• Not a problem-solving meeting. Problems get named there, solved elsewhere.
• Not a planning meeting. The sprint already decided what to build; standup is about keeping today unstuck.

What is a retro?

At the sprint’s end, the retroConcept · lights on your mapretroThe end-of-cycle meeting where the team debugs itself instead of the product. The output stays deliberately small, a change or two to try next cycle. Candor survives only where blame is off the table., short for retrospective, turns the feedback loop on the team itself.

The logistics: the same people as standup, about an hour, once per sprint. But the subject is different. Every other meeting is about the product; the retro is about the process, asking how the last two weeks of working together actually went.

Three questions again, aimed inward this time, answered onto a whiteboard:

The craft is in the third column: one or two concrete changes, not a list of grievances. Next sprint’s retro will start by asking whether the changes helped, and that is the feedback loop looping.

The cultural norm is blamelessness. Notice that “PRs sat unreviewed” names a process problem, not a person. The retro asks “what about how we work allowed this?” — never “whose fault was this?” Hold that word; Module 13’s postmortems are built on it.

And notice what the retro is: the reason agile stays agile. A team that ships in small slices but never adjusts its own process has kept the calendar and lost the philosophy.

What is a roadmap?

Floating above all the sprints is the roadmapConcept · lights on your maproadmapWhere the next few quarters are written down at low resolution: themes and milestones, not tickets. Read it as direction rather than commitment; the dates at the far end are the least real, by design., the long-view plan for what the team intends to build over the coming quarters and in what order.

Where a sprint plans two weeks at ticket resolution, the roadmap plans quarters at milestone resolution. Many modern teams write it in a now / next / later format:

Notice what the format admits. Certainty decreases with distance, like every honest forecast. That is deliberate. A roadmap is a statement of intent, not a contract. Healthy ones are revised whenever reality files an objection: a failed MVP, a surprise competitor, an estimate’s iceberg surfacing.

It is the document that product and engineering argue over most lovingly because it is where the backlog’s ordering, the estimates’ icebergs, and the company’s ambitions all meet on one page.

A translation key for your first week

Four phrases, decoded:

• “That’s next sprint” = two-ish weeks away, probably.
• “Let’s take it to retro” = this hurt; let’s fix the process there, not litigate it now.
• “It’s on the roadmap” = we mean it, directionally, no date.
• “We’re at our WIP limit” = kanban’s do-fewer-things-at-once rule, holding.

None of it is jargon for jargon’s sake. Each phrase is a tiny tool for keeping forty people pointed the same way.

The mental model to remember

Agile is small slices, shipped early, corrected constantly, learning cheaply what waterfall learned expensively. Judge teams by their feedback loops, not their labels.

Scrum is agile on a heartbeat: two-week sprints wrapped in ceremonies. Kanban is agile as flow: a board with WIP limits, back pressure for humans. Most teams blend them.

A sprint is the cycle: plan, work, demo, retro, with a committed goal and a boundary that bodyguards scope.

A standup is the whole team, daily, fifteen minutes, three questions each, existing for question three. Surface blockers in the circle; solve them outside it.

A retro is the team debugging its own process, blamelessly, into one or two concrete changes tried next sprint. It is what keeps agile agile.

A roadmap is quarters of intent at milestone resolution (now, next, later), revised as reality votes.

You should now be able to walk into any of these meetings knowing who belongs there, what will literally happen, and what it exists to produce. And you can take part in the two that most need non-engineers: the standup’s blocker-chasing and the retro’s honesty.