Agile Fundamentals

How to use this page

This page is your take-home companion to the live session. Read it before class to get a head start, or after class to lock the ideas in. Everything covered in the room is here in more depth, with extra examples and the exercises from each session.

The ten sessions move through six stages — Mindset, Framework, Planning, Execution, Scaling, and Delivery — each building on the one before it. Getting the mindset right first is exactly what this session is about: the frameworks and practices in Sessions 3–10 will feel logical rather than arbitrary once you understand the thinking behind them.

What you'll learn this session

Why Agile exists

To understand Agile, you first have to understand the way of working it was reacting against. For decades, most projects were run in what is now called a "waterfall" style: plan the entire thing up front, then move through fixed stages — gather all requirements, design the whole solution, build it, test it, and release it. Each stage must finish before the next starts, and you don't see anything working until the very end.

Four problems show up again and again with this approach.

Feedback comes too late

Because nothing works until the end, you only discover whether you built the right thing after months of effort. A wrong assumption in week one quietly shapes everything that follows.

Requirements change

What people ask for at the start is rarely what they need by the finish. Markets shift, competitors move, users change their minds. A plan that cannot absorb change becomes a liability the moment reality diverges from it.

Risk piles up at the worst moment

Testing happens at the end, when there is the least time and money left to deal with problems.

Value is delayed

A half-finished plan delivers nothing. Until the entire project ships, the customer has received zero benefit, no matter how much work has gone in.

The cost of waiting: late change is expensive

The later you discover that something needs to change, the more it costs to fix. A change spotted while still sketching costs almost nothing. The same change spotted after everything has been built around the original assumption can cost ten or thirty times more.

Where Agile came from

In 2001, seventeen software practitioners frustrated with slow, plan-everything-first projects met and agreed on a short statement of shared beliefs. They called it the Agile Manifesto: four values and twelve principles, expressed in plain language.

Agile did not start as a rulebook, a certification, or a set of mandatory meetings. It began as a set of values — a way of thinking about how to work well under uncertainty. That is why it has spread far beyond software into marketing, operations, education, and general project work.

The four values

Each value names two genuinely good things and tells you which to favour when they pull against each other.

1 · Individuals and interactions over processes and tools

Good people talking to each other solve problems faster than any process or tool can.

2 · Working software over comprehensive documentation

A real, working thing teaches you more than any description of it.

3 · Customer collaboration over contract negotiation

Treat the customer as a partner working toward a shared outcome, not an adversary across a contract.

4 · Responding to change over following a plan

A plan is a useful starting guess, not a promise to reality. When you learn something new, adjust — don't march on just because the plan said so.

The twelve principles

Behind the four values sit twelve principles, best understood as four plain-English themes.

All twelve, restated in plain English:

1. Our top priority is to satisfy the customer by delivering valuable work early and continuously.
2. Welcome changing requirements, even late on — change can be turned into an advantage.
3. Deliver working results frequently, from a couple of weeks to a couple of months, preferring the shorter timescale.
4. Business people and the delivery team must work together daily throughout the project.
5. Build projects around motivated people; give them the environment and support they need, and trust them.
6. The most effective way to share information is a direct, face-to-face conversation.
7. Working results are the primary measure of progress.
8. Agile promotes a sustainable pace — everyone should be able to keep going indefinitely.
9. Continuous attention to technical excellence and good design improves agility.
10. Simplicity — maximising the work not done — is essential.
11. The best results emerge from teams that organise their own work.
12. At regular intervals, the team reflects on how to become more effective, then adjusts.

Notice the pattern: deliver value, in small steps, with people at the centre, always improving.

The same app, built two ways

Imagine your team must build a food-ordering app. Two paths — and why they end so differently.

Both teams worked hard. The difference is when they learned the truth. The waterfall team learned it at month nine. The Agile team learned it in week three, when changing course was cheap.

Agile is a mindset, not a checklist

Agile is not a set of meetings you run or a tool you buy. It is a way of thinking about work under uncertainty: make small bets, get feedback fast, and adjust.

Where Agile fits — and where it may not

Agile is powerful, not universal. Good practitioners know which problems call for it and which don't.

The engine underneath: inspect and adapt

Strip away the vocabulary and every Agile practice is the same simple loop. You make the real state of the work visible, you check it honestly against the goal, and you adjust. Then you do it again.

Agile vs. the traditional approach

What Agile is not

In-class exercises

Go deeper

Key terms — Session 1

Agile

A mindset and set of values for delivering valuable work under uncertainty, favouring small steps, fast feedback, and adaptation over rigid up-front plans.

Waterfall

A traditional, sequential approach where a project moves through fixed stages — requirements, design, build, test, release — one after another, with results only at the end.

Agile Manifesto

The 2001 statement of four values and twelve principles that defines what Agile means.

Iteration (or cycle)

A short, fixed period of work — typically one to four weeks — at the end of which the team has produced something working and usable.

Feedback loop

The cycle of doing some work, showing it, learning from the response, and adjusting. Agile aims to make this loop as short as possible.

Transparency, inspection, adaptation

The three-part loop at the heart of Agile: make work visible, check it honestly, and adjust based on what you find.

Cost of change

The idea that the later a needed change is discovered, the more expensive it is to make. Agile works to find changes early, while they are cheap.

"Doing" vs. "being" Agile

Following Agile practices on the surface versus genuinely holding the underlying mindset. The practices only work when the mindset is real.

What you'll learn this session

The traditional project manager role

The classic project manager holds the plan, assigns the work, tracks the schedule, and keeps the project under control. It is a command-and-control model built for predictable, well-defined work. In that context, it makes complete sense.

From commander to enabler

In Agile, the role of the person leading the project shifts substantially. The goal is no longer to control every task but to create the conditions where a capable team can do its best work and deliver real value.

