Agile Software Development Model

• Agile is a family of methods (Scrum, Kanban, Extreme Programming and others) that share one set of values: the Agile Manifesto of 2001.
• Iterative: the team repeats a short cycle (plan, build, test, show). Incremental: every cycle adds a usable piece of the product.
• Empiricism: decide from what you observe, not from predictions. Each iteration ends with a working increment that the customer can try, so wrong requirements surface after two weeks, not after two semesters.
• In Chapter 04 you compared process models; here we practise one agile framework in detail.

Paraphrased. The manifesto was written by 17 practitioners in February 2001 at Snowbird, Utah.

mindmap
  root((12 principles))
    Value to the customer
      Early and continuous delivery
      Welcome change, even late
      Release every few weeks
    People and collaboration
      Business and developers daily
      Motivated, trusted people
      Talk face to face
    Progress and pace
      Working software measures progress
      A pace you can sustain
    Technical excellence
      Good design, always
      Simplicity: less work
    Self-improving teams
      Self-organising teams
      Reflect and adjust

• Three pillars: transparency (work is visible), inspection (look at it often), adaptation (change course when it drifts).
• 3 accountabilities: Product Owner, Scrum Master, Developers.
• 5 events: the sprint, which contains planning, daily scrum, review and retrospective.
• 3 artifacts, each with a commitment: product backlog (Product Goal), sprint backlog (Sprint Goal), increment (Definition of Done).
• Scrum is deliberately incomplete: it says what must happen, the team chooses how (for example TDD from XP, boards from Kanban).

• "Developers" means everyone who creates the increment: testers, designers and writers too.
• The Scrum Master has no authority over tasks; the Developers decide who does what.

gantt
  title Two-week sprint, example dates
  dateFormat YYYY-MM-DD
  axisFormat %a %d
  excludes weekends
  section Scrum events
  Sprint planning, 4 h      :crit, p, 2026-11-02, 1d
  Daily scrum, 15 min a day :d, 2026-11-03, 8d
  Sprint review, 2 h        :r, 2026-11-13, 1d
  Retrospective, 1.5 h      :crit, 2026-11-13, 1d
  section Work
  Build, test, integrate    :active, dev, 2026-11-02, 10d
  Refine Sprint 2 stories   :2026-11-10, 1d

Shorter sprints get shorter events: Club Hub uses 4 h, 15 min, 2 h and 1.5 h. Refinement is an ongoing activity, not an event.

