Part 4: Scrum Deep Dive — Roles, Ceremonies & Artifacts

Introduction to Scrum

Scrum is not merely an agile methodology — it is a framework for developing, delivering, and sustaining complex products. According to the annual State of Agile report, over 87% of agile teams use Scrum or a Scrum-based hybrid. Yet paradoxically, fewer than 20% of those teams follow Scrum correctly. This gap between adoption and proper implementation is where most delivery pain originates.

In Part 3 we surveyed Agile methodologies at a high level. Now we go deep: every role, every ceremony, every artifact, and — critically — the anti-patterns that turn a powerful framework into bureaucratic theatre.

Origins & History

The term "Scrum" first appeared in a 1986 Harvard Business Review paper by Hirotaka Takeuchi and Ikujiro Nonaka titled "The New New Product Development Game." They observed that the best-performing product teams (at Honda, Canon, and Fuji-Xerox) did not follow a relay-race approach (waterfall) but rather moved like a rugby team — the whole team advancing together, passing the ball back and forth.

In 1995, Jeff Sutherland and Ken Schwaber formalised Scrum as a software development framework at the OOPSLA conference. They published the first Scrum Guide, which has been updated periodically (the latest revision in 2020 simplified the framework significantly).

The Rugby Analogy

In rugby, a "scrum" is a formation where the entire team locks arms and works together to gain possession of the ball. The metaphor is intentional:

• The whole team moves together — no handoffs between phases
• Progress requires coordination — individual brilliance is insufficient
• The opposition (complexity) pushes back — the team must respond as a unit
• Short bursts of focused effort — followed by regrouping

The Scrum Guide

The official Scrum Guide (scrumguides.org) is only 13 pages long. This brevity is by design — Scrum is a framework, not a methodology. It tells you the "what" and "why" but leaves the "how" to the team. The 2020 revision made three significant changes:

1. Replaced "Development Team" with "Developers" (removing the team-within-a-team confusion)
2. Introduced commitments for each artifact (Sprint Goal, Product Goal, Definition of Done)
3. Simplified language, removing prescriptive statements about how to run ceremonies

The Five Scrum Values

The 2016 Scrum Guide update added five explicit values. These are not decorative — they are the behavioural foundation that makes Scrum work. Without them, the ceremonies become empty rituals.

Openness & Respect in Practice

Openness requires psychological safety. If a developer fears punishment for admitting a mistake, they will hide problems until they explode. The Scrum Master's primary job is to create an environment where openness is safe.

Respect means trusting the team's expertise. When a Product Owner overrides technical estimates with "just get it done by Friday," they violate respect. When a developer dismisses a tester's concern as "not a real bug," they violate respect.

Courage

Courage is the most underrated value. It takes courage to:

• Say "no" to a stakeholder who wants to add scope mid-sprint
• Raise an impediment that implicates a manager
• Admit that the team over-committed and cannot deliver everything
• Refactor technical debt instead of shipping another feature
• Cancel a sprint when the Sprint Goal becomes obsolete

The Three Roles

Scrum defines exactly three roles (the 2020 Guide calls them "accountabilities"). No more, no less. Each has clear responsibilities, and the boundaries between them are deliberate. Violating these boundaries is one of the most common sources of dysfunction.

flowchart LR
    subgraph ScrumTeam["Scrum Team (≤ 10 people)"]
        PO[Product Owner]
        SM[Scrum Master]
        DT[Developers]
    end
    ST[Stakeholders] --> PO
    PO --> |"What to build\n(Product Backlog)"| DT
    SM --> |"Process coaching\n& impediment removal"| DT
    SM --> |"Facilitates &\nprotects"| PO
    DT --> |"Working Increment"| ST
                            

Product Owner

The Product Owner (PO) is the single person accountable for maximising the value of the product. They are the voice of the customer and the business within the Scrum Team.

Core Responsibilities

• Backlog Management: Creating, ordering, and clearly expressing Product Backlog items
• Value Maximisation: Ensuring each sprint delivers the highest possible business value
• Stakeholder Liaison: Gathering requirements, managing expectations, communicating progress
• Acceptance Criteria: Defining when a backlog item is "done" from a business perspective
• Release Decisions: Deciding when and what to release to production