Three key roles you'll meet in Agile teams

Agile distributes responsibility across three distinct roles rather than concentrating it in a single project manager. Full coverage comes in Sessions 3–4 (Scrum).

What "done" actually means in Agile

In traditional projects, "done" often means the planned activity was completed — the document submitted, the hours logged. In Agile, "done" means something far more specific, and far more demanding.

What each "done" concept looks like on a real team

Abstract definitions are easy to agree with. The trouble starts when the team encounters an actual piece of work and disagrees on whether it meets the bar. These examples make the difference concrete.

From vision to working results

Scrum projects don't start with a full plan. They start with a clear vision, then work backwards through progressively more specific layers, delivering something real at the end of every Sprint.

The Agile iron triangle: what's fixed, what's flexible

Every project is constrained by scope (what gets built), time (the deadline), and cost (the budget). Traditional PM fixes scope and lets time and cost drift. Agile inverts this.

Fixing time and cost while letting scope flex actually delivers more of what matters. The team must choose what's most valuable for each iteration, so low-value work naturally falls away and the highest-value features ship first.

The Product Backlog: one prioritised list of everything

Instead of a project plan that tells everyone what to do each day, Agile uses a Product Backlog — a single, ordered list of all the work that could be done. The top items are well-understood and ready to build. Lower items are rougher and get refined as they move up.

The backlog is never "done" — it evolves as the team learns more. The Product Owner owns it: responsible for keeping it ordered, keeping the top items clear and actionable, and making sure the team always knows what to work on next.

What goes to the top of the backlog — and why

The constant question in Agile: of everything we could do next, what will deliver the most value right now? The answer is re-evaluated at the start of every iteration. Six factors typically drive the decision.

Business value

Which item has the biggest positive impact for users or the business? Not the most technically interesting — the most valuable.

Risk

Which uncertainty could hurt the most if left unresolved? Agile handles risk by tackling the riskiest unknowns early, while it's still cheap to change course.

Stakeholder need

Has the customer or sponsor flagged something as urgent? Stakeholder relationships are part of the prioritisation equation.

Dependencies

What must be done first because other work blocks on it? Building things in the wrong order creates rework.

Effort vs. value

Is there a quick win — a small item that delivers significant value — that can ship now while the team builds toward something bigger?

Learning value

What will teach the most, fastest? Some items are worth doing early not because they deliver immediate business value, but because they reduce uncertainty for everything that follows.

From output to outcome

Traditional PM measures success by adherence to the plan: did we deliver on time, on budget, in scope? Agile measures success by value delivered: did the right thing get built? Did users benefit?

The same website, two project managers

A company wants to relaunch their e-commerce site. Two PMs take very different approaches.

The Agile PM learned the truth about user needs in week three. The traditional PM learned it in month eight — at a cost of two extra months and significant rework. The difference is not effort: it's when feedback arrived.

Two paths: Scrum or Kanban?

Agile values tell you what to prioritise. Scrum and Kanban are the two most widely used frameworks that put those values into daily practice. Both implement the same Agile values — the difference is in structure. Sessions 3 and 4 go deep on Scrum; Session 7 covers Kanban in full.

Fixed Sprints: how Scrum works

Scrum organises all work into fixed-length Sprints. Every Sprint follows the same rhythm: plan, build, review, improve. The cadence creates regular delivery and forces the team to reflect on both the product and their process every two weeks.

Continuous flow: how Kanban works

Kanban does not work in Sprints. Work flows continuously through a visible board. The key mechanism is the WIP limit — a cap on how many items can sit in any column at once, forcing the team to finish before starting. Four principles underpin every Kanban system.

When does Kanban fit best?

Kanban is the right choice when work arrives continuously and unpredictably — support or operations teams, IT helpdesks, bug-fix queues, or any team whose primary job is handling incoming requests rather than building a predefined set of features. It also works well for teams that need to visualise and limit concurrent workload, or for continuous delivery pipelines where work does not batch naturally into releases.

Scrum board vs. Kanban board

Same Agile values, different visual logic. The board structure reflects how each approach treats time, scope, and flow.

What Agile does not mean for project managers

Concepts and traps that come up in practice

These topics aren't on the slides but will come up the moment you work on or alongside a real Agile team. Understanding them early prevents a lot of confusion later.

In-class exercises

Go deeper

Key terms — Session 2

Product Backlog

A single, ordered list of everything that could be done on a product. The PO owns it; the top items are well-defined; lower items are rough. It evolves continuously.

Definition of Done (DoD)

A shared, written agreement that defines what every piece of work must meet before it can be called complete. Typically: working, tested, peer-reviewed, accepted by the PO, and deployable. Written by the whole team before the first Sprint and applied without exception. Distinct from acceptance criteria, which are specific to individual stories.

Iron triangle

The three project constraints: scope, time, and cost. Traditional PM fixes scope; Agile fixes time and cost and lets scope flex based on what's most valuable.

Servant leadership

The idea that a leader's job is to serve the team's ability to do great work — removing blockers, creating clarity, and staying out of the way of capable people.

WIP limit (Work in Progress limit)

In Kanban, a cap on how many items can sit in any column at once. When a column is full, no new work enters until something moves forward.

Cycle time

In Kanban, how long a single item takes from the moment the team starts working on it to the moment it is considered done. A key metric for understanding system performance and predicting delivery dates without story points.

Throughput

In Kanban, how many items the team completes per unit of time (typically per week). Together with cycle time, throughput gives a data-driven picture of the team's capacity without requiring estimation.

Output vs. outcome

Output is what was built (features, documents, deliverables). Outcome is the change that resulted (users helped, problems solved, value created). Agile optimises for outcome.

