Scrum Methodology — From Agile Foundations to Running Real Sprints
By the end of this module, you will be able to:
Remember from Module 2: the Scrum Guide 2020 deliberately replaced "roles" with accountabilities. Product Owner, Scrum Master, and Developers are not positions on an org chart or lines on a business card — they are three sets of responsibilities that must be held by someone for empiricism to work. One person can hold an accountability alongside their job title; what cannot happen is an accountability held by no one, or smeared across a committee. Keep that lens on for the whole module.
Scrum's unit of delivery is a single Scrum Team: one Product Owner, one Scrum Master, and Developers — typically 10 or fewer people in total. Within it there are no sub-teams and no hierarchy: no "front-end squad" reporting to a "back-end lead", no PO out-ranking the Developers. It is, in the Guide's words, "a cohesive unit of professionals focused on one objective at a time, the Product Goal."
Three adjectives define its shape, and each one is load-bearing:
The size limit is not aesthetic — it is arithmetic. Every pair of people who must stay in sync is a communication path, and the number of paths grows quadratically with team size: for n people there are n(n−1)/2 possible pairs. Each path is a place where information can lag, distort, or die.
| Team size (n) | Communication paths — n(n−1)/2 | What it feels like |
|---|---|---|
| 5 people | 10 paths | Everyone knows everything; a Daily Scrum takes 10 minutes |
| 10 people | 45 paths | The practical ceiling — alignment already takes real effort |
| 20 people | 190 paths | Nobody has the full picture; sub-groups and status meetings emerge on their own |
Doubling a team from 5 to 10 does not double coordination cost — it multiplies it by 4.5. This is also the intuition behind Brooks's Law ("adding manpower to a late software project makes it later") and Amazon's "two-pizza team" rule. Scrum simply builds the limit into the framework.
The sections below examine each accountability in isolation, but never forget they live in one team with one goal. The 2020 Guide erased the internal border between the Product Owner and a separate "Development Team" precisely because teams kept turning that border into a wall: PO writes tickets, devs complain about tickets. The whole Scrum Team is accountable, together, for creating a valuable, useful Increment every Sprint.
The Product Owner (PO) is accountable for maximising the value of the product resulting from the Scrum Team's work. Everything else about the accountability serves that sentence. The PO's chief instrument is the Product Backlog: the PO is accountable for developing and explicitly communicating the Product Goal, creating and clearly communicating backlog items, ordering them, and ensuring the backlog is transparent and understood.
Two structural rules make the accountability work, and both are frequently violated in the wild:
The accountability sounds abstract; the work is not. A typical week for Dana, our TaskFlow PO from Exercise 2.1:
The proxy PO. A business analyst is named "PO" but every real decision is made by a director the team never meets. Decisions take weeks, answers are second-hand, and the backlog reflects the proxy's guesses about the director's guesses about users. Symptom: "let me check and get back to you" as the answer to every question.
The absent PO. The PO holds the title alongside two other jobs, appears at Sprint Planning, then vanishes. Developers invent answers to requirement questions mid-Sprint, and the Review becomes the PO's first look at their own product. Empiricism cannot run on a two-week feedback loop to the value decider.
PO-by-committee. Three department heads "jointly own" the backlog. Each protects their items, ordering becomes horse-trading, and the team optimises for keeping three sponsors calm instead of maximising product value. If multiple people can veto ordering, nobody owns value.
The Scrum Master (SM) is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. The classic label is servant-leader; the 2020 Guide rephrased it as "true leaders who serve" — leadership measured not by authority over people but by how much better the team works because of them.
A common rookie mistake is to picture the SM as "the person who runs the meetings". Facilitation is a sliver of the job. The SM's real work is making the system around the team healthy: causing the removal of impediments, coaching self-management, protecting focus, and keeping the empiricism of Module 2 honest — real transparency, real inspection, real adaptation.
The Scrum Guide defines the accountability as service in three directions at once:
Coaching self-management and cross-functionality; helping the team focus on creating high-value Increments that meet the Definition of Done; causing the removal of impediments (note: causing — teaching the team to remove their own is better than heroically removing them all); ensuring events happen, stay within their timeboxes, and remain positive and productive.
Helping find techniques for effective Product Goal definition and backlog management; helping the team understand the need for clear, concise backlog items; helping establish empirical product planning; facilitating stakeholder collaboration when the PO is drowning in competing voices — coaching Dana, never replacing her.
Leading, training, and coaching the organisation in its Scrum adoption; advising Scrum implementations; helping employees and stakeholders understand an empirical approach; removing barriers between stakeholders and Scrum Teams — e.g., persuading the sales VP to bring feature requests to the Sprint Review instead of ambushing Developers.
The most damaging misreading of the SM accountability is treating it as "project manager, renamed". They differ on almost every axis that matters:
| Traditional Project Manager | Scrum Master | |
|---|---|---|
| Accountable for | Delivering the project on time, scope, budget | The team's effectiveness and healthy Scrum — the team owns delivery |
| Authority | Positional — assigns work, approves changes | None over people — influence through coaching and facilitation |
| Assigns tasks? | Yes — builds and maintains the work plan | Never — Developers self-manage the Sprint Backlog |
| Scope & priorities | Manages scope via change control | Not their job at all — that is the Product Owner's accountability |
| Status reporting | Compiles and sends status reports upward | Makes the team's artifacts so transparent that reports become unnecessary |
| When problems hit | Escalates, re-plans, reallocates people | Asks "what is the impediment, and who is best placed to remove it?" |
| Success looks like | The plan was met | The team improves Sprint over Sprint — and barely needs them |
The scrum-mom. Books every meeting, resolves every conflict, reminds everyone of everything — a full-service parent. The team never learns to self-manage because it never has to; when the SM takes a holiday, the process collapses, which the SM then reads as proof of their indispensability.
The ticket admin. Spends the day updating the tool, moving cards, and grooming dashboards on the team's behalf. The board stops reflecting reality (transparency broken — pillar one!) because the people doing the work are no longer the people updating it.
The status reporter. Attends the Daily Scrum to collect progress and relay it to management. The Daily quietly becomes a reporting ceremony, Developers start performing safety instead of inspecting progress, and openness — the value that feeds transparency — dies first.
In Scrum, Developers are all the people on the Scrum Team committed to creating any aspect of a usable Increment each Sprint — regardless of specialty. The word does not mean "programmers". On the TaskFlow team, the coder writing the API, the tester designing the regression suite, the UX designer prototyping the calendar view, and the data specialist building the stats dashboard are all, in Scrum terms, Developers. What unites them is not a skill but a commitment: together they turn backlog items into a Done Increment.
The Scrum Guide gives Developers four explicit accountabilities:
The plan for the Sprint belongs to the people who will execute it. Developers select how much work fits, break it down, and design the plan — nobody hands them a schedule.
Developers are accountable for every Increment meeting the Definition of Done — the shared quality bar (tested, integrated, documented…) you will formalise in Module 4. "It works on my machine" is not Done.
Each Daily Scrum, Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog — re-ordering, re-slicing, swapping tasks. The plan made at Sprint Planning is a starting point, not a contract.
Accountability is mutual, as professionals — not upward to a manager. If tests are being skipped to look fast, it is the Developers' job to call it, long before any SM or PO notices.
Self-management does not erase expertise — Lina is still the strongest tester in the room. What it erases is the queue: work does not wait in a "ready for QA" pile until the QA department finds time. The team swarms on the Sprint Goal, and specialists teach as they go, gradually growing "T-shaped" people: deep in one skill, capable in several. If only Omar can touch the backend, the team's bus factor is 1 — and every Sprint hostage to his calendar.
Traditional project governance answers "who does what?" with a RACI matrix: for every decision or deliverable, name who is Responsible, Accountable, Consulted, and Informed. RACI assumes the important decisions can be enumerated up front and assigned to individuals — a very defined-process assumption, as you can now recognise from Module 2. In waterfall and RUP projects, RACI charts routinely ran to dozens of rows.
Scrum takes a different bet: for complex work, most decisions cannot be foreseen, so instead of assigning each one, Scrum assigns three broad accountabilities and lets the team collectively own everything inside them. Compare how the same four decisions land in each world:
| Decision | Waterfall / RUP (RACI world) | Scrum |
|---|---|---|
| What to build | Business analyst drafts requirements (R); steering committee approves (A); architects consulted (C); developers informed (I) | Product Owner orders the Product Backlog — one person, informed by stakeholders and the team, final on ordering |
| How to build it | Architect / technical lead decides the design (A); developers execute it (R) | Developers decide collectively — the best architectures emerge from self-managing teams (agile principle 11) |
| Who does which task | Project manager assigns tasks in the work plan (A/R per row) | Developers pull work themselves, task by task, adapting daily — nobody assigns |
| When it ships | PM's milestone plan (A), change board approval for date moves | Product Owner decides when to release; the Definition of Done (owned by the whole team) decides when it can be released — every Sprint produces a releasable Increment |
Notice what the Scrum column does not contain: the Scrum Master. The SM shapes how well these decisions get made — never what gets decided. If you find a team where the SM picks the architecture or the release date, you have found a project manager wearing a Scrum Master badge.
Self-management works because the boundaries are crisp even though the interior is free: the PO cannot dictate how, the Developers cannot reorder the backlog, and nobody can extend the timebox. Inside those boundaries, the team is trusted completely. That trade — hard edges, free interior — is what lets ten people move fast without a 40-row RACI chart.
Time to staff the product. Below is the roster of six colleagues available to build TaskFlow. Your job: shape them into a legitimate Scrum Team and then defend your casting under fire from four realistic scenarios.
| Name | Skills & background |
|---|---|
| Sara | Front-end developer — React, CSS, accessibility; 4 years' experience; quiet in meetings, superb in code review |
| Omar | Back-end developer — APIs, databases, auth; the fastest coder on the roster; impatient with meetings |
| Lina | QA engineer — test design, automation; famously good at asking "what happens if…?"; has facilitated team workshops before |
| Khaled | UX designer — research, prototyping; runs monthly usability sessions with real users; diplomatic, listens more than he talks |
| Rana | Data specialist — analytics, dashboards, SQL; new to the company; keen to learn the product domain |
| Yousef | Full-stack developer — solid across the stack; 6 years using task-manager tools daily as a freelancer before joining; knows the target users' pains personally; comfortable presenting to stakeholders |
Part A — Casting.
Part B — Scenario questions. Answer each in 3–5 sentences, citing the accountability that applies:
Reasonable people can defend different PO and SM picks from this roster — the grading (below) rewards the quality of the justification, not matching a hidden answer key. What is not defensible: a PO committee, an SM who assigns tasks, or leaving an accountability unfilled. Keep your answers — this team staffs your Jira project in Module 4.
You will assemble a playbook a real organisation could use when staffing and defending a Scrum Team. It has three parts:
| Component | Points |
|---|---|
| Product Owner job ad (accurate, complete, realistic) | 25 |
| Scenario analysis (five scenarios, correctly citing accountabilities) | 35 |
| TaskFlow casting — Exercise 3.1 (well-argued casting + scenario answers) | 30 |
| Clarity and structure of writing | 10 |
| Total | 100 |