Scrum Methodology — From Agile Foundations to Running Real Sprints
By the end of this module, you will be able to:
Scrum is not a standalone invention — it is the most popular framework inside the agile movement. If you learn the ceremonies of Scrum without understanding the agile values underneath them, you end up doing "mechanical Scrum": standing up every morning without knowing why. This module gives you the why; the rest of the course gives you the how.
For most of the 20th century, software was built the way bridges are built: plan everything, then execute the plan. This approach is called the waterfall model because work flows downward through fixed phases, and — like water — it is not supposed to flow back up.
Waterfall is not "wrong" — it works well when requirements are stable and fully known up front (think firmware for a medical device with fixed regulatory specs). Software products for real users are rarely like that:
Studies of large waterfall projects (e.g., the Standish Group CHAOS reports) repeatedly found that roughly half of the features specified up front were never or rarely used. Months of work spent building things nobody needed — this is the waste agile set out to eliminate.
Between waterfall and agile sits the Rational Unified Process (RUP), developed at Rational Software (later IBM) in the 1990s. RUP was a major step forward: it replaced one long waterfall with a series of iterations across four phases (Inception, Elaboration, Construction, Transition), attacked the riskiest work first, and produced executable software early.
So why did the industry keep moving? RUP is a process framework — comprehensive, heavily documented, with dozens of roles, artifacts, and workflows to tailor. Many organisations found tailoring it correctly harder than the project itself. Agile methods kept RUP's iterative heart but stripped the process down to the minimum that works.
| Waterfall | RUP | Agile (Scrum) | |
|---|---|---|---|
| Delivery | Once, at the end | Iterative, milestone-driven | Every Sprint (≤ 1 month) |
| Requirements | Fixed up front | Use cases, refined per phase | Living backlog, reordered continuously |
| Change | Resisted (change control) | Managed per iteration | Welcomed, even late |
| Documentation | Heavy | Heavy but tailorable | Just enough |
| Roles | Many, specialised | 30+ defined roles | 3 accountabilities |
In February 2001, seventeen software practitioners — including the creators of Scrum, XP, and Crystal — met at the Snowbird ski resort in Utah to find common ground between their "lightweight" methods. The result was the Manifesto for Agile Software Development: 68 words that changed the industry.
over processes and tools
The best process cannot save a team that does not talk. A daily five-minute conversation beats a week of ticket ping-pong.
over comprehensive documentation
The measure of progress is software a user can actually run — not a 200-page specification describing it.
over contract negotiation
Work with the customer continuously instead of hiding behind a signed scope document when reality changes.
over following a plan
A plan is a snapshot of what we knew yesterday. When we learn something new, changing course is a feature, not a failure.
The manifesto says: "while there is value in the items on the right, we value the items on the left more." Agile does not mean "no documentation, no plans, no contracts" — it means when the two sides conflict, the left side wins.
Behind the 4 values sit 12 principles. You do not need to memorise their exact wording — you need to recognise the behaviour each one demands. Here they are, grouped by theme:
"Agile" is the value system; frameworks are concrete ways to live it. The three you will meet most often:
A lightweight framework built on fixed-length iterations called Sprints. A small team with three accountabilities (Product Owner, Scrum Master, Developers) delivers a usable product increment every Sprint, inspecting and adapting through five structured events. Scrum dominates the industry: most agile teams worldwide report using Scrum or a Scrum hybrid.
Born in Toyota's factories, Kanban visualises work on a board, limits work in progress (WIP), and optimises continuous flow. There are no sprints and no prescribed roles — work is pulled item by item as capacity frees up. Ideal for support/operations teams with unpredictable, interrupt-driven work.
XP prescribes technical practices the other frameworks stay silent about: test-driven development (TDD), pair programming, continuous integration, refactoring, collective code ownership. Many strong Scrum teams quietly adopt XP practices inside their Sprints — the frameworks combine well.
| Scrum | Kanban | XP | |
|---|---|---|---|
| Cadence | Fixed Sprints (1–4 weeks) | Continuous flow | 1–2 week iterations |
| Roles | PO, Scrum Master, Developers | None prescribed | Coach, customer, programmers |
| Key metric | Velocity / Sprint Goal | Lead time, WIP | Tests passing, release frequency |
| Change during cycle | Not inside a Sprint (scope protected) | Any time | Between iterations |
| Prescribes engineering practices? | No | No | Yes — TDD, pairing, CI |
| Best when | Building a product feature by feature | Interrupt-driven work | Quality-critical codebases |
Throughout this course you will act as the Scrum team behind TaskFlow — a task manager web app. By Module 8 you will have written its product backlog, estimated it, planned its sprints, and simulated delivering it in Jira. Here is the product brief you will keep coming back to:
Vision: A simple, fast web app where individuals and small teams organise their daily work.
Target users: Students, freelancers, and small teams (2–10 people).
Wish list from stakeholders (unsorted, incomplete — on purpose!):
Write a one-page argument (bullet points welcome) answering:
Exercise 1.1 becomes the input for Module 2 (mapping TaskFlow onto the Scrum flow) and Module 4 (building the real backlog in Jira). Save your work in a document you can extend.
| Component | Points |
|---|---|
| Waterfall post-mortem depth & accuracy | 30 |
| Manifesto mapping (values correctly interpreted) | 30 |
| TaskFlow analysis & framework recommendation | 30 |
| Clarity and structure of writing | 10 |
| Total | 100 |