Explore Scrum delivery in action—learn how teams plan sprints, test early, stay aligned, and define “done” so real progress gets delivered every time.

---

8.4.1: What is Scrum?

Scrum is one of the best-known Agile frameworks, but what exactly is it?

At its heart, Scrum is a simple structure for organizing teamwork around short bursts of focused effort. These bursts are called sprints—fixed-length cycles, usually 1 to 4 weeks, where a team sets a goal, does the work, and delivers something usable. Then they stop, check how it went, and plan the next one.

So, instead of trying to deliver everything at once, Scrum helps teams deliver value piece by piece, learning and adjusting along the way.

It’s built for situations where:

• The final deliverable isn’t fully known upfront
• Stakeholder needs are expected to evolve as the work progresses
• Fast feedback will lead to a better result

This makes it perfect for software, digital tools, service design, and many internal change projects. But the approach isn’t limited to tech teams.

Scrum can be used in marketing, education, health, and community development, too. Basically, anywhere you’re solving a problem that’s not fully mapped out at the start.

But first, let’s clear up a common misconception: Scrum is not chaotic.

It’s not “do whatever you want” or “work it out as you go.” It may feel flexible compared to traditional project management, but it still has a structure. It just replaces long-term plans with short cycles, regular checkpoints, and very clear roles.

Each sprint includes:

1. A clear goal (what we’re trying to achieve)
2. A selected set of backlog items (what we’ll work on)
3. A shared understanding of “done” (when the work is finished)

The team then gets on with the work. No daily hand-holding. No endless meetings. Just short, focused check-ins to stay on track and adjust if needed.

So, why not just use a traditional project plan?

In a traditional plan, you’re often looking far ahead—sometimes months or even years. That means you have to account for complex dependencies, shared resources, and overlapping tasks. Planning at that scale requires coordination between multiple people working on the same deliverables, often with different equipment, timelines, and approval processes.

Scrum takes a different approach.

Because Scrum only plans one sprint at a time, each person is typically assigned work they can complete themselves within a short period. As we discussed earlier, effort—not duration—is the main consideration when planning work. Most tasks don’t require specialized equipment or shared inputs, and while team members do need to stay in sync, they’re largely free to work independently, using their own expertise to get the job done.

Scrum favors short cycles of autonomy, clarity, and momentum over the complications that come with larger-scale coordination.

So, why is it called Scrum?

Good question! We’ll reveal that in a bonus section at the end of this topic. But, spoiler alert: whoever named it clearly didn’t understand how rugby works.

---

8.4.2: Scrum people

Scrum has just three core roles. You’re already familiar with the Product Owner. They’re the person responsible for deciding what needs to be delivered and in what order. They represent the user’s voice and are the keepers of the sacred backlog.

Let’s unpack the other two—the Scrum Master and the Development Team—and see how they ideally work together without needing a traditional project manager to call the shots.

The Scrum Master: A different kind of project leader

The Scrum Master isn’t just a project manager in disguise. They’re not there to assign tasks, set deadlines, or keep a Gantt chart up to date.

Instead, their job is to make sure the Scrum process is working and to help the team work better within it.

Think of them as a facilitator, coach, and team guardian all rolled into one. Their responsibilities include:

• Helping the team stay in sync
• Removing blockers that are getting in the team’s way
• Protecting the team from distractions or interference
• Supporting the Product Owner by making sure backlog items are doable and done

They don’t manage the people—they manage the process. A good Scrum Master spends more time asking questions than giving instructions. They help the team reflect, improve, and stay focused on delivering value.

If you’re used to traditional project management, this might sound like stepping back, but it’s just a different way of leading. One based on support and trust, not command and control.

The Development Team: Self-organizing and cross-functional

Scrum teams don’t rely on handovers between departments or long approval chains. The Development Team includes everyone needed to deliver each sprint from start to finish. Depending on what we’re up to in this iteration, that might include analysts, designers, coders, testers, service reps—whoever the project needs.

Key things to know about the Development Team are that:

• They’re self-organizing—they choose how to get the work done
• They’re accountable for delivery—not the Scrum Master or Product Owner
• They work together as equals—there are no job titles or hierarchies inside the team

It’s a big shift from the traditional model, where one person delegates and others execute. In Scrum, the team plans together, solves problems together, and shares responsibility for the results.

But, wait. Can that really work?

Good question. On paper, this all sounds beautifully efficient—maybe even a little anarchic. But for Scrum to actually work in practice, a few key conditions need to be met:

• Clear purpose: The team must know what they’re trying to achieve and why
• Right people and skills: The team needs a mix of expertise from across the organization, and each person must be able to work independently without requiring constant direction.
• Trust and autonomy: Leaders need to step back, and teams need to step up
• Psychological safety: Team members must feel safe to challenge, speak up, and experiment
• Discipline: Scrum only works if everyone follows through on their commitments and sticks to the process

Without these? You don’t get agility—you get increasingly aggressive sticky notes.

So, here’s how it all fits:

• The Product Owner decides what gets built
• The Development team decides how to build it
• The Scrum Master holds the left and right limits from within and without. They help everyone stay on track and continually improve

Three roles, no micromanaging, and a shared focus on getting the job done, together.

Next up: how Scrum teams stay in sync and keep momentum through each sprint.

---

8.4.3 The rhythm of Scrum

Scrum is often described as a lightweight framework, and that’s true. There are no bloated templates or layers of formal reporting. But lightweight doesn’t mean unstructured.