Product Owner Anti-Patterns

Scrum Master

The Scrum Master (SM) is a servant-leader accountable for establishing Scrum as defined in the Scrum Guide. They help everyone understand Scrum theory, practices, rules, and values.

What a Scrum Master Actually Does

• Impediment Removal: Identifies and eliminates blockers that slow the team
• Process Coaching: Helps the team improve their practices sprint over sprint
• Facilitation: Ensures ceremonies are productive and timeboxed
• Shield: Protects the team from external interruptions and pressure
• Organisational Change Agent: Helps the broader organisation adopt agile practices

Scrum Master Anti-Patterns

Development Team (Developers)

The Development Team consists of professionals who do the work of delivering a potentially releasable increment at the end of each Sprint. The 2020 Scrum Guide uses "Developers" to encompass anyone who contributes to creating the increment — not just programmers.

Key Characteristics

• Self-organising: The team decides how to turn backlog items into increments. No one tells them how to do their work.
• Cross-functional: The team has all competencies needed to accomplish the work without depending on others outside the team.
• Ideal size: 5-9 people (the 2020 Guide says "typically 10 or fewer"). Fewer than 3 limits interaction and skill diversity. More than 9 requires too much coordination.
• No sub-teams: There are no "front-end team" or "QA team" within the Scrum Team. Everyone collectively owns the increment.
• No titles: Regardless of individual expertise (senior, junior, architect), all Developers share equal accountability for the increment.
• Collective ownership: Any developer can work on any backlog item. Knowledge silos are actively broken down.

Scrum Artifacts

Artifacts represent work or value. They are designed to maximise transparency of key information so that everyone has the same understanding of the artifact.

Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to the product. The Product Owner is responsible for it, including its content, availability, and ordering.

User Story Format

While not mandated by Scrum, the most common format for backlog items is the user story:

# User Story Format
As a [type of user]
I want [some goal]
So that [some reason/business value]

# Example
As a registered customer
I want to save items to a wishlist
So that I can purchase them later without searching again

# Acceptance Criteria (Given/When/Then)
Given I am logged in
When I click "Add to Wishlist" on a product page
Then the product appears in my wishlist within 2 seconds
And I see a confirmation toast notification

INVEST Criteria

Good user stories follow the INVEST acronym:

Story Points & Estimation

Story points measure the relative effort of backlog items. They are NOT hours. A 5-point story is roughly 2.5× the effort of a 2-point story. Common scales include:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21 (most common — gaps increase with uncertainty)
• T-shirt sizes: XS, S, M, L, XL (useful for high-level roadmap estimation)
• Powers of 2: 1, 2, 4, 8, 16 (simpler, forces coarser grouping)

Planning Poker is the most popular estimation technique: each team member privately selects a card, all reveal simultaneously, and outliers discuss their reasoning before re-voting.

Sample Product Backlog

Sprint Backlog

The Sprint Backlog is a subset of the Product Backlog selected for the current sprint, plus a plan for delivering the increment and achieving the Sprint Goal. It is owned by the Development Team.

• Only the Development Team can add or remove items during the sprint
• It is updated daily as the team learns more about the work
• It includes the Sprint Goal as its commitment
• It is visible to everyone (typically on a physical or digital board)

A typical Sprint Board has columns: To Do → In Progress → In Review → Done. Each backlog item is broken into tasks (2-8 hours each) that flow across the board.

Product Increment

The Increment is the sum of all Product Backlog items completed during a Sprint and the value of all previous increments. At the end of a Sprint, the new Increment must be "Done" — usable and meeting the Definition of Done.

Scrum Ceremonies (Events)

Scrum prescribes five events (including the Sprint itself as a container). Each is timeboxed. Each has a specific purpose. Removing any event reduces transparency and creates dysfunction.

Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed. The entire Scrum Team participates.

Three Questions of Sprint Planning

1. Why is this Sprint valuable? — The PO proposes how the product could increase value. The team collaborates to define the Sprint Goal.
2. What can be Done this Sprint? — Developers select items from the Product Backlog. They assess capacity, velocity history, and item complexity.
3. How will the chosen work get done? — Developers decompose items into tasks (typically ≤ 1 day). This creates the initial plan.

Capacity Planning

