Scrum Methodology — From Agile Foundations to Running Real Sprints
By the end of this module, you will be able to:
The Scrum Guide never calls these "meetings", and the distinction is not pedantry. A meeting is where information is exchanged; a Scrum event is a formal opportunity to inspect an artifact and adapt — each one exists to move the empirical loop from Module 2. Held well, the events create the regularity that eliminates the need for other meetings: no separate status meetings, steering committees, or sign-off sessions. If your calendar still fills with those, the events are not doing their job. And because every event is timeboxed (a maximum duration, never extended), the cost of inspection is fixed and predictable.
The Sprint is the heartbeat of Scrum and, formally, an event itself — the container inside which all the other events, and all the work, happen. A Sprint is a fixed-length period of one month or less in which the team turns selected backlog items into a Done Increment that moves the product toward the Product Goal.
Every rule above defends one thing: predictability of feedback. A Sprint that stretches, pauses, or absorbs random scope is a Sprint whose Review keeps sliding — and with it, the moment stakeholders see reality. Short, fixed, back-to-back Sprints put a hard ceiling on how long the team can be wrong about anything.
The Guide sets only the maximum (one month). Within that, the choice is a trade-off between feedback frequency and overhead:
| 1 week | 2 weeks | 4 weeks | |
|---|---|---|---|
| Feedback frequency | Very high — course-correct weekly | High — 26 inspection points a year | Low — a bad bet can burn a whole month |
| Event overhead | Highest share of the week goes to events | Moderate and predictable | Lowest proportionally, but each event is long |
| Room for meaty stories | Tight — stories must be very small | Enough for real features if stories are well split | Plenty — but invites big, risky stories |
| Pressure & focus | Intense; can feel relentless | Healthy urgency | Weeks 1–2 often drift ("plenty of time left") |
| Best for | Mature teams, volatile products, tight deadlines | Most teams, most products — the industry default | Very stable requirements, research-heavy work |
Our team is new to Scrum, so one-week Sprints would leave little room between the events to build anything, while four weeks would delay our very first user feedback by a month. Two weeks gives us enough runway to deliver 4–5 small stories, a Review every fortnight, and — crucially for learners — more repetitions of the full Scrum loop before this course ends. We will keep this length for the rest of the course; changing sprint length should be a considered Retrospective decision, not a per-sprint whim.
Sprint Planning opens the Sprint. The whole Scrum Team attends; the timebox is a maximum of 8 hours for a one-month Sprint — proportionally less for shorter ones (about 4 hours for our two-week TaskFlow Sprints). The event works through three topics, and it is worth learning them by their questions:
The output of Sprint Planning is the Sprint Backlog you met in Module 4: the Sprint Goal (why) + the selected items (what) + the plan (how). Note the direction of the logic: capacity determines scope, not the other way round. A team that lets a stakeholder's wish list determine the Sprint's contents is planning by hope.
Here is a condensed transcript of how Sprint Planning might sound for our team of three Developers (Sara, Omar, Lina), Product Owner (Rania), and Scrum Master (Khaled):
Rania (PO): The Product Goal is that individuals can fully manage daily tasks. For Sprint 1, I propose we aim for the smallest thing a real user could actually use: "A user can manage a basic task list." Create, complete, edit, delete — the core loop.
Omar (Dev): That matches the top four backlog items. But "manage" — does Sprint 1 include projects and lists? That story is fifth.
Rania: Not for the goal. A flat list of tasks that works end-to-end beats a half-built hierarchy. Projects can wait for Sprint 2.
Sara (Dev): We have no codebase yet, so "create a task" hides the setup work: repository, deployment pipeline, staging environment — our DoD says every story must be deployed to staging. I'd rather we make that cost visible inside the first story than invent a fake "Sprint 0".
Lina (Dev): Agreed. Then realistically: create, complete, edit, delete — four stories. I think delete is at risk if the setup runs long.
Khaled (SM): That's fine — the goal says basic task list. If delete slips, is the goal still met? Rania?
Rania: A list you can't delete from is annoying but usable — the goal survives. Let's select all four and treat delete as the flex item.
Sara: Then we're agreed: goal "A user can manage a basic task list", four stories selected, and we'll break them into tasks now, starting with the create-task story since it carries the setup.
Notice everything that just happened: the PO proposed the why but the Developers chose the what; scope was negotiated against the goal, not against wishes; hidden work was surfaced honestly; and a flex item was identified before the Sprint, not confessed at its end.
The Daily Scrum is a 15-minute event held every working day of the Sprint, at the same time and place to cut complexity — no scheduling negotiation, no calendar invites, it simply always happens. It is an event for the Developers, run by the Developers: they inspect progress toward the Sprint Goal and adapt the Sprint Backlog, producing a concrete plan for the next 24 hours. The Product Owner and Scrum Master attend as Developers only if they are actively working on Sprint Backlog items.
The single most common corruption of the Daily Scrum is turning it into a report to the Scrum Master or a manager — each Developer facing the "boss", listing yesterday's activity, waiting to be dismissed. The audience of the Daily Scrum is the Developers themselves. The test: if the Scrum Master is sick and nobody shows up to run it, does the Daily still happen? On a healthy team, nobody even notices the SM is missing.
Scrum prescribes no format — the Developers choose whatever keeps the event focused on the Sprint Goal. Two common options:
Each Developer answers: What did I do yesterday? What will I do today? What impediments are in my way?
Simple and easy to start with — but person-centric. It can drift into individual status recitals where nobody listens until their own turn.
The team pulls up the Sprint board and walks the items right to left — closest to Done first: "What do we need to finish TF-6 today? Who can unblock TF-8?"
Work-centric rather than person-centric: it naturally surfaces stuck items, swarming opportunities, and progress toward the goal.
A companion technique is the parking lot: when a topic needs a real discussion ("how should the reminder scheduler work?"), it is named, "parked", and taken up right after the Daily by only the people who need it. The fifteen minutes stay intact and nobody is held hostage to a debate that concerns two people.
The Sprint Review is held at the end of the Sprint, timeboxed at a maximum of 4 hours for a one-month Sprint (about 2 hours for TaskFlow's two-week Sprints). Its purpose: inspect the Increment and adapt the Product Backlog. The Scrum Team and invited stakeholders — real users, sponsors, sales, support — look at what is Done, discuss what changed in the market and the product, and decide together what to do next.
The most important word in the Scrum Guide's description is working session. The Review is often mislabelled as "the demo", and the difference matters:
| Demo-and-approve gate (anti-pattern) | Working session (Scrum Review) | |
|---|---|---|
| Direction | One-way: team presents, stakeholders judge | Two-way: everyone inspects and discusses |
| Stakeholders | Passive audience giving thumbs up/down | Active participants — ideally hands on the product |
| Question asked | "Do you accept this work?" | "Given what we now see, what should we build next?" |
| Acceptance | Happens here, dramatically | Already happened — Done was decided by the DoD during the Sprint |
| Output | A signed-off checkbox | A revised Product Backlog — items added, re-ordered, dropped |
The concrete outcome of a good Review is visible in the tool the next morning: the Product Backlog has changed. New items from stakeholder reactions, an item promoted because a user gasped at its absence, an item deleted because nobody cared. A Review after which the backlog is untouched was probably a demo.
On the staging site (remember the DoD — everything Done is deployed), a stakeholder is handed the keyboard and asked to use it: create the task "Prepare Module 5 lecture", edit its description, complete it, delete a task created earlier. No slides, no mockups — only the four Done stories. Then Rania puts the backlog on screen and asks: "Sprint 2 is planned as projects and lists plus due dates — does what you just used change that?" If a stakeholder says "I couldn't tell which tasks were finished at a glance", a new item enters the backlog on the spot.
The Retrospective closes the Sprint, timeboxed at a maximum of 3 hours for a one-month Sprint (about 90 minutes for a two-week one). If the Review inspects the product, the Retrospective inspects the team itself: individuals, interactions, processes, tools, and the Definition of Done. What went well? What problems did we hit? How did we solve them — and what will we change?
The non-negotiable output: at least one concrete improvement enters the next Sprint — ideally added to its Sprint Backlog so it is planned work, not a wish. "We should communicate better" is a sentiment; "PRs unreviewed for more than four hours get raised in the Daily" is an improvement. A team that retrospects for a year without changing anything has held twenty-six ceremonies and zero Retrospectives.
Structure prevents the Retrospective from collapsing into a generic gripe session; rotating formats keeps the answers from becoming rehearsed. Four proven ones:
Three columns: what should we start doing, stop doing, continue doing? The simplest format and the best default for a team's first Retrospectives — action-oriented by construction.
Liked, Learned, Lacked, Longed for. Adds a learning dimension the other formats miss — good after Sprints with new technology or new team members.
Sorts the Sprint by emotion rather than process. Surfaces frustration and morale issues that hide behind neutral process language — use it when the mood feels off.
Draw a boat: wind (what pushes us forward), anchors (what drags us), rocks (risks ahead), island (the goal). The visual metaphor loosens up teams tired of column lists and adds forward-looking risk talk.
Every format fails if people fear the consequences of honesty. Nobody says "I broke staging on Tuesday and hid it" in a room where that becomes ammunition. The Scrum Master's real Retrospective job is protecting safety: the prime directive ("everyone did the best job they could, given what they knew at the time"), no managers in the room unless the team invites them, criticism aimed at the process rather than persons — and visible follow-through, because nothing kills honesty faster than raising the same problem three Sprints in a row to no effect.
Memorise this table — it is the skeleton of every Scrum certification exam and, more importantly, of every real Sprint. Timeboxes shown are maximums for a one-month Sprint; shorter Sprints usually scale them down proportionally (the Daily Scrum stays 15 minutes regardless).
| Event | Timebox (1-month Sprint) | Participants | Purpose | Key output |
|---|---|---|---|---|
| The Sprint | ≤ 1 month (fixed) | Scrum Team | Container: turn backlog items into a Done Increment toward the Product Goal | Done Increment(s) |
| Sprint Planning | 8 hours | Scrum Team (others invited for advice) | Define why (goal), what (selection), how (plan) | Sprint Backlog incl. Sprint Goal |
| Daily Scrum | 15 minutes (always) | Developers | Inspect progress toward the Sprint Goal; adapt the Sprint Backlog | Plan for the next 24 hours |
| Sprint Review | 4 hours | Scrum Team + stakeholders | Inspect the Increment; discuss what to do next | Revised Product Backlog |
| Sprint Retrospective | 3 hours | Scrum Team | Inspect people, process, tools, DoD | ≥ 1 improvement for the next Sprint |
Open the TaskFlow project you built in Module 4 — its 17 ordered stories are about to become a Sprint. You will replay the worked Planning conversation from above, in the tool.
Sprint name: Sprint 1 — A user can manage a basic task list
Sprint goal: A user can manage a basic task listAs a user, I can create a task with a title and descriptionAs a user, I can mark a task as completeAs a user, I can edit a task's title and descriptionAs a user, I can delete a task (the flex item — first to drop if the goal is threatened)# Subtasks for: As a user, I can create a task with a title and description
Set up repository, CI pipeline, and staging environment
Design the task data model and create the tasks table
Build POST /tasks API endpoint with validation
Build the "new task" form UI (title + description)
Wire form to API and show the created task in the list
Write unit and integration tests for task creation
Verify on mobile viewport and check form accessibilitySwitch to the Board view. It is no longer empty: three columns — To Do, In Progress, Done — with your four stories (and their subtasks) stacked in To Do, and the Sprint Goal displayed at the top of the board. This board is your Sprint Backlog made visible: every Daily Scrum from now on starts by looking at it, and Module 7's burndown chart is generated from how cards move across it. Drag one subtask to In Progress just to feel the mechanics — then drag it back.
The Guide's timeboxes are stated for a one-month Sprint. Scale them to TaskFlow's two-week Sprint and design a working agenda for each event. Fill in a table with one row per event:
| Event | Your timebox (2-wk Sprint) | Agenda (3–5 bullet steps) | Facilitation risk you will watch for |
|---|---|---|---|
| Sprint Planning | ? | e.g. 1. PO presents goal proposal … | e.g. selection by wishful thinking |
| Daily Scrum | ? | ? | ? |
| Sprint Review | ? | ? | ? |
| Sprint Retrospective | ? | ? | ? |
| The Sprint (container) | ? | key calendar milestones across the 2 weeks | ? |
Timeboxes are maximums — your scaled numbers should be at or below the proportional value, and you should be able to justify each one.
Write a realistic 15-line dialogue of a TaskFlow Daily Scrum on day 4 of Sprint 1, using the team from this module (Sara, Omar, Lina; Khaled the SM may appear only to protect the timebox). Requirements:
You are the Scrum Master joining a brand-new team. Your deliverable is a kit you could genuinely use to facilitate that team's first Sprint.
| Component | Points |
|---|---|
| Facilitation guides — accuracy of purpose, participants, timeboxes, outputs | 25 |
| Facilitation guides — quality of agendas and anti-pattern interventions | 15 |
| Jira Sprint 1 correctly created, populated, and started (goal, stories, subtasks, dates) | 25 |
| Exercise 5.1 — scaled timeboxes correct and agendas workable | 15 |
| Exercise 5.2 — realistic dialogue, blocker surfaced and routed correctly | 15 |
| Clarity and structure of the written submission | 5 |
| Total | 100 |