Sprint Goal

A single, clear objective that the Scrum team commits to achieving within a Sprint. Scope can flex during the Sprint; the Sprint Goal does not. If the goal becomes unreachable, the Sprint can be cancelled by the PO — a rare but valid option.

Velocity

The average number of story points a Scrum team completes per Sprint, measured over several past Sprints. Used for forecasting (when will we ship X?) not performance management. Velocity is a team metric, not an individual one.

Backlog refinement

An ongoing activity (not a formal ceremony) where the team clarifies, estimates, and prepares upcoming backlog items before they reach Sprint Planning. Sometimes called "refinement." Unrefined backlogs are among the most common causes of poor Sprint Planning.

Technical debt

The accumulated cost of shortcuts taken during development — quick fixes, skipped tests, deferred clean-up. Like financial debt, it accrues interest: the longer it goes unaddressed, the more it slows future work. Managed by keeping it visible on the backlog and budgeting time to pay it down.

What you'll learn this session

What Scrum is — and what it is not

Scrum is a lightweight framework for developing and delivering complex products. It defines three roles, three artifacts, and four ceremonies — and then deliberately stops. It does not tell you how to write code, how to design interfaces, or how to run a meeting. Those decisions belong to the team.

The distinction between a framework and a methodology matters more than it might seem. A methodology tells you exactly how to do everything. A framework gives you structure and leaves the how to the people doing the work. Scrum is intentionally incomplete — that incompleteness is a design choice, not an oversight.

Scrum is built on the same three empirical pillars you saw in Session 1. Transparency means making the real state of the work visible — through boards, backlogs, and honest conversation. Inspection means regularly checking the work against its goal. Adaptation means adjusting the plan when inspection reveals a gap. Every Scrum ceremony exists to trigger one or more of these three things.

The five Scrum values

Scrum has five values that are not peripheral additions — they are the operating conditions that make the mechanics meaningful. Without them, you get compliance: teams that run standups and planning sessions that accomplish nothing because nobody is genuinely engaged with what those events are for.

Notice the relationship between the values and the ceremonies. The Daily Scrum only works if the team has the courage and openness to flag blockers honestly. The Retrospective only works if the team has the commitment and respect to hold difficult conversations. The values are not decorative — they are the load-bearing walls.

The Product Owner

The Product Owner is accountable for the value the product delivers. They do this primarily by managing the Product Backlog — deciding what gets built, in what order, and making sure the team always understands what the most important work is and why.

The PO is the single source of truth on product direction. That singularity is important: shared PO accountability is functionally no accountability. If two people both own the backlog, neither owns it.

The Scrum Master

The Scrum Master is accountable for the Scrum team's effectiveness. They do this by coaching the team on Scrum, facilitating the ceremonies, and removing anything that slows the team down. The key word is serves — the SM serves the team, not the organisation's management agenda.

This is a fundamentally different idea of leadership from the traditional model. The SM has no authority to assign tasks or override decisions. Their influence comes entirely from coaching, facilitation, and the trust the team places in them.

The Developers

The Developers are the group of professionals who do the work of turning backlog items into a working Increment each Sprint. They are self-organising — no manager tells them how to do the work — and collectively accountable — the team succeeds or fails together, not per individual.

Scrum recommends teams of 3–9 people. Smaller than three and the team lacks the cross-functional skills to deliver independently. Larger than nine and coordination overhead starts to undermine the agility Scrum is trying to create.

The three Scrum artifacts

Scrum has three artifacts, each providing transparency about a different dimension of the work. Items flow through them in sequence: from the Product Backlog, into the Sprint Backlog, and out the other side as the Increment.

User stories

A user story is a short, plain-language description of a feature told from the perspective of the person who wants it. The formula has three parts: who wants it, what they want to do, and why it matters to them. Keeping that structure forces the team to think about the user before the solution.

The story is not the full specification — it is a placeholder for a conversation. The real detail lives in the acceptance criteria and the discussion that happens between the PO and the team during Backlog Refinement.

Three questions to test any story

Before the team commits to a story, three quick checks cover the most common problems:

What good and bad user stories look like

The formula is simple. The discipline is in being specific enough that the team can act on the story without guessing. These examples show the difference clearly.

✓ Good stories

✕ Bad stories

Acceptance criteria and the Definition of Done

Every user story needs two quality bars before it can be considered complete. Understanding the difference between them prevents one of the most common sources of team conflict.

The Sprint cycle

Every Sprint follows the same rhythm: plan on day 1, build through the middle, review and improve on the final day. Each Sprint begins the moment the last one ends — no gap, no wind-down, no waiting for approval. The table below shows all four ceremonies in a standard two-week Sprint. The Sprint itself is a protected container: once the Sprint Goal is set, the team owns the work inside it. The PO does not add new items mid-Sprint without removing something of equivalent size.

The four ceremonies at a glance

Before going into each ceremony in depth, here is the full picture. Bookmark this table — it answers every "who runs it, how long, what comes out" question you'll have in the next four sections.

Two things worth noting before the detail: the time boxes above are maximums, not targets. A team that genuinely needs only 90 minutes for Sprint Planning should stop at 90 minutes. And every ceremony is a team event — the SM facilitates, but the team owns the outcome.

Sprint Planning

Sprint Planning begins the Sprint. The whole Scrum Team collaborates to decide what to build and how to build it. The output is a Sprint Goal — a short, compelling statement of why this Sprint matters — and a Sprint Backlog of the items the team will work on to achieve it.

The Sprint Goal matters more than most teams realise. It is what holds the Sprint together if reality intervenes and the team needs to make decisions mid-Sprint. If two items conflict and the team cannot do both, the Sprint Goal tells them which one to prioritise. Without a goal, every item is equally important — which means nothing is truly prioritised.

