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.

# Sprint 17 failure mapping — what went missing
sprint_goal: "Deploy payment gateway v2"
failures:
  - value: Commitment
    symptom: "We'll try to finish all 8 stories"
    result: Delivered 2 of 8; no sprint goal met
    fix: One committed sprint goal, not a wishlist
  - value: Courage
    symptom: "The DB migration looks fine" 
    result: Rolled back in production; 4 hours downtime
    fix: Name the fear in daily scrum before it ships
  - value: Focus
    symptom: Team pulled 3 new stories mid-sprint
    result: Zero stories completed; all 8 carried over
    fix: Freeze backlog entry after sprint planning
  - value: Openness
    symptom: "No blockers" every day
    result: API contract wasn't agreed; blocked 3 devs
    fix: Make "no blockers" a red flag, not a green light
  - value: Respect
    symptom: "The devs never commit on time"
    result: PO assigned deadlines without estimates
    fix: PO must attend estimation or accept team's range

def is_done(story):
    # Production DoD checklist — every condition must pass
    rules = {
        'code_reviewed': story.reviews > 0,
        'unit_tests': story.test_coverage >= 0.85,
        'integration_tests': story.integration_status == 'pass',
        'no_p1_bugs': story.p1_bug_count == 0,
        'docs_updated': story.docs_version == story.version,
        'deployed_staging': story.staging_etag == 'healthy',
        'acceptance_criteria_met': story.ac_validation['pass_count'] == story.ac_validation['total']
    }
    failed = [k for k, v in rules.items() if not v]
    if failed:
        print(f"REJECTED — missing: {', '.join(failed)}")
        return False
    print("DONE — increment is releasable")
    return True

# Real sprint example
story_42 = {'reviews': 2, 'test_coverage': 0.92, 'integration_status': 'pass', 
            'p1_bug_count': 1, 'docs_version': '2.1', 'staging_etag': 'healthy',
            'ac_validation': {'pass_count': 4, 'total': 5}}
is_done(story_42)  # REJECTED — missing: no_p1_bugs, docs_updated

| Feature               | Scrum                          | Kanban                          | Scrumban (hybrid)              |
|-----------------------|--------------------------------|--------------------------------|--------------------------------|
| Flow type             | Iterative (time-boxed)        | Continuous (pull-based)        | Iterative + pull               |
| WIP limits            | Implicit (sprint scope)       | Explicit (per column)          | Explicit (per swimlane)        |
| Iterations            | Fixed sprints (1-4 weeks)     | None (continuous delivery)     | Optional time boxes             |
| Cadence               | Sprint planning, review, retro| No fixed cadence               | Sprint rhythm + Kanban flow     |
| Best for              | Complex, uncertain features   | Predictable, flow-based work   | Mixed: features + maintenance   |
| Change flexibility    | Low mid-sprint; high between  | High (anytime)                 | Medium (commit to sprint goal)  |

def plan_sprint(velocity, team_members, sprint_days, holidays, meeting_hours):
    # Capacity = velocity adjusted for real availability
    ideal_days = sprint_days  # e.g., 10
    actual_days = sprint_days - holidays
    capacity_ratio = actual_days / ideal_days
    
    # Meeting overhead reduces capacity per person
    daily_meeting_cost = meeting_hours / 8  # convert to person-days lost
    overhead_factor = max(0, 1 - (daily_meeting_cost / team_members))
    
    adjusted_capacity = velocity * capacity_ratio * overhead_factor
    # Buffer: never exceed 80% of adjusted capacity
    max_commit = adjusted_capacity * 0.8
    
    print(f"Velocity: {velocity}")
    print(f"Capacity ratio: {capacity_ratio:.2f} ({holidays} holidays)")
    print(f"Meeting overhead: {overhead_factor:.2f}")
    print(f"Adjusted capacity: {adjusted_capacity:.1f}")
    print(f"Max sprint commitment (80%): {max_commit:.1f}")
    return round(max_commit)

# Real example
plan_sprint(velocity=30, team_members=5, sprint_days=10, holidays=2, meeting_hours=4)
# Output: Velocity: 30; Capacity ratio: 0.80; Meeting overhead: 0.90
# Adjusted capacity: 21.6; Max commitment: 17.3

# Decision tree for choosing a scaling framework
scaling_decision:
  teams: 3  # Number of Scrum teams
  cross_dependencies: true  # Do teams need to coordinate on shared code?
  governance_level: "moderate"  # low, moderate, high
  
  # Decision logic
  if teams < 2:
    recommendation: "No scaling needed. Fix your single team."
  elif teams <= 5 and cross_dependencies:
    if governance_level == "low":
      recommendation: "LeSS — minimal overhead, one backlog, one sprint"
    else:
      recommendation: "Nexus — add integration team for dependency management"
  elif teams > 5:
    recommendation: "SAFe — but only if you accept PI planning and ART cadence"
  else:
    recommendation: "Independent teams with component ownership — no framework needed"

# Real scenario: 3 teams, shared backend service, moderate governance
# → Nexus: single sprint cadence, dedicated integration team for API coordination
# Output: Recommendation: Nexus