Agile Scrum — Why 75 Story Points Delivered Zero Features

// WATERFALL TIMELINE — client sees working software only at the END

Month 1: [Requirements] — write a 200-page spec document
Month 2: [Design]       — architect the entire system on paper
Month 3: [Development]  — build everything
Month 4: [Development]  — still building...
Month 5: [Testing]      — find hundreds of bugs
Month 6: [Deployment]   — ship to client
           ↑
           Client says: "Actually, we need it to work differently."
           Cost to fix: HUGE. You're effectively starting over.
           Team morale: in the floor.
           Budget remaining: close to zero.

// AGILE TIMELINE — client sees working software every 2 weeks

Week 1-2:  [Sprint 1] — build Feature A → demo to client → get feedback
Week 3-4:  [Sprint 2] — build Feature B → demo to client → get feedback
Week 5-6:  [Sprint 3] — ADJUST Feature A based on feedback → ship Feature C
            ↑
            Client says: "Feature A needs tweaking."
            Cost to fix: TINY. You finished it two weeks ago.
            Team morale: intact — they saw the feedback coming.
            Budget remaining: most of it — you caught this early.

// THE KEY DIFFERENCE:
// Waterfall: discovery of wrong assumptions costs months
// Agile:     discovery of wrong assumptions costs days
//
// The feedback loop length is the only variable that matters.
// Everything else in Agile is just a mechanism to shorten it.

// THE AGILE MANIFESTO — Four Values with Real Decision Scenarios

// ─────────────────────────────────────────────────────────────
// VALUE 1: Individuals and Interactions > Processes and Tools
// ─────────────────────────────────────────────────────────────
// Scenario: Your team is blocked on an API contract disagreement.
// The process says open a JIRA ticket and route it through architecture review.
// That's five days minimum.

Agile Choice:
  "Let's get the two engineers + the API owner on a 20-minute call right now."
  Result: unblocked by lunch. Story continues.

Process-Over-People Choice:
  "Submit a change request form. Architecture review meets Thursdays."
  Result: blocked for five days. Sprint goal missed.

// ─────────────────────────────────────────────────────────────
// VALUE 2: Working Software > Comprehensive Documentation
// ─────────────────────────────────────────────────────────────
// Scenario: Client asks 'can users filter the report by date range?'

Agile Choice:
  Build a rough filter on a feature branch. Demo it over a 10-minute screen share.
  Get: "Yes, but we need quarter-to-date as a preset, not just a date picker."
  Cost: 2 days of work to find out exactly what they need.

Doc-First Choice:
  Write a 12-page requirements document describing date filter options.
  Review cycle: 3 weeks. Approval: 4 weeks.
  Build what was documented. Client says: "This isn't quite what we meant."
  Cost: 2 months to find out exactly what they need.

// ─────────────────────────────────────────────────────────────
// VALUE 3: Customer Collaboration > Contract Negotiation
// ─────────────────────────────────────────────────────────────
// Scenario: Three sprints in, the client wants to change the core data model.

Agile Choice:
  "Thanks for telling us now — that's genuinely useful.
   Let's look at the backlog together and figure out what this affects."
  Result: expensive rework in Sprint 4, but you've got 8 sprints left to deliver.

Contract-First Choice:
  "That's not in scope. A change order will cost £40,000 and extend delivery by 3 months."
  Result: client agrees reluctantly, says nothing more, accepts delivery,
  then never uses the product because the data model was wrong.

// ─────────────────────────────────────────────────────────────
// VALUE 4: Responding to Change > Following a Plan
// ─────────────────────────────────────────────────────────────
// Scenario: A competitor ships a feature your users are now actively requesting.

Agile Choice:
  Discuss with Product Owner. Reprioritise next Sprint's backlog.
  Ship a version of the feature in 2 weeks. Get ahead of the churn risk.

Plan-First Choice:
  "That's not in scope for this release.
   We'll consider it for version 2.0, roadmap review is in Q4."
  Result: users churn before Q4. The plan was followed perfectly.
  The business outcome was a failure.

// ─────────────────────────────────────────────────────────────
// THE PATTERN ACROSS ALL FOUR:
// Agile always prefers the faster feedback loop and the direct human conversation
// over the document, the process gate, the approval chain, or the original plan.
// The right side of each value isn't wrong — it just takes longer to tell you
// that you're building the wrong thing.

// ════════════════════════════════════════════════════════
// SCRUM FRAMEWORK — Complete Reference Overview
// ════════════════════════════════════════════════════════

// ─── THE THREE ROLES ─────────────────────────────────────