• Product backlog: the single ordered list of everything the product might need. Items near the top are small and clear (refined); items at the bottom are coarse. The PO is accountable for its order.
• Sprint backlog: the Sprint Goal, the items selected for the sprint and the plan to deliver them. It changes daily as the Developers learn.
• Increment: a concrete, usable step toward the Product Goal. It adds to all earlier increments and is verified to work with them. Several increments may be produced within one sprint.
• Commitments make each artifact measurable: the Product Goal (long-term target), the Sprint Goal (this sprint's target) and the Definition of Done (when an item becomes part of the increment).

• A story point is a unit of relative size that blends effort, complexity and uncertainty. "US-05 is about as big as US-06 and bigger than US-04."
• Pick a reference story everyone understands (US-04 = 3) and size others against it. People compare much better than they predict hours.
• Points belong to one team: 5 points in team A says nothing about team B.
• The whole team estimates, because the work includes coding, testing and review.
• Hours are still useful for tasks inside a sprint (capacity check), not for backlog items.

flowchart TD
  A[PO reads the story
and its criteria] --> B[Questions and answers]
  B --> C[Everyone picks a card
in secret]
  C --> D[All cards revealed together]
  D --> E{Close enough?}
  E -- no --> F[Highest and lowest
explain why]
  F --> C
  E -- yes --> G[Record the consensus]

Revealing at the same time avoids anchoring: nobody copies the first number spoken aloud. Technique popularised by Mike Cohn (2005).

Discussion after round 1

• Malis (2): "Cancel is one line: set the status to Cancelled."
• Rithy (13): "The 24-hour rule needs the event start and the current time, and the CSV file must be rewritten, not appended. We also have no test for time yet."
• The team agrees to inject the current time as a parameter (easy to test) and to reuse the CSV writer from US-05. Round 2 converges.

• A task board shows every sprint backlog item and its tasks in columns by state. Anyone can see the sprint at a glance: transparency.
• Cards move left to right; the developer who takes a task puts their name on it.
• Update the board before the daily scrum so the daily discusses reality.
• Work on one story at a time (swarming): three half-finished stories are worth zero points at the review.
• Tools: a whiteboard with sticky notes, or GitHub Projects (Lab-07), Jira, Trello.

---
config:
  themeVariables:
    xyChart:
      plotColorPalette: "#6c757d, #0d6efd"
---
xychart-beta
  title "Sprint 1 burndown, remaining task hours"
  x-axis [D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10]
  y-axis "Remaining hours" 0 --> 52
  line [48, 43.2, 38.4, 33.6, 28.8, 24, 19.2, 14.4, 9.6, 4.8, 0]
  line [48, 50, 46, 42, 40, 35, 31, 24, 16, 9, 3]

Grey straight line: ideal burn (48 h / 10 days = 4.8 h per day). Blue line: actual remaining hours taken from the board every evening.

• How to build it: after sprint planning, sum the task estimates (48 h). Each day, sum the hours still open on the board and plot the point.
• Day 1 goes up (48 to 50 h): the team discovered a task, the CSV file must be rewritten on cancel. New work found is normal and should be visible.
• Actual above ideal = behind. On day 5 the ideal is 24 h, the actual 35 h: 11 h late. The daily scrum should re-plan now, not on day 9.
• Day 10 ends at 3 h: the CLI cancel command is unfinished, so US-06 is not done. It returns to the product backlog; the sprint delivers 8 of 13 points.

---
config:
  themeVariables:
    xyChart:
      plotColorPalette: "#0d6efd, #dc3545"
---
xychart-beta
  title "Velocity of a team over five sprints"
  x-axis [S1, S2, S3, S4, S5]
  y-axis "Story points done" 0 --> 25
  bar [14, 18, 15, 17, 16]
  line [16, 16, 16, 16, 16]

Bars: points of stories that met the DoD. Red line: the average, 16 points.

Remaining product backlog      60 points
Velocity range (last 5 sprints) 14 to 18 points

Best case   60 / 18 = 3.3  -> 4 sprints
Worst case  60 / 14 = 4.3  -> 5 sprints
Forecast    4 to 5 sprints = 8 to 10 weeks
            (2-week sprints; round up, a
             partial sprint is still a sprint)

• Velocity counts only done stories; partly finished work counts zero.
• Forecast with a range, never a single number; the range narrows as history grows.
• Use it for the team's own planning. Comparing teams by velocity, or setting it as a target, makes points inflate.

• Visualise every step of the workflow as a column.
• Limit WIP: the number on each column is the maximum number of cards in it. When Develop is full, a developer helps finish or unblock a card instead of starting a new one.
• Manage flow, make policies explicit (what "Ready" means), use feedback loops and improve step by step.
• No sprints and no prescribed roles: work is pulled continuously.

Little's Law: lead time = WIP / throughput
WIP 6 cards, 3 cards done per week -> 2 weeks
WIP 3 cards, same throughput       -> 1 week

git commit -m "Add capacity rule" \
  -m "Co-authored-by: Sokha <sokha@example.com>"

The co-author trailer keeps both partners visible in the Git history.

• The test states the rule from the acceptance criterion before any code exists.
• Run it and watch it fail: that proves the test can detect the missing behaviour.
• Commit the red test: test: cannot register twice (red).

// tests/registration_service_test.cpp
#include <gtest/gtest.h>
#include "InMemoryRegistrationRepository.hpp"
#include "clubhub/RegistrationService.hpp"

using namespace clubhub;
using clubhub::testing::InMemoryRegistrationRepository;

TEST(RegistrationService, StudentCannotRegisterTwice) {
    InMemoryRegistrationRepository repo;  // test double, no file
    RegistrationService service{repo};
    Event event;
    event.id = "E1";
    event.capacity = 30;
    service.registerStudent(event, "S001");
    EXPECT_THROW(service.registerStudent(event, "S001"), DuplicateRegistration);
}

$ ctest --test-dir build --output-on-failure
[ RUN      ] RegistrationService.StudentCannotRegisterTwice
registration_service_test.cpp:16: Failure
Expected: service.registerStudent(event, "S001") throws an exception
  of type DuplicateRegistration.
  Actual: it throws nothing.
[  FAILED  ] RegistrationService.StudentCannotRegisterTwice

quadrantChart
  title Which process fits?
  x-axis Stable requirements --> Volatile requirements
  y-axis Low criticality --> High criticality
  quadrant-1 Hybrid, agile plus rigour
  quadrant-2 Plan-driven
  quadrant-3 Either, keep it light
  quadrant-4 Agile
  ITC Club Hub: [0.72, 0.25]
  Pacemaker firmware: [0.15, 0.92]
  Startup mobile app: [0.88, 0.15]
  Payroll upgrade: [0.3, 0.62]
  Banking app: [0.78, 0.72]
  Report script: [0.2, 0.1]