Scrum Methodology — From Agile Foundations to Running Real Sprints
Six modules of theory and setup converge here. You have a framework (Modules 2–3), a backlog (Module 4), a planned and started Sprint (Module 5), and estimates on everything (Module 6). This module runs Sprint 1 — all ten working days of it — as a guided simulation: every day has a team narrative, exact Jira actions to perform, and one lesson to keep. The Sprint will not go smoothly. That is deliberate: a blocker, a scope attack, and an honest mid-Sprint forecast miss are where Scrum earns its keep.
By the end of this module, you will be able to:
In this simulation you are the whole Scrum Team: when the script says Rania (PO) declines a scope request, you make that decision and write that comment; when Khaled (SM) removes an impediment, you remove the flag; when Sara, Omar, and Lina (Developers) finish a subtask, you drag the card. This is not busywork — moving the cards yourself is how the mechanics (flags, scope changes, burndown steps, sprint completion) become muscle memory instead of trivia. Perform every "Jira actions" list for real: your Module 7 Project is graded on the artifacts these actions generate.
Everything below already exists in your Jira project — this card is the single-page recap the team would pin to the wall:
Sprint Goal: "A user can manage a basic task list"
Duration: 2 weeks — 10 working days, Monday to Friday twice over
Team: Rania (Product Owner) · Khaled (Scrum Master) · Sara, Omar, Lina (Developers)
| Key | Story | Points | Note |
|---|---|---|---|
| TF-5 | Create a task with a title and description | 2 | Carries the one-off setup subtasks (repo, CI, staging) |
| TF-6 | Mark a task as complete | 2 | |
| TF-7 | Edit a task's title and description | 3 | |
| TF-8 | Delete a task | 1 | The flex item — first to drop if the goal is threatened (agreed at Planning) |
| TF-17 | Sign in with my Google account | 5 | Pulled in during Module 6's estimation lab |
| Committed | 13 |
Board columns: To Do → In Progress → Done
Definition of Done (from Module 4): code reviewed by another Developer · automated tests written and green · deployed to staging · verified on a mobile viewport · keyboard-accessible with labelled form fields
For the simulation we treat today as Day 1, regardless of when you actually clicked Start sprint. Points burn only when a whole story reaches Done — subtask progress moves cards but not the burndown. Where a day says "add a comment", write it in your own words; comments are the audit trail your evidence pack is built from. And resist fast-forwarding: the mid-Sprint decisions only make sense if you let each day's information arrive in order.
The team. Planning ended Friday; this morning the board is a wall of To Do. The instinct is for each Developer to grab a different story — Sara takes create, Omar takes sign-in, Lina takes edit — and the team resists it. Three stories in progress with an empty codebase means three people fighting over the same missing foundations. Instead they swarm the top story: TF-5 carries the setup subtasks, so finishing it unblocks everything else. Sara takes the repository/CI/staging subtask, Omar the data model and POST /tasks endpoint, Lina the task form UI.
Jira actions:
Day 1 — swarming this story first; it unblocks the rest of the sprint.Lesson: Start a Sprint by finishing things, not by starting everything. One story flowing beats five stories crawling.
The team. At the Daily, the team walks the board right to left. Nothing is near Done yet — expected. Sara reports the CI pipeline "fights back": the test runner works locally but fails in CI. Omar's endpoint is ahead of schedule, so the plan changes: Omar pairs with Sara on the pipeline for the morning. Lina's form renders; she needs the API to wire it. That is the whole meeting — eight minutes, plan adjusted.
Jira actions:
Day 2 — CI failing on test step; Omar pairing with Sara this morning.Lesson: The Daily is replanning, not reporting. "Omar pairs with Sara" is a decision no status email would have produced.
The team. Morning: the pipeline is green, the form is wired, tests pass, the app deploys to staging. TF-5 is checked against the DoD line by line — review done, tests green, staging live, mobile viewport verified, keyboard accessible — and moves to Done. First burn: 13 → 11. The team takes the small win and pulls the next work: Omar starts TF-17 (Google sign-in), Lina starts TF-6.
By noon Omar hits a wall: registering TaskFlow with Google's OAuth service requires API credentials from the university's Google Cloud organisation account — which none of the Developers can access. He cannot code around it; every sign-in flow needs a real client ID. Omar does two things immediately: he makes the blocker visible in Jira, and he posts it in the team channel rather than waiting for tomorrow's Daily. Khaled takes the impediment — chasing the credentials is now his job, not Omar's — and Omar switches to helping Lina finish TF-6 instead of sitting idle.
Jira actions:
Day 3 — BLOCKED: need OAuth client credentials from the org Google Cloud account. Raised with Khaled (impediment).Lesson: A blocker's cost is measured in how long it stays invisible. Flag it in minutes, hand the impediment to the Scrum Master, and redeploy yourself — never sit quietly "waiting for access".
The team. Mid-morning, a stakeholder from marketing emails Rania: a competitor just shipped dark mode, and "it's basically a CSS change — can the team just squeeze it into this sprint? It would look great in Friday's newsletter." Rania answers the same day, politely and firmly: no work enters a running Sprint from outside. The Sprint exists so the Developers can hold a stable plan for two weeks; dark mode is already in the Product Backlog as TF-19, and she offers something better than a promise — a slot in the next refinement session to discuss its priority for Sprint 2, plus a note on the ticket recording the competitive signal. The stakeholder leaves with a path, not a brush-off.
Meanwhile Khaled's chase pays off: the credentials arrive late afternoon. He removes the flag, and Omar confirms he can resume TF-17 tomorrow morning. Lina's TF-6 is nearly through review.
Jira actions:
Day 4 — stakeholder request: competitor shipped dark mode; wants it ASAP. PO decision: not entering Sprint 1. To be discussed for Sprint 2 at refinement.Day 4 — credentials received; impediment resolved by Khaled. Resuming tomorrow.Lesson: The Product Owner's "no" is really a "not now, and here is where it lives" — the backlog is the pressure valve that makes Sprint stability possible.
Compare Day 4 with Module 6's lab, where TF-17 was added mid-Sprint. The difference is not the direction of the change — it is who decided and what it protected. In Module 6 the Developers found capacity and pulled work in collaboration with the PO, strengthening the Sprint Goal. On Day 4, work tried to enter from outside, past the team, serving a newsletter rather than the goal. Accept one "tiny" side request and you have taught every stakeholder that the Sprint Backlog is a suggestion; the second and third requests arrive within the week, planning becomes meaningless, and velocity — the number all your forecasts depend on — turns to noise. If a change is ever truly urgent enough to override the goal, Scrum has an honest mechanism: the PO cancels the Sprint and the team replans in the open. Anything else goes through the Product Backlog.
The team. TF-6 clears review, deploys to staging, passes the DoD checks — Done. Burn: 11 → 9. Omar is back on TF-17 with real credentials; the consent screen appears for the first time. Lina pulls TF-7 (edit). At the Daily, Khaled puts the burndown on screen for the first time: remaining 9 against an ideal of about 6.5. Behind, but explainably behind — the blocker cost a day and a half, and TF-17's five points won't burn until the whole story lands. Nobody panics; it goes on the watch list for Monday.
Jira actions:
PUT /tasks/:id endpoint, stale-data handling, tests).Lesson: A burndown above the ideal line is information, not an accusation. The question it asks is "what do we change Monday?", and the team now has the weekend-proof answer: finish TF-7 fast, keep swarming TF-17.
The team. OAuth turns out to be a nest of details: redirect URIs differ between staging and local, sessions expire strangely, and the "sign in" button works on Omar's machine and nowhere else. Sara joins him after lunch. Lina's edit story progresses — endpoint done, form half-wired. Nothing reaches Done today; the burndown stays flat at 9. One flat day, clearly explained at the Daily, is life. The team notes it and moves on.
Jira actions:
Day 6 — redirect URI + session handling issues on staging; Sara pairing with Omar.Lesson: Flat burndown days happen. The discipline is narrating them honestly at the Daily so a flat line never arrives as a surprise.
The team. Khaled opens the Daily with the chart: remaining 9, ideal 3.9. Six working days of budget left in the plan, three on the clock. The team does the forecast out loud, story by story: TF-7 finishes tomorrow (likely), TF-17 finishes by Day 9 (probable, now that OAuth cooperates) — and TF-8 (delete) has not been started and realistically will not be, because every remaining hour belongs to the two bigger stories. Someone says the uncomfortable sentence: "We are not finishing everything we committed."
Now the move the whole course has been building toward. At Planning, the team explicitly marked TF-8 as the flex item — first to drop if the goal was threatened. Rania asks the only question that matters: is the Sprint Goal still met without delete? Yes — a user who can create, complete, and edit tasks is managing a basic task list; delete rounds it out but does not make or break it. Decision, taken jointly by the Developers and the PO: TF-8 returns to the Product Backlog, at the top, a strong candidate for Sprint 2. The Sprint Backlog shrinks to protect the Sprint Goal. That is not the plan failing — that is the plan adapting, which is the entire point of inspecting a burndown mid-Sprint instead of at the funeral.
Jira actions:
Day 7 — descoped from Sprint 1 by Developers + PO to protect the Sprint Goal (flex item per Planning). Candidate for Sprint 2.Lesson: Scope is the negotiable variable — never the timebox, never quality (the DoD), and never the goal while it is still achievable. Teams that cannot say "we're dropping this to protect that" end up saying nothing and missing everything.
The team. TF-7 clears review and the DoD — Done. Burn: 8 → 5. On TF-17, the happy path works end-to-end on staging: click the button, Google consent, land signed in. Remaining: edge cases (declined consent, expired session) and tests. Review prep also starts today, not Friday: Khaled sends the Review invitation to the stakeholders (including the dark-mode requester — deliberately), and Rania drafts the demo storyline around the Sprint Goal.
Jira actions:
Day 8 — happy path working on staging; edge cases + tests remain.Lesson: Review preparation is a two-day trickle, not a day-10 scramble — because the increment is already on staging, prep is a script, not a rescue.
The team. Omar finishes the edge cases; Sara reviews; tests are green; staging updated; mobile and keyboard checks pass. TF-17 → Done. Burn: 5 → 0, a day early. The afternoon is the dress rehearsal: the team walks the demo script on staging (never localhost — localhost demos are where reviews go to die), times it, and decides who drives. Khaled quietly assembles the retro data: the sprint timeline with the blocker, the scope events, and the burndown.
Jira actions:
Lesson: Finishing a day early is not slack — it is what buffer looks like when scope was adapted honestly on Day 7 instead of heroically denied until Day 10.
The team. The morning is polish and small fixes — no new work starts. The afternoon holds the two feedback events, in their fixed order: the Sprint Review (inspect the product with stakeholders — full script in the Review section below), then the Sprint Retrospective (inspect the team, privately — full script below), then Khaled clicks Complete sprint. Sprint 1 closes with 12 of 13 committed points Done, the goal met, two new backlog items from stakeholder feedback, and one improvement action for Sprint 2.
Jira actions: run the Review, Retro, and Close sections below — they are Day 10's afternoon, expanded.
Lesson: The last day of a Sprint belongs to feedback loops, not to heroic merges. If Day 10 is a crunch day, the problem happened on Day 5.
Open Reports → Burndown chart for Sprint 1. If you performed each day's actions, your chart tells this exact story — here it is as numbers, with the ideal line for comparison (ideal burns 1.3 points per day from 13):
| Day | Ideal remaining | Actual remaining | What happened |
|---|---|---|---|
| Start | 13.0 | 13 | Five stories committed, 13 points |
| Day 1 | 11.7 | 13 | Swarming TF-5; nothing Done yet — plateau, and that's fine |
| Day 2 | 10.4 | 13 | CI pipeline fight; still nothing Done |
| Day 3 | 9.1 | 11 | TF-5 Done (−2); TF-17 starts and is immediately blocked |
| Day 4 | 7.8 | 11 | Blocker day: flag on TF-17, dark-mode request deflected; flat |
| Day 5 | 6.5 | 9 | TF-6 Done (−2); first team look at the chart |
| Day 6 | 5.2 | 9 | OAuth details bite; flat again — two flat days total from one blocker |
| Day 7 | 3.9 | 8 | Scope change: TF-8 (−1) descoped to protect the goal — a notch, not a burn |
| Day 8 | 2.6 | 5 | TF-7 Done (−3); momentum back |
| Day 9 | 1.3 | 0 | TF-17 Done (−5); finished a day early |
| Day 10 | 0.0 | 0 | Review, Retro, close — velocity: 12 points |
Three reading skills to take from this chart. First, it is a staircase, not a slope — points burn only when whole stories meet the DoD, so plateaus followed by drops are the normal texture, and the drop sizes tell you your story sizes. Second, distinguish burns from scope changes: Day 7's step down is a descope, not progress — Jira renders it differently (a notch in the scope line), and an honest reader never counts it as work completed. Third, judge the sprint by the response, not the gap: this team was above the ideal line for nine days out of ten — and still landed the goal, because at each inspection point (Day 5, Day 7) it changed something rather than hoping.
| Verdict | This sprint's evidence |
|---|---|
| Healthy signs | First story Done by Day 3; plateaus explained aloud at the Daily the day they happened; scope adapted on Day 7 with the goal explicitly re-checked; zero reached before the last day |
| Troubled signs (absent here, watch for them) | Flat until Day 9 then a cliff (batch-Done, invisible risk); the line rising without a PO conversation (scope leaking in); "remaining 9" met with silence at the Daily (a chart nobody reads is decoration) |
Friday, 14:00, one hour, Sprint Goal on the first slide. Attendees: the Scrum Team plus stakeholders — Rania invited the marketing stakeholder from Day 4 on purpose: people who push scope mid-Sprint are exactly the people who should see how the Sprint-and-backlog rhythm serves them. The agenda for a two-week Sprint:
| Slot | Time | Content |
|---|---|---|
| Goal & outcome | 5 min | Rania restates the Sprint Goal, what was committed (13), what is Done (12), and — without spin — that TF-8 was descoped on Day 7 and why |
| Demo | 20 min | Developers drive the working increment on staging (script below) |
| Feedback | 15 min | Stakeholders use it, react, suggest; PO captures every item aloud |
| Backlog & what's next | 15 min | Rania shows the top of the Product Backlog, the new items just captured, and the velocity-based outlook for Sprint 2 |
| Close | 5 min | Confirm next Review date; thank the room |
Demo the goal, not the ticket list — one continuous user journey that proves "a user can manage a basic task list":
The feedback slot produces two concrete items — provided inputs for your simulation:
Feedback that is not captured as a backlog item evaporates by Monday. Create both in Jira now:
Jira actions:
As a user, I can set a priority on a task and see it as a colour — epic: Task Management, unestimated, description noting it came from the Sprint 1 Review.As a user, I must confirm before a task is permanently deleted — epic: Task Management; add a comment linking it conceptually to TF-8, which it will ship alongside.Nobody "approved" the Sprint in that room — the work was already Done by the Definition of Done, and Increments could have shipped mid-Sprint. What the Review produced is the thing no other event can: the market's reaction, converted into two ordered backlog items while the reaction was still warm. If your Reviews end with applause and no new backlog items, they were presentations, not inspections.
Stakeholders leave; the Scrum Team stays. Forty-five minutes, Khaled facilitating, format: Start – Stop – Continue — the simplest of the retro formats from Module 5, right for a team's first retrospective. Everyone writes stickies silently first (silent writing beats loud brainstorming: the quietest developer's sticky carries the same weight as the loudest voice). Here is the board your simulated team produced — use these provided inputs:
Flagging blockers earlier. Omar sat on the OAuth credentials problem for half a day before raising it — he "wanted to be sure it was really blocked". Half a day, times every future blocker, is real money.
Leaving Review prep to the end. Prep only started Day 8 because Khaled pushed; left alone it would have been a Day 10 scramble. The invitation list, demo script, and dry run should be a standing checklist that starts mid-Sprint.
Pairing on unfamiliar code. Sara + Omar on the CI pipeline (Day 2) and again on OAuth (Day 6) turned two potential multi-day rabbit holes into one-day fixes. Keep pairing as the default response to "I've never touched this before".
Now the discipline that separates useful retros from group therapy: the team dot-votes and picks ONE improvement — not three, one — and phrases it as a checkable working agreement with an owner:
Agreement: Any blocker is posted in the team channel and flagged in Jira within one hour of being suspected — "not sure it's really blocked yet" counts as blocked. Khaled checks for unflagged stuck work at every Daily.
Why this one: it attacks the sprint's biggest measured loss (a day and a half of flat burndown), it costs nothing, and it is verifiable — at the Sprint 2 retro the team can count hours-to-flag and see whether it worked. "Communicate better" would have been a wish; this is an experiment.
Jira actions: make the improvement visible where work happens — create a task Working agreement: flag blockers within 1 hour and place it at the top of the Sprint 2 backlog (or pin it to the board). Module 8's capstone will check that this action visibly influenced Sprint 2 — an improvement that lives only in retro notes does not count.
One real improvement per Sprint is 26 per year — and unlike a list of ten resolutions, one actually happens. This is Agile Principle 12 (Module 1) running at full power: the team tunes itself on the same cadence it ships. The retro's output is not the sticky wall; it is the single experiment the next Sprint will run.
The final mechanical act, and what Jira does with it:
Your Jira project now shows: a completed Sprint 1 with a sprint report (12/13 points, one honest descope), a burndown with a readable story, two Review-sourced stories in the backlog, a visible retro action, and an empty Sprint 2 shell. You have run a full Scrum cycle end to end — everything Module 8 does builds on this exact state.
Perform all ten days of the simulation in your own Jira project — every card move, flag, comment, descope, and the sprint completion. Then export the evidence:
Write half a page on the dark-mode request. A Product Owner facing a mid-Sprint stakeholder request has three real alternatives:
For each alternative, state its true cost in this specific sprint (think: the blocker already in flight, the Sprint Goal's wording, what each choice teaches stakeholders about how to get work done in future). Then defend why the backlog was right here — and describe one realistic scenario in which alternative 2, the swap, would have been the better call.
Your deliverable is the artifact set a real Scrum team would have at the end of a real Sprint — assembled into one document (plus your live Jira project) that a reviewer could audit end to end.
| Component | Points |
|---|---|
| Simulation completeness — all daily Jira actions performed and traceable (flag, comments, descope, completion) | 30 |
| Burndown reading — plateaus, notch, and staircase correctly interpreted; verdict argued from evidence | 20 |
| Review evidence — agenda, demo script, feedback captured; both new stories correctly created in the backlog | 20 |
| Retrospective output — board complete, single action checkable and visible in Jira | 15 |
| Exercise 7.2 — three alternatives costed honestly; backlog choice defended; swap scenario plausible | 10 |
| Clarity and structure of the evidence pack | 5 |
| Total | 100 |