-
Notifications
You must be signed in to change notification settings - Fork 134
SE 14 Agile and Scrum
Part of the Software Engineering Principles series
In 2001, seventeen software practitioners published the Agile Manifesto, a reaction to the failures of heavyweight, document-driven methodologies. It declared four value statements:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The items on the right have value. The items on the left are valued more.
Twelve principles follow from these values. The most important:
- Deliver working software frequently — weeks, not months
- Welcome changing requirements, even late in development
- Business people and developers must work together daily
- Working software is the primary measure of progress
- Continuous attention to technical excellence and good design
- Simplicity — maximising the work not done — is essential
Traditional ("waterfall") projects often failed because:
- Requirements were fully specified upfront, then changed during development
- Working software was not seen until near the end
- Feedback came too late to influence the product
- Large, infrequent releases meant large, risky deployments
Agile addresses these by delivering in small, frequent increments and incorporating feedback continuously.
Scrum is the most widely used Agile framework. It structures work into fixed-length Sprints (typically 2 weeks) and provides a minimal set of roles, events, and artefacts.
Responsible for maximising the value of the product. The Product Owner:
- Maintains and prioritises the Product Backlog
- Defines acceptance criteria for backlog items
- Is the single authoritative source of requirements for the team
- Makes trade-off decisions about scope
One person — not a committee.
Serves the team and organisation by:
- Ensuring the team understands and practises Scrum
- Removing impediments that block the team's progress
- Facilitating Scrum events
- Protecting the team from external interruptions
The Scrum Master is not a project manager and does not assign work.
Cross-functional professionals who do the work of delivering a potentially releasable increment each Sprint. The team:
- Is self-organising — decides how to do the work, not just what
- Typically 3–9 people
- Is collectively accountable for delivering the Sprint Goal
An ordered list of everything that might be needed in the product — features, bug fixes, technical improvements. The Product Owner owns and maintains it.
Items higher in the backlog are more refined (smaller, clearer) and have higher priority. Items lower down are larger and less well understood.
The set of Product Backlog items selected for the current Sprint, plus a plan for delivering them. The team owns the Sprint Backlog.
The sum of all completed Product Backlog items at the end of a Sprint. The increment must be Done — meeting the team's Definition of Done — and potentially releasable.
A shared understanding of what "done" means for any backlog item. A typical DoD:
- Code reviewed and approved
- Unit tests written and passing
- No regression in existing tests
- Deployed to test environment
- Acceptance criteria verified by Product Owner
- No outstanding known defects
The DoD creates transparency and prevents "99% done" from being a permanent state.
A time-box of consistent length (typically 2 weeks) during which a Done, usable increment is created. Sprints have a fixed start and end date. Requirements do not change during a Sprint — only the team selects how to deliver the committed work.
Held at the start of each Sprint. The team:
- Understands the Sprint Goal — what will be achieved this Sprint
- Selects backlog items they forecast they can complete
- Breaks selected items into tasks
- Produces the Sprint Backlog
Time-box: up to 8 hours for a 4-week Sprint (proportionally less for shorter Sprints).
A 15-minute daily event for the Development Team. Each member typically addresses:
- What did I do yesterday that helped achieve the Sprint Goal?
- What will I do today?
- Do I see any impediment?
The purpose is coordination, not status reporting to management.
Held at the end of the Sprint. The team demonstrates the increment to stakeholders, who provide feedback that informs the Product Backlog.
This is not a demo of what the team tried to build — it is a demonstration of working software that meets the Definition of Done.
The team reflects on itself — process, tools, relationships — and identifies improvements to implement in the next Sprint.
Three questions:
- What went well?
- What did not go well?
- What will we do differently next Sprint?
The retrospective is where Agile's commitment to continuous improvement is practised concretely.
A user story is a lightweight format for expressing a requirement from the perspective of a user:
As a [role], I want to [capability] so that [benefit].
As a pharmacist,
I want to scan a medicine barcode to look it up,
So that I can process dispensing quickly without typing errors.
Each story has acceptance criteria — specific, testable conditions that must be satisfied for the story to be considered done:
Given a valid barcode is scanned,
When I look up the medicine,
Then the correct medicine name, current stock level, and expiry date are shown.
Given an unknown barcode is scanned,
When I look up the medicine,
Then an error message "Medicine not found" is displayed and no dispensing occurs.
Good user stories are:
| Letter | Property |
|---|---|
| I | Independent — can be worked on without depending on other stories |
| N | Negotiable — details are discussed, not dictated |
| V | Valuable — delivers value to a user or stakeholder |
| E | Estimable — the team can estimate the effort |
| S | Small — fits in a Sprint |
| T | Testable — acceptance criteria can be verified |
Scrum teams estimate relative complexity, not absolute time. The most common approach is Story Points using the Fibonacci sequence (1, 2, 3, 5, 8, 13, 20).
- A story is read and discussed
- Each team member secretly chooses a card representing their estimate
- Cards are revealed simultaneously
- Large differences are discussed; the process repeats until consensus
The goal is shared understanding, not a precise number. The discussion is more valuable than the estimate itself.
A team's velocity is the average number of story points completed per Sprint over recent history. It is used for forecasting, not as a performance target.
Kanban is an alternative to Scrum that focuses on visualising work and limiting work-in-progress (WIP) rather than time-boxed iterations.
┌───────────┬────────────┬────────────┬──────────┐
│ Backlog │ In Progress│ Review │ Done │
│ │ (WIP: 3) │ (WIP: 2) │ │
├───────────┼────────────┼────────────┼──────────┤
│ Story A │ Story C │ Story E │ Story F │
│ Story B │ Story D │ │ Story G │
│ Story H │ │ │ │
└───────────┴────────────┴────────────┴──────────┘
WIP limits prevent the team from starting more work than it can complete, which reduces context switching and reveals bottlenecks.
Kanban suits ongoing maintenance and support work where there is a continuous flow of items rather than project-scoped work.
Agile does not mean:
- No documentation (it means just enough documentation)
- No planning (it means planning at the right level of detail)
- No process (it means lightweight, empowering process)
- Moving fast at the expense of quality (technical excellence is explicit in the Agile principles)
Teams that practice Agile rituals without the underlying values — daily stand-ups become status reports, retrospectives become complaint sessions, sprints become micro-waterfalls — get the overhead without the benefits.
Agile delivery depends on strong technical practices. Without them, velocity degrades sprint by sprint as technical debt accumulates:
| Technical practice | Why it enables Agile |
|---|---|
| Automated testing | Confidence to change code at speed |
| Refactoring | Keeps code malleable for future stories |
| Continuous integration | Prevents integration failures accumulating |
| Clean code | Team members can work in each other's code |
| Simple design | Easy to extend; does not over-engineer for hypothetical futures |
Previous: SE-13: Database Design Principles
Next: SE-15: Foundational Coding Principles