Teams must account for real-world constraints:

# Sprint Capacity Calculation
Team size: 6 developers
Sprint length: 10 working days
Individual capacity: 6 productive hours/day (accounting for meetings, admin)

# Adjustments
- Dev A: 2 days PTO = 8 days available
- Dev B: 1 day conference = 9 days available
- Others: Full 10 days

Total capacity = (8 + 9 + 10 + 10 + 10 + 10) × 6 hours = 342 hours
Historical velocity: ~40 story points / sprint
Focus factor: 0.7 (30% for meetings, unexpected issues)

Available capacity for sprint work: 342 × 0.7 = 239 hours

Daily Standup (Daily Scrum)

The Daily Scrum is a 15-minute event for the Developers. It occurs every working day at the same time and place to reduce complexity.

The Three Questions (Traditional Format)

1. What did I accomplish yesterday that helps the team meet the Sprint Goal?
2. What will I work on today to help the team meet the Sprint Goal?
3. Do I see any impediments that prevent me or the team from meeting the Sprint Goal?

Daily Standup Anti-Patterns

• Status report to the SM: People report upward instead of coordinating laterally
• Running over 15 minutes: Deep discussions should be taken "offline" after standup
• Problem-solving in standup: Raise the impediment; solve it afterwards with relevant people
• Skipping standup: "We're all in the same room" — information still gets lost without explicit sharing
• Walking the board instead of walking the team: Column-by-column reviews lose the person-centric sync

Sprint Review

The Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog. Stakeholders are invited to provide feedback.

The Sprint Review includes:

• The PO explains what has been "Done" and what has not
• Developers demonstrate the work done and answer questions
• The PO discusses the Product Backlog as it stands and projects likely delivery dates
• The entire group collaborates on what to do next — input to Sprint Planning
• Review of budget, timeline, and marketplace for the next anticipated release

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements during the next Sprint. It occurs after the Sprint Review and before the next Sprint Planning.

Popular Retrospective Formats

The Sprint

The Sprint is the heartbeat of Scrum — a fixed-length container for all other events. All work needed to achieve the Product Goal happens within Sprints.

Sprint Characteristics

