Scrum Methodology — From Agile Foundations to Running Real Sprints
By the end of this module, you will be able to:
You will notice this course is called "Scrum Methodology" — because that is what everyone searches for — but the Scrum Guide is careful to call Scrum a framework. The difference matters. A methodology tells you exactly what to do: which documents to write, which diagrams to draw, which steps to follow (think RUP from Module 1, with its 30+ roles). A framework is deliberately incomplete: Scrum defines a minimal structure — three accountabilities, five events, three artifacts — and leaves everything else (how you write requirements, how you test, how you deploy) for the team to fill in. The Scrum Guide even says it: Scrum is "purposefully incomplete" and acts as a container within which you can employ whatever practices work. That is why Scrum fits a two-person startup and a hundred-team bank — and also why "we do Scrum" tells you surprisingly little about how a team actually works.
Strip away the ceremonies, and Scrum rests on a single idea: empirical process control. Empiricism asserts that knowledge comes from experience, and that decisions should be made based on what is observed — not on what was predicted. Instead of planning the whole product up front and hoping the plan survives, an empirical process works in short cycles: do a small amount of work, look honestly at the result, adjust course, repeat.
This is not a software invention. Empirical control is how chemical plants handle processes too complex to model precisely: measure constantly, correct continuously. Ken Schwaber, one of Scrum's creators, borrowed the idea directly from industrial process control theory after a DuPont process engineer told him that his "defined" software processes were being applied to a problem that was anything but defined. Building a new product involves unknown requirements, unknown technology risks, and people — the very definition of a complex problem, where more is unknown than known.
Empiricism only works when three things are in place. The Scrum Guide calls them the pillars of Scrum, and every Scrum event you will meet in Module 5 exists to serve at least one of them:
The work and its state must be visible to those doing the work and those receiving it — and visible truthfully. A backlog nobody updates, or a "done" that secretly means "done except testing", destroys transparency.
Team example: the TaskFlow team keeps a single board everyone can see; when the login feature hits a blocker, the card says so the same day — not at the end of the month in a status report.
The artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect undesirable variances early. Inspection without transparency is misleading; inspection that never happens makes transparency pointless.
Team example: every day the Developers inspect progress toward the Sprint Goal in the Daily Scrum; every two weeks stakeholders inspect the working product in the Sprint Review — clicking it, not watching slides about it.
When inspection reveals that something is off-target, the process or the product must be adjusted as soon as possible. Inspection that never leads to change is theatre — the most common failure mode of "mechanical Scrum".
Team example: the Sprint Review reveals users find TaskFlow's reminders confusing; the Product Owner reorders the backlog that same week to fix the reminder flow before building the calendar view.
Transparency enables inspection; inspection enables adaptation. Break any link and the others collapse: if the data is dishonest, inspecting it produces wrong conclusions; if nobody inspects, there is nothing to adapt to; if nothing ever changes, people stop bothering to be transparent. When you diagnose a struggling Scrum team, start by asking which pillar broke first.
The waterfall model from Module 1 is the textbook example of defined process control: it assumes that if you understand the process well enough, you can specify every step in advance and get a predictable output — the way an assembly line stamps out identical cars. That assumption is excellent for repeatable manufacturing and terrible for product development, where every product is being built for the first time.
| Defined process control | Empirical process control | |
|---|---|---|
| Core assumption | The work is well understood and repeatable | More is unknown than known; surprises are normal |
| Planning | Complete plan up front; success = following it | Just-enough plan; success = valuable outcome |
| Change | A deviation to be controlled and minimised | Information to be used and welcomed |
| Feedback | At phase gates, months apart | Continuous — daily and per Sprint |
| Risk | Accumulates silently until integration/testing | Surfaced early, every cycle |
| Fits best | Manufacturing, construction, regulated repetition | New product development — like TaskFlow |
Empirical control means admitting, out loud and often, that the plan was wrong. Organisations used to defined processes often experience Scrum's transparency as embarrassment ("why is the burndown flat?") and respond by hiding problems — which quietly turns Scrum back into waterfall with daily meetings. Protecting honest transparency is one of the Scrum Master's hardest jobs, as you will see in Module 3.
Empiricism describes how the process works; the Scrum values describe how the people must behave for it to work. Added to the Scrum Guide in 2016, the five values are not decoration — each one directly protects the three pillars. A team that lacks courage will not be transparent about bad news; a team that lacks openness cannot inspect honestly. For each value below, note the real behaviour and the anti-pattern that fakes it.
The team commits to achieving its goals and to supporting each other — commitment to the Sprint Goal, not a blood oath to finish every ticket.
In practice: two days before Sprint end, a developer finishes early and picks up a teammate's struggling task instead of pulling new work — the goal matters more than individual throughput.
Anti-pattern: management treats the Sprint forecast as a contractual promise, so the team pads estimates and commits to less than it can do — commitment inverted into self-protection.
The team's primary focus is the work of the Sprint. One product, one goal at a time — Scrum's answer to the multitasking tax.
In practice: when a stakeholder asks for "a quick favour" mid-Sprint, the team routes it to the Product Owner for the next Sprint instead of silently absorbing it.
Anti-pattern: every developer is "50% allocated" to two other projects; the Daily Scrum becomes a scheduling negotiation and the Sprint Goal belongs to no one.
The team and its stakeholders are open about the work and the challenges — the behavioural fuel of the Transparency pillar.
In practice: in the Daily Scrum a developer says "I estimated this at one day; it has taken three and I don't understand the legacy code" — and gets help, not blame.
Anti-pattern: the "watermelon status report" — green on the outside, red on the inside. Everything is "on track" until the week before release.
Team members respect each other as capable, independent professionals — across specialties, seniority levels, and disagreements.
In practice: the senior architect lets the junior developer's simpler design go ahead after the team prefers it — and helps make it succeed rather than waiting for it to fail.
Anti-pattern: testers treated as second-class "checkers" who receive work thrown over a wall; designers excluded from planning "because it's technical".
The team has the courage to do the right thing and to work on tough problems — including the courage to say no, to surface bad news, and to change course.
In practice: mid-Sprint the team discovers the chosen sync approach cannot work offline; they tell the Product Owner immediately and re-plan, rather than shipping something they know is broken.
Anti-pattern: everyone privately knows the release date is impossible, but nobody says so in the meeting where it could still be fixed — courage deferred until the retrospective post-mortem.
Because the mechanics are easy to fake. Any team can hold a fifteen-minute meeting every morning; only a team living these values will say true things in it. When the values live, the pillars of transparency, inspection, and adaptation "come to life, building trust" — the Scrum Guide's own words. When they don't, you get all of Scrum's meetings and none of its benefits.
Here is the entire framework as a single loop. Everything in the rest of this course — roles in Module 3, artifacts in Module 4, events in Module 5 — is a zoom-in on one box of this picture. Read it top to bottom, then notice the arrow that closes the loop: Scrum has no "end phase". Each Sprint ends where the next begins.
Developers build, test, and integrate the work — the loop above repeats every working day
Every box serves the empiricism you learned above. The three artifacts (Product Backlog, Sprint Backlog, Increment) provide transparency. Every event is a formal opportunity for inspection: the Daily Scrum inspects Sprint progress, the Review inspects the product, the Retrospective inspects the process. And every inspection feeds an adaptation: the day's plan, the Product Backlog, the team's way of working. You will use this exact mapping in Exercise 2.1.
Scrum has exactly one authoritative definition: the Scrum Guide, written and maintained by Scrum's co-creators, Ken Schwaber and Jeff Sutherland. The 2020 edition is 13 pages. Read it this week — it takes about 30 minutes, and every certification exam and every job interview question about Scrum traces back to it. This section gives you the map before you read the territory.
If you learned Scrum from older material — or your future employer did — these are the differences you must know:
| Topic | Scrum Guide 2017 | Scrum Guide 2020 |
|---|---|---|
| Product Goal | Did not exist | A single Product Goal is introduced as the long-term objective the Product Backlog serves — each Sprint should bring the product closer to it |
| Roles | Three "roles" | Three "accountabilities" (Product Owner, Scrum Master, Developers) — a deliberate word change to stress that these are sets of responsibilities, not job titles or boxes on an org chart |
| Team structure | Development Team inside the Scrum Team | One unified Scrum Team, no sub-teams — removing the "us vs. them" line between the PO and "the devs" |
| Self-organisation | Teams are "self-organising" (choose how) | Teams are "self-managing" — they choose who does what, when, and how: a broader grant of authority |
| Prescriptiveness | Suggested the three Daily Scrum questions, listed Review agenda items | Softer and shorter (19 → 13 pages): the three questions are gone, teams choose their own structure for events; each artifact gets an explicit "commitment" (Product Goal, Sprint Goal, Definition of Done) |
| Audience | Software-flavoured language | Generalised language — Scrum for any complex product work |
From here on we follow 2020 wording: accountabilities (though "roles" survives in everyday speech and in our Module 3 title), self-managing, Developers (not "Development Team"). If a source tells you the Daily Scrum requires three fixed questions, it is quoting a pre-2020 guide.
Four sentences from the Guide are worth carrying in your head verbatim (lightly abridged here):
Scrum: "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems."
The Sprint: "the heartbeat of Scrum, where ideas are turned into value" — fixed length, one month or less, a new one starts immediately after the last.
The Increment: "a concrete stepping stone toward the Product Goal… In order to provide value, the Increment must be usable."
On completeness: Scrum is "purposefully incomplete… Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions."
Theory becomes yours when you instantiate it. In Module 1 you met TaskFlow — the task manager web app with its unsorted wish list (tasks, projects, due dates, sharing, comments, mobile, Google sign-in, dark mode, stats). You argued for a delivery approach in Exercise 1.1. Now you will take the generic Scrum flow diagram above and fill in every box with TaskFlow specifics.
Draw (or write as a table) the full Scrum flow for TaskFlow's first Sprint. For every element of the flow, answer concretely:
Here is the map started for you. The filled rows show the expected depth; the (you complete) rows are yours. Do not copy the filled rows blindly — disagree with them if you can defend it.
| Scrum element | Instantiated for TaskFlow | Pillar(s) served |
|---|---|---|
| Product Owner | Dana, the product founder: she interviews target users (students, freelancers) weekly, owns the vision, and has the authority to say "not yet" to the dark-mode fans. | Transparency — one visible, ordered backlog with one owner |
| Product Backlog (top of) | 1. Create/edit/complete/delete tasks — without this there is no product. 2. Organise tasks into lists — the minimum structure users expect. 3. (you complete items 3–5 with justification) | Transparency |
| Sprint Goal (Sprint 1, 2 weeks) | "A visitor can manage a simple personal task list end-to-end" — note it is an outcome, not a list of tickets. | Focus for the team; a transparent target for inspection |
| Daily Scrum | (you complete: what would the TaskFlow Developers inspect each day, and what might a real adaptation look like mid-Sprint?) | (you complete) |
| Increment after Sprint 1 | (you complete: one paragraph — what exactly can a user do at the first Review? Be honest about what is NOT there yet: no sharing, no reminders, no Google sign-in.) | (you complete) |
| Sprint Review | (you complete: who attends, what do they inspect, what backlog adaptation might result?) | (you complete) |
| Sprint Retrospective | (you complete: name one plausible process problem after Sprint 1 and the improvement the team commits to) | (you complete) |
Your completed TaskFlow map is part of this module's project below, and it becomes the seed of the real Product Backlog you will build in Jira in Module 4. Extend the same document you started in Module 1.
You will produce a short "field guide" — the document you would hand a colleague who keeps saying "we do standups, so we're agile". It has three parts:
| Component | Points |
|---|---|
| Pillars in practice (three concrete, diagnostic stories) | 30 |
| Values self-assessment (honest, specific, well-argued) | 25 |
| TaskFlow Scrum map (Exercise 2.1 completed with sound reasoning) | 35 |
| Clarity and structure of writing | 10 |
| Total | 100 |