Scrum Methodology — From Agile Foundations to Running Real Sprints
By the end of this module, you will be able to:
TF), your Sprint 1 velocity of ~12–13 points, your Definition of Done, the two review feedback items ("task priorities/colors" and "delete confirmation"), and your retrospective actionThis module is different from the previous seven. There is one big graded capstone — delivering TaskFlow Sprints 2 and 3 in Jira as the full Scrum team — and then a look beyond single-team Scrum: scaling frameworks, Scrum-with-Kanban, certifications, and interview preparation. The capstone proves that Modules 1–7 stuck; the "beyond" sections send you into the real world with honest advice rather than marketing.
In Module 7 you ran Sprint 1 with the course guiding every step. Now the training wheels come off. You will plan and simulate two more complete Sprints of TaskFlow, and every decision — the goals, the forecasts, the mid-sprint responses, the retro format — is yours to make and defend. Treat this like a brief from a real employer, because that is exactly what it rehearses.
Role: You act as the entire Scrum team — Product Owner ordering the backlog, Developers forecasting and executing, Scrum Master keeping the process honest. Where the accountabilities would disagree in real life, write down the tension and how you resolved it.
Mission: Plan and simulate two complete two-week Sprints (Sprint 2 and Sprint 3) in your existing Jira project, picking up exactly where Sprint 1 ended.
Continuity requirements — Sprint 1's outcomes are not decoration:
Ground rules: Simulated does not mean sloppy — issues transition through the board day by day, the daily log is written as-you-go (not reconstructed at the end), and every event produces an artifact.
Sprint 3 demands the same rigor as Sprint 2 — goal, evidence-based capacity, ten daily log entries, a review with feedback, a retro with an action — plus two additions:
Writing the whole daily log in one sitting at the end. It always shows: entries are too tidy, nothing goes wrong until the scripted event, and the Jira board history contradicts the log. Simulate day by day — even at ten minutes per "day", the artifacts come out authentic.
The capstone is graded out of 100. Notice where the weight sits: a quarter of the grade is in-sprint discipline — the day-by-day work that separates people who can talk about Scrum from people who can run it.
| Component | What we look for | Points |
|---|---|---|
| Backlog stewardship | Sprint 1 feedback items refined into real stories with acceptance criteria, estimated, deliberately ordered; new review items handled the same way | 15 |
| Sprint planning quality | Outcome-focused Sprint Goals; capacity derived from velocity evidence, not wishes; Collaboration epic story in Sprint 2 | 15 |
| In-sprint discipline & event artifacts | 20 authentic daily log entries; board history consistent with the log; scripted event resolved procedurally correctly; retro action visibly applied | 25 |
| Review & retro quality | Reviews inspect the increment against the goal and produce plausible feedback; retro uses a new format and yields a testable action | 15 |
| Velocity analysis & forecast | Sealed Sprint 3 prediction with reasoning; honest post-sprint comparison; complete three-sprint table | 10 |
| Release recommendation | Grounded in the actual state of the four epics and the DoD; a clear, defensible ship/don't-ship call | 10 |
| Professionalism of evidence pack | Complete, organised, labelled, readable by someone who has never seen your project | 10 |
| Total | 100 |
An excellent capstone reads like the record of a team that actually existed: velocity wobbles believably, the blocker ripples into the burndown, the Sprint 2 retro action changes something observable in Sprint 3, and the release recommendation admits what is not done. Perfection is a red flag; honesty is the rubric's spine.
Everything in this course assumed one team, one product, one backlog — and that is where Scrum shines. But products outgrow one team: TaskFlow with a million users might need web, mobile, and platform teams all touching the same product. The moment multiple teams share a product, problems appear that the Scrum Guide does not address: integration (do the increments combine into one working product?), dependencies (team A blocked on team B), and coordination (whose backlog wins?). Scaling frameworks exist to answer these. Here are the three you will hear about, described honestly.
Nexus is Scrum.org's own answer, designed to be the minimum addition that makes 3–9 teams work on one product. There is still a single Product Owner and a single Product Backlog — non-negotiable, because two backlogs means two products. A Nexus Integration Team, drawn from the Scrum teams, is accountable for the combined work integrating into one increment every Sprint. Events get scaled counterparts (Nexus Sprint Planning, a Nexus Daily Scrum focused on integration, Nexus Sprint Review, Nexus Retrospective). If you know Scrum, you can read the entire Nexus Guide in half an hour — it is deliberately thin.
SAFe targets the enterprise: hundreds or thousands of people, multiple products, budgeting cycles, compliance. Its central construct is the Agile Release Train (ART) — a "team of teams" of roughly 50–125 people that plans together in a two-day PI Planning event covering the next 8–12 weeks. SAFe adds many roles (Release Train Engineer, Product Management, System Architect, Business Owners) and several configuration layers.
The controversy, stated plainly: SAFe is the most widely adopted scaling framework in large corporations — and the most criticised. Many experienced agilists consider it too heavy, arguing it re-installs the top-down planning, fixed roles, and big-batch thinking agile was created to escape, wrapped in agile vocabulary. Defenders reply that enterprises need some structure to change at all. Both can be true. For your career: SAFe jobs are plentiful, and you should walk into one with single-team fundamentals intact rather than learning agile through SAFe.
LeSS — the name is a pun, "LeSS is more" — takes the opposite bet: scaling means removing, not adding. Created by Craig Larman and Bas Vodde, LeSS is essentially the Scrum Guide applied to 2–8 teams with almost nothing added: one Product Owner, one Product Backlog, one Sprint for all teams, one integrated increment. Coordination happens between teams directly ("just talk"), not through new roles or layers. LeSS is intellectually elegant and organisationally demanding — it usually requires restructuring the organisation itself, which is why fewer companies adopt it than SAFe.
| Nexus | SAFe | LeSS | |
|---|---|---|---|
| Teams supported | 3–9 teams, one product | 50–125 people per ART; whole enterprises via portfolios | 2–8 teams (LeSS Huge: more, via requirement areas) |
| Added roles | Nexus Integration Team | Many: RTE, Product Management, System Architect, Business Owners | None (LeSS Huge adds Area Product Owners) |
| Added events | Nexus-level planning, daily, review, retro | PI Planning, ART syncs, System Demo, Inspect & Adapt | Slight tweaks: shared planning part 1, overall retro |
| Weight | Light — a thin layer on Scrum | Heavy — layers, roles, its own certification ecosystem | Minimal — deliberately less process, not more |
Every scaling framework assumes the teams inside it already run excellent single-team Scrum. Scaling a broken process gives you a bigger broken process — dysfunction multiplied by the number of teams. If an employer drops you into a Nexus or an ART, the skills that make you valuable there are the ones you practised here: a clean backlog, honest forecasting, a real Definition of Done, and events that actually inspect and adapt. Learn to scale after the fundamentals are boring to you.
Module 1 presented Scrum and Kanban as alternatives. In practice, mature teams often run Kanban's flow practices inside Scrum — the Sprint, roles, and events stay, and the team adds flow optimisation on top. This is common enough that Scrum.org publishes an official Kanban Guide for Scrum Teams (see Resources) describing exactly this combination. The three additions that matter most:
Cap how many items may sit in "In Progress" on the sprint board (e.g., max 3). Forces the team to finish before starting — the cure for ten stories all 80% done on day 9. "Stop starting, start finishing."
How long an item takes from work starting to done. If average cycle time is 2 days, a story picked up on day 9 of a 10-day sprint is a visible risk — no burndown squinting required. Jira tracks this in its control chart.
How many items the team finishes per unit of time (e.g., 5 items/week). Velocity weighs items by size; throughput just counts them. Together they make forecasting more robust — especially when estimates are noisy.
The clearest signal is lots of unplanned work. Imagine TaskFlow is live and your team spends 40% of each sprint on urgent bugs and support escalations that cannot wait two weeks. Pure Scrum handles this awkwardly — unplanned work either torpedoes the forecast or queues painfully in the backlog. Flow metrics help: WIP limits keep interruptions from swamping planned work, cycle time tells you how fast you really turn around an urgent item, and throughput gives stakeholders an honest service-level expectation ("urgent bugs are typically resolved within 3 days"). Other signals: work that resists estimation, or a burndown that routinely cliff-drops on the last day because everything finishes at once.
The Kanban Guide for Scrum Teams is explicit: nothing in Scrum is removed. The Sprint Goal, events, accountabilities, and Definition of Done all remain. Kanban practices are an overlay that improves transparency of flow — one more example of the Module 2 lesson that Scrum is a minimal framework designed to have practices added inside it.
Scrum certifications are a genuine hiring signal — many job postings filter on them — but the market is confusing because two rival bodies (Scrum.org and Scrum Alliance) offer similar-sounding credentials. The honest comparison:
PSM I is the strongest value for someone finishing this course: a fraction of a CSM's cost, no travel or scheduling, never expires, and its difficulty makes it a more credible signal, not less. The best preparation is free: the Scrum Guide itself plus the scrum.org open assessments. You do not need a paid prep course; you need repetitions.
Whether you interview as a developer, Scrum Master, or product person, Scrum questions will come up — and interviewers listen for understanding, not recitation. The ten questions below cover most of what gets asked; each sketch shows the shape of a strong answer. Make it yours by substituting evidence from your own TaskFlow sprints.
Notice the pattern across all ten sketches: rule → reason → real example. State what Scrum says, explain the mechanism behind it, then ground it in a sprint you actually ran. Candidates who can only do the first step sound like flashcards; you can now do all three.
Eight modules ago, TaskFlow was a wish list and "agile" was a buzzword. Look at what you can do now:
Scrum says nothing about how to build quality software inside the Sprint. Extreme Programming does: test-driven development, pair programming, refactoring, continuous integration. The strongest Scrum teams are quietly XP teams inside their Sprints — start with TDD and your Definition of Done grows teeth.
A "done" increment every Sprint begs the question: why not ship every Sprint — or every day? Continuous integration and delivery pipelines close the gap between increment and production, and pair naturally with everything you learned here.
DevOps Lab courseIf ordering the TaskFlow backlog was the part you loved — deciding what to build and why — the product path awaits: discovery, user research, outcome metrics, roadmapping. The PSPO track is the certification on-ramp; Inspired (Marty Cagan) is the reading on-ramp.
You started this course with a wish list on a whiteboard and you are finishing it with three simulated Sprints of a real product in Jira, a velocity history, a Definition of Done you wrote yourself, and a release recommendation with your name on it. That is not "learned about Scrum" — that is ran Scrum. Whatever you build next, build it in small slices, show it to real people early, and change course when they teach you something. That habit is the whole course in one sentence.
Back to Course Home