Product Owner (PO)
  ├── Owns the PRODUCT BACKLOG (the prioritised master to-do list)
  ├── Decides WHAT gets built and in what priority order
  ├── Represents the customer and business to the development team
  ├── Must be available — an absent PO is the most common sprint killer
  └── Key question: "Are we building the RIGHT thing?"

Scrum Master (SM)
  ├── Coaches the team on Scrum values, practices, and principles
  ├── Removes impediments blocking the team from doing their work
  ├── Protects the team from external interruptions during the Sprint
  ├── Does NOT assign tasks, track hours, or manage people
  ├── Does NOT tell the team HOW to solve technical problems
  └── Key question: "Are we working the RIGHT WAY?"

Development Team
  ├── Cross-functional: developers, designers, QA engineers together
  ├── Self-organising: THEY decide how to do the work (not the SM)
  ├── Collectively accountable — no 'not my job' culture
  ├── 3-9 people (small enough to move fast, large enough to cover skills)
  └── Key question: "Can we build it well, and can we finish it this Sprint?"

// ─── THE THREE ARTIFACTS ─────────────────────────────────

Product Backlog
  └── Master prioritised list of ALL work for the product
  └── Continuously refined — not a fixed document
  └── Example items (ordered by business priority):
       [1] "Users can reset password via email"     [8 pts, HIGH]
       [2] "Dashboard loads in under 2 seconds"     [5 pts, HIGH]
       [3] "Export report data to CSV"              [3 pts, MEDIUM]
       [4] "Dark mode toggle"                       [5 pts, LOW]

Sprint Backlog
  └── The specific subset the team commits to for the current Sprint
  └── Selected by the Development Team during Sprint Planning
  └── Owned by the Dev Team — the PO cannot add to it mid-Sprint
  └── Includes the Sprint Goal: the single unifying objective

Increment
  └── The actual working, potentially shippable software produced
  └── Every Sprint must produce an Increment
  └── Must meet the team's shared Definition of Done (DoD)
  └── Example DoD: code reviewed + unit tested + deployed to staging
                   + PO accepted + no new critical bugs introduced

// ─── THE FOUR CEREMONIES ─────────────────────────────────

Sprint Planning     (start of Sprint, 2-4 hours)
  └── What: Team selects backlog items, agrees on Sprint Goal,
           breaks stories into tasks
  └── Who: Entire Scrum team
  └── Output: Sprint Backlog + Sprint Goal

Daily Scrum         (every day, exactly 15 minutes)
  └── What: Team synchronises — what's done, what's next, any blockers
  └── Who: Development Team (SM facilitates, PO optional)
  └── Output: Updated plan for the next 24 hours
  └── NOT: a status report to management

Sprint Review       (end of Sprint, 1-2 hours)
  └── What: Team demos working software, stakeholders give feedback
  └── Who: Scrum team + stakeholders, customers if possible
  └── Output: Updated Product Backlog based on feedback
  └── NOT: a sign-off meeting or a pass/fail evaluation

Sprint Retrospective (end of Sprint, 45-90 minutes)
  └── What: Team reflects on HOW they worked, not what they built
  └── Who: Scrum team only — no stakeholders, no management
  └── Output: 1-3 specific, actioned improvements for next Sprint
  └── NOT: a complaint session or a blame exercise

// ─── THE SPRINT CYCLE ────────────────────────────────────

[Sprint Planning]
      ↓
[Daily Scrums × 8-10 days]
      ↓
[Sprint Review] → Stakeholder feedback → Updated Backlog
      ↓
[Retrospective] → Process improvement → Team agreement
      ↓
[Next Sprint Planning — starts Monday]

// Typical Sprint: 2 weeks (some teams: 1 week for fast-moving products,
//                           4 weeks for complex enterprise work)
// Rule: Once chosen, Sprint length stays constant. Stability matters.

// ═══════════════════════════════════════════════════════════════
// A REALISTIC TWO-WEEK SPRINT — Day by Day
// Team: 4 developers, 1 designer, 1 QA engineer
// Sprint Goal: "Users can register, log in, and reset their password"
// ═══════════════════════════════════════════════════════════════

// ─── DAY 1 (Monday): SPRINT PLANNING ────────────────────────────

Product Owner presents top backlog items:
  Story 1: "As a new user, I want to register with email + password"  [8 pts]
  Story 2: "As a registered user, I want to log in securely"          [5 pts]
  Story 3: "As a user, I want to reset my password via email"         [8 pts]
  Story 4: "As a user, I want to see a dashboard after login"        [13 pts]

// Story Points = relative complexity, NOT hours
// 1 pt = trivially simple, 13 pts = large and uncertain
// Team's realistic capacity this Sprint: ~21 points
// (Team uses 70% of theoretical capacity — 30% buffer for emergent work)

Team selects Stories 1, 2, and 3 (21 points total)
Story 4 returns to Product Backlog — next Sprint candidate