The Daily Scrum

The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint plan. It happens at the same time and place every working day. The hard time limit is not arbitrary — it forces the team to be concise, surface only what matters, and move deeper discussions outside the meeting.

The Sprint Review

The Sprint Review is where the team demonstrates the Increment to stakeholders and the PO, inspects what was built, and adapts the Product Backlog based on what was learned. It is the team's primary feedback loop with the real world.

The Sprint Review is not a sign-off meeting and not a performance review. It is a collaborative conversation about what was built and what to build next. The goal is feedback, not approval.

The Sprint Retrospective

The Sprint Retrospective is where the team inspects how it worked together — its processes, tools, interactions, and habits — and identifies concrete improvements for the next Sprint. It happens after the Sprint Review and before the next Sprint Planning.

The Retrospective is the ceremony that makes Scrum self-improving. Without it, the same problems resurface Sprint after Sprint. With it, a team steadily gets better at working together regardless of what they are building. It is also usually the first ceremony cut when time is tight — which is exactly backwards.

Supporting events teams commonly add

The four Scrum ceremonies are mandatory. But most real teams add supporting events around them to keep the work flowing well. These are not in the official Scrum Guide but are widely considered best practice — and for good reason.

Backlog Refinement (Refinement)

The most important supporting event. The team meets mid-Sprint — typically for one to two hours per week — to review upcoming backlog items. They clarify ambiguous stories, split large ones into smaller deliverable pieces, confirm acceptance criteria, and estimate effort. The goal is to ensure the top of the backlog is always ready for Sprint Planning, so Planning is not a scramble.

Without Refinement, Sprint Planning regularly runs long or produces commitments the team does not fully understand. With it, Planning is fast because the hard thinking happened earlier in the week.

Three Amigos (Story Workshop)