What gives Scrum its strength is its rhythm—a steady, repeatable cadence of activity that keeps the team focused, aligned, and constantly moving. That rhythm is anchored in the sprint, and the one event that brings the team together every day is the daily stand-up.

The daily stand-up is a quick, 15-minute check-in. The team gathers at the same time every day and in the same place to align, flag blockers, and keep things moving.

It’s called a “stand-up” because standing up tends to discourage long-winded speeches. It’s short, sharp, and all about coordination.

And while it’s central to Scrum, the idea isn’t unique.

Tradespeople on building sites often hold a daily toolbox talk to run through the day’s plan, safety concerns, and job sequencing. No slides, no spreadsheets—just a practical start to the workday.

Likewise, hospital shift teams in emergency departments do daily “huddles” before each shift. They review patient loads, urgent cases, staff availability, and equipment needs. It’s not even a project meeting, just a crucial way to get aligned quickly before things get hectic.

Whatever the context, when people are doing short bursts of focused work in dynamic environments, a quick but regular team check-in is one of the most effective tools available.

The alternative—especially in traditional projects—is for individuals or small teams to meet with the project manager separately throughout the day or week. The PM acts as an information hub, pulling updates, pushing out instructions, and relaying key points. That works when you’ve got large teams with highly complex, dependent workflows.

But Scrum assumes something different: small, capable, self-managing individuals who can own their part of the work and coordinate directly. The daily stand-up keeps that loop tight.

What you cover (and what you don’t)

The stand-up format pivots on three simple prompts:

• What did I work on yesterday?
• What am I working on today?
• Is anything getting in my way?

This isn’t a time to impress anyone. It’s not a platform to perform. It’s a quick scan of the map before everyone gets back on the trail.

When it works well: A developer says they’re waiting on content before finishing a feature. A teammate jumps in—“I’ve got it now, I’ll upload it after stand-up.” The delay is avoided before it even starts.

And when it doesn’t: Each team member takes the floor and delivers a mini TED Talk. Timelines, insights, achievements—someone even shares a story about their cat. No blockers are raised (we’re too polite), no actions agreed (we’re too diplomatic), and no one’s sure what the point was. That’s not a stand-up—that’s a podcast.

Keep it crisp. If something needs more discussion, it’s parked and handled after the stand-up with just the relevant people.

The daily stand-up is the heartbeat of Scrum delivery. It’s how self-managing teams stay aligned during each sprint without relying on a central controller. Everyone knows what’s going on, what’s getting done, and where help might be needed.

It may seem like a small thing, but skipping it—or misusing it—can quietly drain momentum. Run it well, and your team stays connected, coordinated, and in control.

---

8.4.4: Done means done

In Scrum, the goal of every sprint is to deliver something usable—something that works, adds value, and could be released if needed. That only happens when teams finish what they start. Not “almost done.” Not “we’ll tidy it up later.” Done.

Importantly, Scrum doesn’t wait until the end of the project to test. It builds quality into every sprint.

The two main kinds of testing that happen during delivery are:

• Developer testing: The person doing the work checks it meets the requirements. This might include code reviews, unit tests, or peer checks, depending on the type of work.
• User acceptance testing (UAT): This happens closer to the end of the sprint. Stakeholders or users try the finished product and confirm it meets their needs.

This way, bugs, misunderstandings, or gaps are picked up early, before they snowball into bigger issues.

The Definition of Done

At the start of every sprint, the team defines what “done” means and sticks to it. This might include:

• Completed and tested
• Reviewed by a peer or stakeholder
• Documentation written
• Deployed to a test environment
• Ready for release (if needed)

This is called the Definition of Done, and it’s the gold standard for every iteration. It makes sure everyone’s playing by the same rules and helps avoid surprises at the end of the sprint.

You might also think of it as the sprint acceptance criteria.

However, sometimes, even with the best planning, items don’t get finished. That’s not ideal, but it’s also not the end of the world.

There are lots of reasons why something might not be done by the end of a sprint:

• It was too big or complex, and the team underestimated the effort
• Unexpected blockers popped up, like delays in approvals, missing resources, or dependencies
• The task wasn’t clearly defined, so more time went into clarifying or reworking it
• Testing revealed issues that need more time to fix
• The team was overloaded or pulled onto other urgent work

Critically, though, if an item doesn’t meet the Definition of Done, it’s not counted as delivered. It gets returned to the backlog, and the product owner decides whether to:

• Schedule it for the next sprint
• Break it into smaller chunks
• Park it for later

The team then reflects on what happened during the retrospective (which we’ll introduce shortly), so they can learn and improve.

Working this way helps reduce risk. Instead of discovering problems months later, you catch them early, when they’re cheaper and easier to fix.

It also helps avoid technical debt—unfinished work, short-term hacks, or vague promises to “fix it later.” Scrum teams aim to leave every item properly done before moving on.

And because testing happens early and often, it creates a fast feedback loop. Users and stakeholders can respond to real progress—not just status updates—and the team can adapt accordingly.

It’s not about looking busy

Ultimately, progress isn’t measured by how many hours people work. It’s measured by what’s actually done and usable.

So if someone says, “It’s nearly finished—I just need to test it and update the documentation,” it’s not done. If it’s not deliverable, it doesn’t count.

And that’s the point. Scrum holds a high standard: not to be picky, but to protect the team from rework, wasted effort, and false progress.