Team sets Sprint Goal:
  "By end of Sprint, a user can create an account, log in,
   and recover access if they forget their password."

Team breaks stories into tasks:

  Story 1 — Registration:
    ├── Design registration form UI                   [Designer, Day 1-2]
    ├── Build /register API endpoint (POST)           [Dev A, Day 1-3]
    ├── Email format validation + uniqueness check    [Dev B, Day 2-3]
    ├── Hash password with bcrypt before storage      [Dev A, Day 3]
    └── Integration tests: happy path + duplicates    [QA, Day 3-4]

  Story 2 — Login:
    ├── Build /login API endpoint (POST)              [Dev A, Day 3-5]
    ├── JWT token generation + storage                [Dev B, Day 4-5]
    └── Integration tests: valid + invalid creds      [QA, Day 5-6]

  Story 3 — Password Reset:
    ├── Build /forgot-password + /reset endpoints     [Dev C, Day 4-7]
    ├── Email delivery via SendGrid                   [Dev C, Day 5-7]
    ├── Time-limited token generation (1 hour expiry) [Dev D, Day 5-7]
    └── End-to-end test: full reset flow              [QA, Day 7-8]

// ─── DAYS 2-9: SPRINT EXECUTION ──────────────────────────────────

// Daily Scrum — every morning, 15 minutes, team-led
// Example from Day 4:

  Dev A:   "Yesterday: finished /login endpoint, PRs up for review.
             Today: starting JWT refresh token logic.
             Blocker: NONE."

  Dev B:   "Yesterday: JWT generation done, merged.
             Today: uniqueness check on email — needs DB schema clarification.
             Blocker: Need write access to staging database. Who owns that?"

  SM:      "I'll get you staging access by 10am. Anyone else?
             [Dev B]: noted, I'll follow up directly — let's keep moving."

  QA:      "Yesterday: registration tests passing, 2 edge cases found.
             Today: writing login test scenarios.
             Blocker: No staging environment for password reset flow yet."

  Dev C:   "I'll have reset endpoints deployed to staging by 2pm today.
             QA, I'll message you when it's ready."

// Notice:
// 1. Dev B's blocker was resolved in the meeting itself — that's the goal.
// 2. Dev C and QA coordinated without waiting for a manager to arrange it.
// 3. Managers can observe but don't speak. The team synchronises with itself.
// 4. Meeting ended at 14 minutes.

// ─── DAY 9 (Thursday): SPRINT REVIEW ─────────────────────────────

// Audience: Scrum team + Product Owner + 2 business stakeholders

Team demos working features on staging environment:
  ✅ Story 1 — Registration: live form, real validation, confirmation email
  ✅ Story 2 — Login: demo with test accounts, error handling shown
  ✅ Story 3 — Password reset: email arrives in 3 seconds, link works, token expires

Stakeholder feedback:
  Stakeholder A: "Password reset email arrives fast — great.
                  But the email copy says 'Click here' — feels generic.
                  Can we brand it properly?"

  Stakeholder B: "Registration form is clean. One question: what happens
                  if someone enters an email already in the system?"

  QA Demo: Shows the 'Email already registered' error — already handled.
  Stakeholder B: "Perfect."

Product Owner action:
  → Adds "Brand password reset email template" to Product Backlog (low priority)
  → NOT added to this Sprint. Captured. Will be ranked in next Planning.

// ─── DAY 10 (Friday): SPRINT RETROSPECTIVE ───────────────────────

// Audience: Scrum team ONLY. No stakeholders. Psychological safety required.

  WENT WELL:
  ✅ All three stories delivered — accurate estimation
  ✅ Blockers from Daily Scrum resolved same-day, every time
  ✅ QA and Dev coordinated async without waiting for handoffs

  NEEDS IMPROVEMENT:
  ❌ QA found two bugs in Story 1 on Day 5 that should have been caught Day 2
     Root cause: QA wasn't involved when Dev and Designer agreed acceptance criteria

  ACTION ITEM (single owner assigned):
  → QA joins story kickoff for every story from Sprint 7 onward [Owner: SM]
  → Added as explicit task in Sprint 7 Planning
  → Tracked: will review impact in Sprint 8 Retrospective

// ─── SPRINT COMPLETE ─────────────────────────────────────────────

// Working software: deployed and PO-verified      ✅
// Sprint Goal met: fully                          ✅
// Stakeholder feedback: captured and backlogged   ✅
// Team improvement: specific, owned, trackable    ✅
// Next Sprint: begins Monday with refreshed backlog ✅

// Total cycle time to validate assumptions: 10 working days.
// Compare that to a Waterfall project where the same feature set
// would be 'done' on paper at month 6 but untested against real users.