A short, focused conversation between three perspectives — typically the PO (what and why), a developer (how), and a tester (how do we know it's right) — before a story is built. These three roles tend to make different assumptions about what a story means. Catching those differences before any code is written costs nothing to fix. Catching them after costs days.

The conversation usually takes 15–30 minutes and can happen informally. The output is not a document — it is shared understanding.

Mid-Sprint Check-in

A brief team sync at the midpoint of the Sprint — not replacing the Daily Scrum, but supplementing it with a broader question: is the Sprint Goal still achievable? If the answer is no, the team has time to negotiate scope with the PO rather than arriving at Sprint Review having discovered the problem in the last 24 hours.

Definition of Done Review

Periodically — usually at the Retrospective — the team reviews and strengthens the DoD. A stronger DoD means higher-quality Increments over time. Teams often start with a minimal DoD (working, tested) and gradually add criteria (code reviewed, security scanned, performance benchmarked) as they mature.

How it all fits together

It is worth stepping back to see how all the pieces connect before looking at any of them in isolation again.

The Product Owner maintains a Product Backlog — an ordered list of everything that could be built. At Sprint Planning, the team pulls the most important items from the top of the backlog into the Sprint Backlog, commits to a Sprint Goal, and starts a Sprint.

During the Sprint, the team holds a Daily Scrum each morning to coordinate and adapt the plan. Mid-Sprint, they meet with the PO for Backlog Refinement, clarifying and sizing the items that will come up in future Sprints.

At the end of the Sprint, the team demonstrates the Increment at the Sprint Review. Stakeholder feedback is gathered and the Product Backlog is updated. Then the team holds a Sprint Retrospective to improve how they work together. The next Sprint begins immediately.

Where Scrum goes wrong in practice

Scrum fails more often from bad habits than from bad rules. These six patterns are the most common ways real teams undermine a framework they are nominally following.

The Sprint Board

The Sprint Board makes all Sprint work visible at a glance. It shows every item the team committed to, where each one currently sits, and how close the team is to the Sprint Goal. It resets at the start of every Sprint — only Sprint-committed work appears on the board.

The WIP limits are set by the team and tuned over time. A team that regularly has five items In Progress simultaneously is spreading effort too thin — WIP limits make that visible before it becomes a crisis. The board is updated daily, usually at or just after the Daily Scrum.

In-class exercises

Go deeper

Handouts, references & further learning

Six printable handouts, three reading picks, and five short videos — all focused on Sessions 3 and 4. The reference cards are designed to be kept and used, not just read once.

Key terms — Session 3

Scrum

A lightweight framework for developing and delivering complex products. It defines three roles, three artifacts, and four ceremonies — and leaves the "how" to the team.

Sprint

A fixed-length iteration in Scrum, typically 1–4 weeks. The Sprint is a container that protects the team from outside interference while they work toward the Sprint Goal.

Sprint Goal

A short, specific statement of what the Sprint is for. Agreed by the whole team at Sprint Planning. Guides all trade-off decisions made during the Sprint.

Product Owner (PO)

The person accountable for the value the product delivers. Owns and orders the Product Backlog. Single source of truth on product direction — not a committee.

Scrum Master (SM)

The person accountable for the Scrum team's effectiveness. Coaches the team on Scrum, facilitates ceremonies, and removes impediments. Serves the team — does not manage it.

Developers

The professionals who do the work of turning backlog items into a working Increment each Sprint. Self-organising and cross-functional. 3–9 people.

Sprint Backlog

The set of Product Backlog items selected for the current Sprint, plus the Sprint Goal and the team's plan for delivering them. Owned by the Developers.

Increment

The sum of all completed Sprint Backlog items — cumulative and potentially releasable. Must meet the Definition of Done.

User story

A short description of a feature from the user's perspective. Formula: "As a [user type], I want to [action], so that [benefit]." A placeholder for a conversation, not a full specification.

Acceptance criteria

Specific conditions a user story must meet to be accepted by the PO. Written per story, different every time. Answers: "how will we know this is correct?"

INVEST

A six-point quality checklist for user stories used by experienced Agile teams: Independent, Negotiable, Valuable, Estimable, Small, Testable. Useful as a deeper reference once the basics are solid — not a required step for every story in the early stages of Agile adoption.

Sprint Planning

The ceremony that begins every Sprint. Team selects backlog items, creates the Sprint Goal, and plans the first days of work. Max 4 hours for a two-week Sprint.

Daily Scrum

A 15-minute daily event for the Developers to inspect progress toward the Sprint Goal and adapt the plan. Not a status report — a coordination tool owned by the team.

Sprint Review

End-of-Sprint ceremony where the team demonstrates the Increment to stakeholders and the PO. Feedback is gathered. Product Backlog is updated. Not a sign-off — a conversation.

Sprint Retrospective

End-of-Sprint ceremony where the team inspects how it worked together and commits to 1–3 concrete improvements. The ceremony that makes Scrum self-improving.

What you'll learn this session

From knowing Scrum to running it well

Most Scrum training ends at the framework. Teams leave understanding what the ceremonies are — and then discover that knowing what Sprint Planning is and knowing how to run one well are two completely different things.

This session is about closing that gap with technique, not repetition. Each ceremony has common failure patterns that appear in almost every team's first year with Scrum. Naming them in advance makes them easier to catch and correct.

Running Sprint Planning well

Good Sprint Planning produces a Sprint Goal the team believes in and a Sprint Backlog the team owns. Bad Sprint Planning produces a list of tasks assigned by someone else to people who weren't consulted.

The difference usually comes down to whether the backlog was ready before Planning started, and whether the team had enough space to ask real questions.

The facilitation guide

Common Sprint Planning failure modes

How to split user stories that are too large

A story that cannot be completed in one Sprint is called an epic. The team's job — often during Backlog Refinement — is to split it into smaller stories that can each be delivered independently and still deliver real value to the user.

The most important constraint: each split story must be independently valuable. Splitting "User can log in" into "Backend auth logic" and "Login UI" is not a good split — neither is useful on its own. A better split delivers a complete (if minimal) slice of value.

Rule of thumb: if you cannot complete a story within one Sprint without heroics, it needs to be split. The splitting conversation is itself valuable — it forces the team to deeply understand the work before committing to it.

Backlog Refinement — what it looks like in practice

Backlog Refinement (sometimes called Backlog Refinement) is the ongoing work of preparing upcoming stories so that Sprint Planning is never the first time anyone has seen them. Without it, teams arrive at Sprint Planning facing vague, unestimated stories and spend the whole session clarifying rather than committing.

Refinement is not a formal Scrum ceremony — it is a recommended practice. Most teams run it once per Sprint, typically mid-Sprint, for 60–90 minutes. The Scrum Guide suggests spending no more than 10% of the team's Sprint capacity on it.

What happens in a refinement session

Running the Daily Scrum well

The Daily Scrum is the easiest ceremony to do badly and the fastest to improve. The difference between a useful standup and a waste of 15 minutes is almost entirely a matter of format and who is running it.

Three formats — the team chooses

Running the Sprint Review well

The Sprint Review is your team's most visible moment. Done well, it builds stakeholder trust, generates real feedback, and sharpens the backlog. Done badly — a slideshow with passive stakeholders and no real discussion — it is a ceremony that consumes two hours and changes nothing.

Running the Sprint Retrospective well

The Retrospective only works if people feel safe enough to be honest. Creating that safety is the SM's job — and it starts before the ceremony begins, not during it. Teams that are afraid to surface problems use the Retrospective for small talk and surface-level complaints.

Three techniques — rotate to keep sessions fresh

Handling impediments

An impediment is anything that slows the team down or prevents them from reaching the Sprint Goal. Removing impediments fast is the single most high-value activity a Scrum Master can perform — and the one most frequently neglected in favour of administrative tasks.

Types of impediments

The escalation ladder

Not all impediments can be resolved at the same level. The SM's job is to move each one up the ladder as fast as necessary — not to wait for the next Retrospective to surface it.

"Scrum But"

"Scrum But" is the term for teams that claim to use Scrum but have silently dropped the parts that felt inconvenient. The pattern is always the same: "We use Scrum, but [we skip X / we changed Y / we don't do Z]." The result is usually the worst of both worlds — the overhead of Scrum's ceremonies without the benefits of its discipline.

The tricky thing about Scrum Buts is that each individual exemption often sounds reasonable in isolation. Of course the PO is busy. Of course there's sometimes urgent work mid-Sprint. It is only when you step back and look at what has been quietly dropped that the pattern becomes clear.

How to recover from Scrum failure modes

Session 3 named the six failure modes. The table below gives the recovery path for each — concrete actions the SM and team can take to correct course without starting from scratch or abandoning Scrum entirely.

Scrum with remote or distributed teams

Most Scrum was designed with co-located teams in mind. Remote teams can use Scrum just as effectively — but each ceremony needs a deliberate adaptation to compensate for the loss of physical presence, informal communication, and the shared context that comes from being in the same room.

The fundamentals do not change. Transparency, inspection, and adaptation still drive everything. What changes is how you create the conditions for those things when the team isn't in the same room.

When Scrum needs to grow

A single Scrum team of 3–9 people can deliver a significant product. Sometimes a product grows large enough that one team is no longer enough — more people are needed, and coordination between them becomes its own challenge.

For now, the most important thing to know is this: make sure your single team is running Scrum well before thinking about scaling. Scaling amplifies both strengths and problems. A team that skips Retrospectives will skip them across ten teams simultaneously. The foundation must be solid first.

In-class exercises

Go deeper

Handouts, references & further learning

The Sprint Planning Worksheet and Retrospective Format Guide are especially useful to take into real work after Session 4. The full materials page also includes reading picks and five short videos.

Key terms — Session 4

Velocity

The average amount of work a Scrum team completes per Sprint, measured in story points or story count. Used for Sprint Planning forecasting — not as a performance metric or target.

Capacity

The team's available working time in a specific Sprint, accounting for holidays, support rotations, and other known commitments. Compared against velocity to decide what is realistic to commit to.

Story splitting

The practice of breaking a large user story (epic) into smaller stories that each deliver independent value and can be completed within one Sprint. Five common patterns: by workflow step, user type, data type, happy/unhappy path, and MVP slice.

Prime Directive

A statement read at the start of Retrospectives to establish a blame-free tone: "Everyone did the best job they could, given what they knew at the time." Attributed to Norm Kerth.

Scrum But

The pattern of teams that claim to use Scrum while silently dropping parts that feel inconvenient: "We use Scrum, but we don't do Retrospectives." Results in the overhead of Scrum without its benefits.

Impediment

Anything that slows the team down or prevents them reaching the Sprint Goal. Types include technical blockers, process bottlenecks, people dependencies, and external constraints.

Impediment log

A simple list of all open impediments, recording what each is, who owns resolution, and by when. Reviewed at every Retrospective. Open impediments with no progress are a signal the SM needs to escalate more aggressively.

Escalation ladder

The SM's four-step framework for handling impediments: (1) resolve directly, (2) escalate internally, (3) escalate externally, (4) make it visible. Each step is faster than waiting for the next Retrospective.

Walk the board

A Daily Scrum format where the team reviews the Sprint Board column by column — starting from Done and moving left — rather than each person answering three questions. Keeps focus on the Sprint Goal and board state.

Start / Stop / Continue

A Retrospective technique using three questions: what should we start doing, stop doing, and continue doing? Fast, actionable, and suitable for most teams and situations.

4Ls

A Retrospective technique covering four dimensions: Liked (what worked), Learned (new knowledge or insights), Lacked (what was missing), Longed for (what would have made the Sprint better). Useful for deeper reflection.

Scaling frameworks

Structured approaches for coordinating multiple Agile teams working on a single product or portfolio. Examples include Scrum of Scrums (lightweight), LeSS (Large-Scale Scrum), and SAFe (Scaled Agile Framework). Covered in depth in the post-course guide — relevant once a single team is running Scrum well.

Async standup

A Daily Scrum format where team members post their update asynchronously — typically at the start of their working day — using a tool like Geekbot or a structured Slack thread. Used by distributed teams in different time zones.

Core hours

A designated synchronous window when all team members in a distributed team are reachable. Decisions happen in core hours; updates and documentation happen asynchronously outside it.

What you'll learn this session

How Agile projects are initiated

Traditional projects begin with a detailed specification: a document defining every feature, scope, timeline, and budget before a line of work is done. Agile projects begin differently — with a shared understanding of the problem and just enough structure to start learning.

The initiation phase in Agile is not about certainty. It is about direction. The team needs to know who they are building for, what problem they are solving, and what success looks like — not every detail of how to get there.

The product vision

Every product needs a north star — a short, clear statement of what it is for, who it helps, and what makes it worth building. The product vision does not describe features. It describes purpose. When the team loses sight of what they are building and why, the vision is what brings them back.

Four qualities to test yours against

The Product Goal

Introduced in the 2020 Scrum Guide, the Product Goal is the long-term objective for the Scrum Team. It serves as the target against which the Product Backlog is planned.

What you'll learn this session

User Stories in depth

Session 5 introduced User Stories as the building block of Agile requirements. This session goes deeper. We will take the format you already know — As a / I want / so that — and examine what makes a story genuinely useful versus one that just fills the template. Then we will use User Stories to build a User Journey, define an MVP, and prepare for estimation. Everything from here uses QuickBite, a food delivery app with three user types: customers, restaurant owners, and delivery riders.

A User Story is a requirement written from the perspective of the person who will use the product — not a technical specification or a task description. When the entire backlog is made of stories written this way, you have replaced the traditional requirements document with something more useful: a living, ordered, human-readable list of what the product needs to become.

The three parts of the format — and why each one matters

The client's need, in their own words

Traditional projects collect requirements in a document — sometimes hundreds of pages, written by business analysts before a single line of code. The document attempts to capture everything upfront. In Agile, User Stories replace that document. Each story is one requirement, written as a real human need. The backlog of stories is the living requirements list — it grows, shrinks, and reorders as the team learns and the product evolves.

Three things every story needs

A story that just has the format is a starting point. A story the team can actually commit to and build has three things: the story itself, acceptance criteria, and the right size.

Story Splitting Techniques

A story that is too large to fit into a Sprint is an Epic. Splitting Epics into vertical, valuable slices is a core skill.

Never split a story by architectural layer (e.g., "Build the database", "Build the UI"). This violates the INVEST principle of value. Instead, use these common patterns to split stories vertically:

What you'll learn this session

Inside the Sprint — day by day

Planning, estimation, and story maps set the stage. But the Sprint itself — two weeks of actual delivery — is where Agile's inspect-and-adapt loop runs at its highest frequency. Understanding what good execution looks like is the foundation for knowing when something has gone wrong.

The team owns the how. The PO owns the what. The SM removes obstacles. None of these roles picks up slack for the other two — and a team that has blurred those boundaries will feel it in the Sprint.

The Sprint Board

The Sprint Board is the team's single source of truth for the current Sprint. It makes work visible — what is waiting, what is in progress, and what is done — in a format every team member can read in under ten seconds. A well-maintained board makes most status meetings unnecessary.

The burndown chart

A burndown chart shows how much work remains in a Sprint over time. The vertical axis is story points remaining; the horizontal axis is Sprint days. The ideal line runs from total commitment on day 1 to zero on the final day. The actual line shows reality.

How to read it

Five burndown patterns and what they mean

Most Sprint burndowns fall into recognisable patterns. Learning to name the pattern is the first step to knowing what to do about it — and more importantly, how early to act.

How the PO keeps the backlog current

The Sprint Review is not just a demo — it is the PO's primary signal for what to do next. Stakeholder reactions, questions, and feedback from real working software update the backlog in ways that no upfront planning can anticipate. A PO who treats the Sprint Review as a tick-box event and doesn't update the backlog afterwards has broken the feedback loop that makes Agile work.

Spotting a Sprint in trouble

The earlier a problem is identified, the more options the team has. A Sprint that looks fine at day 8 and collapses at day 9 had warning signals the team either missed or chose not to raise. Here are the five most reliable signals.

Mid-Sprint adjustments

When a Sprint runs into trouble, the team has more options than most people think — and fewer than managers typically want. The SM's job is to protect the team's ability to respond while maintaining the integrity of the Sprint Goal.

Handling Mid-Sprint Scope Changes

Sprints are meant to be protected, but emergencies happen. How a team handles interruptions defines their maturity.

When a stakeholder asks for a new feature mid-Sprint, or a critical production bug emerges, the Product Owner and Scrum Master must work together to protect the Sprint Goal without ignoring business reality.

What you'll learn this session

What Agile actually looks like when you start

Every Agile course teaches the ideal version: clear Sprint Goals, refined backlogs, stakeholders who engage, and teams that self-organise effortlessly. Real teams rarely experience this, especially at the beginning. Understanding what "imperfect Agile" looks like — and what to do about it — is the most useful thing a beginner can learn before their first Sprint.

When stakeholders want a fixed plan

One of the most common real-world challenges for a beginner Agile practitioner: a stakeholder asks "when will this be done?" and expects a specific date. Agile's honest answer — a range based on current velocity and remaining backlog — can feel unsatisfying to someone used to project plans with precise end dates. Handling this conversation well is a core skill.

The three things a stakeholder actually needs

Doing Agile vs Being Agile

Every organisation that adopts Agile starts by doing it — learning the ceremonies, installing the tools, following the framework. Most stop there. Being Agile requires a different answer to a more fundamental question: how does this organisation think about uncertainty, failure, and change?

Anti-patterns in Agile transformation

These patterns appear in almost every failed transformation. Each one is recognisable in hindsight. The goal is to recognise them while there is still time to change course.

Your sphere of influence

Most people cannot change their whole organisation. But everyone can change the way they work within their immediate team — and demonstrate value clearly enough to create pull from others. This is how most real Agile transformations actually spread: not from a top-down announcement, but from a team whose results make others curious.

The most effective change agents don't try to change the organisation. They create a team that others want to join, a process others want to copy, and outcomes others want to explain.

In-class exercises

Go deeper

Key terms — Session 8

Doing Agile

Adopting Agile ceremonies, tools, and vocabulary without the underlying mindset change. Teams run Sprints, standups, and Retrospectives — but estimates are still treated as commitments, standups are still status reports, and Retrospective actions are never implemented. The form exists; the function does not.

Being Agile

Working with a genuinely Agile mindset — where the Daily Scrum is a team coordination tool, estimates are honest forecasts, Retrospective improvements actually happen, and stakeholders receive transparent updates rather than polished status reports. Visible in behaviour, not in vocabulary.

Release forecast

An estimate of when remaining backlog work will be complete, calculated as: remaining points ÷ velocity = Sprints remaining. Always communicated as a range, never as a fixed date. Updated after every Sprint Review as velocity and scope change.

Scope creep

The gradual addition of new work to a Sprint or project without a corresponding removal of existing work. Causes backlogs to grow without end, Sprint Goals to blur, and teams to feel permanently behind. Addressed by enforcing the backlog boundary: new requests go to the Product Backlog, not directly into the Sprint.

Sphere of influence

The domain within which a person can make direct, immediate changes — starting with themselves, then their immediate team, then broader relationships. The most effective way to spread Agile practices is to start inside your sphere and let results create pull outward.

Anti-pattern

A common response to a problem that feels like it should work but consistently makes things worse. In Agile: standups that become status meetings, backlogs that only grow, Retrospectives without implemented actions, and estimates communicated as commitments are all anti-patterns — recognisable, named, and fixable once identified.

What you'll learn this session

What "done" actually means

Every Agile team uses the word "done" — but teams that haven't defined it mean different things when they say it. A developer says done when the code is written. A tester says done when it passes QA. The PO says done when a real user can use it. A stakeholder says done when it is in production. Without an explicit definition, done is a negotiation that happens at the worst possible moment: the end of a Sprint, under time pressure, in front of everyone.

Agile distinguishes between two separate things that both use the word done. Knowing the difference prevents the most common source of late-Sprint surprises.

The Definition of Done — how to write it and why it matters

The Definition of Done is not a list of tasks. It is a set of conditions that must be true before any story can be moved to Done on the Sprint Board. It represents the team's commitment to the minimum standard of work they will ship — and it is agreed by the whole team, not imposed by management.

A typical starter Definition of Done

Building the right thing vs building it right

These are two separate concerns that require different answers from different people on the team.

Quality as a shared team responsibility

In traditional projects, quality is owned by a QA department that tests the product at the end. By the time problems surface, the code is written, the decisions are made, and fixing issues is expensive. In Agile, quality is built into the process — every Sprint, every story, every day.

Giving feedback that actually works

Agile teams depend on feedback. Retrospectives only improve the process if people can say what went wrong. Sprint Reviews only improve the product if stakeholders can say what they actually think. And day-to-day quality only improves if teammates can tell each other when something isn't working — without damaging the relationship in the process.

Most feedback that fails does so for one of three reasons: it is too vague to act on, it describes the person rather than the behaviour, or it is delivered at the wrong moment. Good feedback has none of these problems.

The structure of feedback that works

Receiving feedback

Receiving feedback well is as important as giving it well. The most useful response to feedback is not agreement or disagreement — it is understanding. "Can you give me a specific example?" and "What would have been better?" are the two most valuable questions to ask when receiving feedback. They move the conversation from evaluation to learning.

Contributing well to a team

Agile teams are more than a group of people completing tasks. They are interdependent — a blocker on one person's story affects the team's ability to hit the Sprint Goal. Contributing well is not just about doing your own work. It is about being the kind of team member other people can depend on.

Working with colleagues who think in Waterfall

Not everyone you work with will have done this course. Some colleagues will still think in fixed plans, detailed upfront requirements, and sequential phases. Some will ask for a complete specification before they can start. Some will treat an estimate as a contract. This is normal — and it is not a problem to be solved by persuasion. It is a practical situation to be managed.

The Product Owner and the developers

The PO-team relationship is one of the most important dynamics in a Scrum team — and one of the most frequently misunderstood. The PO is not the team's manager. The team does not report to the PO. But the PO is the person who determines what gets built, in what order, and why. That creates a relationship that needs to work well in both directions.

In-class exercises

Go deeper

Key terms — Session 9

Definition of Done (DoD)

A shared, team-level checklist that applies to every User Story the team ships. Defines the minimum quality standard for all work — not the acceptance criteria for a specific story. Written by the whole team together, enforced every Sprint, improved over time through Retrospectives.

Acceptance criteria

Story-specific conditions that define when a particular User Story is done. Written by the PO before the Sprint begins. Different from the DoD — acceptance criteria answer "did we build what this story asked for?" while the DoD answers "did we build it to our agreed standard?"

Technical debt

The accumulated cost of shortcuts taken during development. Each shortcut saves time now and costs more time later — like financial debt that accrues interest. Teams carrying high technical debt deliver fewer story points per Sprint over time. Paid down through dedicated refactoring work, ideally budgeted as a percentage of every Sprint.

Building the right thing

Solving a problem that real users actually have. The Product Owner's primary responsibility. Measured by user behaviour, adoption, and outcomes — not by features shipped or velocity achieved.

Building it right

Delivering work that meets the team's quality standard, can be understood and changed by others, and does not introduce new problems. The developers's primary responsibility. Enabled by practices like code review, automated testing, and the Definition of Done.

Observable feedback

Feedback that describes what was seen or heard, rather than an interpretation or conclusion about the person. Observable feedback ("the story had no acceptance criteria") is specific and actionable. Interpretive feedback ("you don't care about quality") is easy to dismiss and hard to act on.

Closing the loop

Session 10 does not introduce new concepts. It is a deliberate pause — a chance to look back at the full journey, connect the pieces, and leave with a clear sense of what matters most. Every session built on the last. This session makes that architecture visible.

You will also complete the Final Assignment in class today. The brief is in the last section of this page. You will have 45 minutes of structured time to work through it with access to everything you have learned.

The full picture

Every session was designed to build on the one before it. Looking at the full arc at once shows why the order matters — and reveals the connections between stages that are easy to miss when you are inside them.

Five things worth carrying forward

Ten sessions produce a lot of material. Most of it you will look up when you need it. But five ideas from this course are worth internalising — because they change how you think, not just what you know. These are the ones that will still be useful in five years.

How to use this website after the course

This website was built to be a companion for the course — but it is also a reference you can return to whenever you need it. Here is exactly what is here and when to use each part.

Applying this in real life — where to start

The most common reason people don't apply what they have learned is not lack of knowledge — it is not knowing where to start. Here are practical first steps depending on where you are right now.

Bringing it all together — QuickBite Sprint 0

Work individually. You have 45 minutes. Answer each part in order.

Where to go from here

Ten sessions. Six stages. One complete picture of how Agile actually works — from the first principle to the last Sprint. What comes next is yours to decide.

Terms to carry forward

These are the ideas that cut across all ten sessions. If you only remember these six, the rest will follow.

Agile

A mindset for delivering work under uncertainty. Favours short feedback loops, small working increments, and adaptation over comprehensive upfront plans. Not a set of meetings — a way of thinking about how to work well when the future is unclear.

Sprint

A fixed-length iteration — typically two weeks — during which the team builds, tests, and delivers a working increment toward a Sprint Goal. Sprints do not extend. Incomplete work returns to the backlog. The next Sprint begins immediately when the last one ends.

User Story

"As a [user], I want to [goal], so that [benefit]." A requirement written from the user's perspective. The backlog of stories replaces the traditional requirements document. Three quality checks: is it small enough, is it valuable, is it testable?

Definition of Done

A team-level checklist that applies to every story — not the acceptance criteria for a specific one. Defines the minimum quality standard for all work. Written by the whole team, enforced every Sprint, improved through Retrospectives. A story that meets its acceptance criteria but fails the DoD is not done.

Velocity

The average story points a team completes per Sprint, calculated over the most recent 3–5 Sprints. Used for release forecasting — not as a performance target. Story points are only meaningful within one team; velocity cannot be compared across teams.

Feedback loop

The cycle of doing work, showing it, learning from the response, and adjusting. The shorter the loop, the less time is spent building the wrong thing. The inspect-and-adapt loop is the engine underneath every Agile practice — from the Daily Scrum (24-hour loop) to the Sprint Review (Sprint-length loop) to the Retrospective (process loop).