• Fixed timebox: 1-4 weeks (2 weeks is the industry standard)
• Consistent length: All sprints are the same duration (don't alternate between 1 and 3 weeks)
• No extension: A Sprint cannot be lengthened. If the work is not done, it returns to the backlog.
• Sprint Goal: Every sprint has a single unifying objective that gives the team focus and flexibility
• No scope changes: Once Sprint Planning is complete, scope should not change within the sprint (with rare exceptions negotiated with the PO)

flowchart TD
    A[Sprint Planning
4-8 hours] --> B[Sprint
1-4 weeks]
    B --> C{Daily Scrum
15 min each day}
    C --> |"Repeat daily"| C
    C --> |"Sprint ends"| D[Sprint Review
2-4 hours]
    D --> E[Sprint Retrospective
1.5-3 hours]
    E --> F{Sprint Goal
Achieved?}
    F --> |"Yes"| G[Releasable Increment]
    F --> |"Partially"| H[Incomplete items
return to backlog]
    G --> I[Next Sprint Planning]
    H --> I
    I --> A

    style A fill:#3B9797,color:#fff
    style D fill:#16476A,color:#fff
    style E fill:#BF092F,color:#fff
    style G fill:#217346,color:#fff
                            

Sprint Cancellation

A Sprint can be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel a Sprint. Cancellation is rare and traumatic — it indicates a major shift in business direction.

Reasons a Sprint might be cancelled:

• Company direction changes dramatically (merger, pivot, market crash)
• Technology conditions change rendering the Sprint Goal impossible
• The Sprint Goal no longer makes business sense

When cancelled, any completed backlog items are reviewed. If part of the work is releasable, the PO typically accepts it. Incomplete items are re-estimated and put back on the Product Backlog.

Definition of Ready & Definition of Done

Definition of Ready (DoR)

The Definition of Ready is a team agreement that describes when a Product Backlog item is ready to be pulled into a Sprint. It ensures the team does not commit to poorly understood work.

• ✅ User story follows the "As a... I want... So that..." format
• ✅ Acceptance criteria are defined and testable
• ✅ Story is estimated by the Development Team
• ✅ Story is small enough to complete within one sprint
• ✅ Dependencies are identified and resolved (or have a plan)
• ✅ UX/UI designs are available (if applicable)
• ✅ The Product Owner can explain the business value
• ✅ The team has asked questions and received answers

Definition of Done (DoD)

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It creates transparency by providing everyone a shared understanding of what "complete" means.

• ✅ Code is written and peer-reviewed (pull request approved)
• ✅ All unit tests pass (minimum 80% code coverage for new code)
• ✅ Integration tests pass
• ✅ No critical or high-severity bugs remain
• ✅ Code merged to main branch
• ✅ Feature deployed to staging environment
• ✅ Acceptance criteria verified by QA
• ✅ Product Owner has accepted the story
• ✅ Documentation updated (API docs, user guides, runbooks)
• ✅ Performance benchmarks met (response time < 200ms for APIs)
• ✅ Security scan passed (no new critical vulnerabilities)
• ✅ Monitoring/alerting configured for new features

Scrum Metrics

Metrics help teams understand their performance and improve over time. However, metrics in Scrum must be used carefully — they are tools for the team's improvement, not management's surveillance.

Velocity

Velocity is the average number of story points completed per sprint. It is used for forecasting (how many sprints to complete the backlog) and capacity planning (how much to commit in Sprint Planning).

{
  "team": "Phoenix",
  "velocityHistory": {
    "sprint_18": 34,
    "sprint_19": 38,
    "sprint_20": 31,
    "sprint_21": 42,
    "sprint_22": 36,
    "sprint_23": 39
  },
  "averageVelocity": 36.7,
  "standardDeviation": 3.8,
  "forecastRange": {
    "pessimistic": 33,
    "likely": 37,
    "optimistic": 41
  }
}

Burndown Chart

A Sprint Burndown Chart shows the remaining work in the Sprint Backlog across time. The ideal line shows steady progress; reality often shows plateaus (blockers) or cliff-drops (stories completed in batches).

Burnup Chart

A Burnup Chart shows total work completed over time against the total scope. Unlike burndown, it also reveals scope changes — if the total scope line moves up, scope was added mid-sprint.

Sprint Goal Success Rate

Track what percentage of sprints achieve their Sprint Goal. A healthy team achieves 80%+ of Sprint Goals. Consistently missing Sprint Goals indicates estimation problems, scope creep, or external interruptions.

Common Scrum Anti-Patterns

Anti-patterns are practices that seem helpful but actually undermine Scrum's effectiveness. Recognising them is the first step to fixing them.

"Scrumbut"

"We do Scrum, but..." is the most pervasive anti-pattern. It indicates teams that use Scrum's vocabulary without its substance:

• "We do Scrum, but we don't do retrospectives because we don't have time"
• "We do Scrum, but the PO just sends requirements via email"
• "We do Scrum, but our sprints are flexible — they end when the work is done"
• "We do Scrum, but we don't estimate because it's a waste of time"
• "We do Scrum, but management assigns work directly to developers"

Mini-Waterfall Sprints

Week 1: Requirements analysis. Week 2: Development. Week 3: Testing. Week 4: "Hardening." This is waterfall with a 4-week timebox, not Scrum. In proper Scrum, every item should flow through analysis → development → testing → done within the sprint, ideally within days.

Other Critical Anti-Patterns

Case Studies

Exercises

Conclusion & Next Steps

Scrum is deceptively simple — three roles, five events, three artifacts. Yet mastering it requires deep understanding of why each element exists and the discipline to resist shortcuts. The framework succeeds when teams embrace its values, maintain its boundaries, and continuously improve their implementation.

Key takeaways from this deep dive:

• Scrum is a framework, not a methodology — it defines structure, not implementation details
• Values drive behaviour — without commitment, focus, openness, respect, and courage, ceremonies become theatre
• Roles have clear boundaries — the PO owns the "what," Developers own the "how," the SM protects the process
• Artifacts maximise transparency — backlog ordering, sprint boards, and increments keep everyone aligned
• Anti-patterns are insidious — "Scrumbut" erodes Scrum gradually; vigilance is required
• Metrics serve the team — velocity is for forecasting, never for comparison or punishment