Agile vs. Scrum: What's the Difference? — A Practical Guide for Development Teams

Introduction

This article organizes the relationship between Agile and Scrum, and summarizes the minimum knowledge needed to work in the field. It's aimed at those who are about to join a team or want to update knowledge they've built up on their own.

What Is Agile?

In a Nutshell

Agile is not a specific methodology, but rather a "way of thinking" and "set of values" for software development. Its starting point is the "Agile Manifesto," published in 2001 by 17 software developers who came together.

The Four Values

The Agile Manifesto expresses these values as preferring the right side over the left.

One important note: it does NOT say "the left side has no value." Both sides have value, but we place greater emphasis on the right side—that is the Agile stance.

12 Principles (Excerpts)

Behind the manifesto are 12 principles. You don't need to memorize all of them, but here are the three most frequently cited:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

"Deliver working software in short cycles" and "Welcome change"—these two points can be considered the core of Agile.

What Is Scrum?

How It Relates to Agile

This is where things often get confused. Here it is in a diagram:

Agile (mindset / values)
├── Scrum (framework) ← most widely adopted
├── XP (Extreme Programming)
├── Kanban
└── Others...

In other words, Scrum is one specific framework for practicing Agile. Agile ≠ Scrum, and the correct relationship is Scrum ⊂ Agile.

The Scrum 3-5-3

Scrum consists of "3 Accountabilities, 5 Events, and 3 Artifacts." In the 2020 version, the traditional term "roles" was changed to "accountabilities," and each artifact received a commitment (Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done).

The 3 Accountabilities

• Product Owner (PO): Responsible for maximizing the value of the product. Decides the priority of what to build.
• Scrum Master (SM): Supports the correct functioning of Scrum. A coach for the team who removes impediments.
• Developers: The people who actually build the product. Engineers, designers, QA, etc.

The 5 Events

The 3 Artifacts

• Product Backlog: A prioritized list of everything you want to do. Managed by the PO.
• Sprint Backlog: The list of work for the current Sprint. Managed by the Developers.
• Increment: The working product completed in the Sprint.

The Sprint Cycle

[Planning] → [Development + Daily × N days] → [Review] → [Retro] → Next Sprint

Repeating this cycle for a fixed period is the fundamental rhythm of Scrum.

Diving Deeper into Scrum with Examples

From here, let's take a closer look at parts that can be hard to grasp from abstract explanations alone, using a fictional product as an example.

Deep Dive into Roles

Product Owner (PO) — Alex's Day

The PO's job is often described as "deciding priorities," but in reality it's much messier. Here's a typical day for FitLog team's PO, Alex:

• Morning: Reviews usage data from the recent release, identifies screens with high drop-off rates. Organizes requests from the customer support team.
• Afternoon: Meets with stakeholders (marketing, executive team) to align Q3 business goals with the product goal.
• In between: Immediately responds to developer questions like "This spec—would this lighter implementation work for you?"
• Weekly: Refines the backlog and clarifies acceptance criteria for top items.

The key point is that the PO bears the weight of both "user value" and "business value." To have a basis for deciding "Feature A vs. Feature B—which comes first?", they need to handle user research, data analysis, and executive meetings.

Scrum Master (SM) — Examples of Sam's Interventions

The SM is often thought of as a "meeting facilitator," but the essence is a coach who draws out the team's autonomy. Here are some things FitLog team's SM, Sam, actually does:

• Notices that Developer A says "I was investigating this bug again yesterday" every day in the Daily Scrum, and reaches out 1-on-1: "Are you struggling? Do you need help?"
• Observes that there's always a mismatch in "spec interpretation" between the PO and developers, and brings this issue up in the Retro.
• Stops direct requests flying in from other departments ("We need urgent help!") and reinforces the rule: "Requests go through the PO."
• Proposes revisiting the format of Scrum events when the team has settled in (e.g., changing the Daily Scrum format).

The SM is a role that may seem to be doing nothing, but is actually continuously shaping the team's environment. "The SM seems idle lately" can actually be a good sign that the team is starting to run autonomously.

Developers — What Does "Self-Managing" Mean?

In the 2020 Scrum Guide, the entire Scrum Team is described as self-managing. For Developers specifically, self-management manifests in these concrete ways:

• "What" to do in the Sprint is decided in consultation with the PO, but "how" to implement it is decided by the Developers.
• Tasks are not assigned from above; Developers pull them themselves.
• Estimates are made by Developers (not the PO or a manager).
• Developers are responsible for upholding quality standards (Definition of Done).

When iOS developer Chris notices "This API response is slow and hurts the UX," they directly consult Backend developer Riley to improve it—this kind of horizontal collaboration happening naturally is what a healthy Scrum team looks like.

Deep Dive into Events

Sprint Planning — A Real Example of How It Goes

FitLog team's 2-week Sprint Planning proceeds like this (approximately 4 hours):

Part 1: Why is this Sprint valuable? (Setting the Sprint Goal)

PO Alex: "I want our goal for this Sprint to be: 'Users can check their training progress for the past 30 days through a graph.' Last month's research showed that users with higher retention use the graph feature more."

The Sprint Goal is best expressed as a state to achieve, not a feature list.

Part 2: What can be done this Sprint? (Selecting Backlog Items)

For the top items presented by the PO, developers estimate using Planning Poker and select an amount that fits within their capacity.

Part 3: How will the selected work be completed? (Task Breakdown)

Developers break the selected backlog items down into concrete tasks.

Developer Chris: "Breaking down the 'Graph Display Screen' item, it becomes 4 tasks: API design, iOS implementation, Android implementation, and E2E testing. Since we can't parallelize without the API design done first, Day 1 should be focused on Riley."

Daily Scrum — Good vs. Bad

❌ Bad Daily (turns into a status report)

"Yesterday I worked on the API implementation. Today I'll write tests. No blockers."
"I've been progressing on the screen implementation. I'll continue today."
……(continues flatly for 15 minutes)

This is a status report, not inspection and adaptation.

✅ Good Daily (inspection and adaptation)

Developer Chris: "The graph rendering library is heavier than expected. To achieve the Sprint Goal, I want to consider switching to a different library. I need 2 hours for additional investigation after Planning."
Developer Riley: "Then I can move my API implementation forward by a day to support you."
Developer Chris: "Let's work out the details just the two of us in 30 minutes after this."

The right purpose is a place for re-planning how to act today in relation to the Sprint Goal.

Sprint Review — More Than Just a Demo

A common misconception about the Review is "demo what works and you're done." A proper Review is a dialogue involving stakeholders.

• Developers demo the working Increment
• Stakeholders interact with it and give feedback
• External information is shared: "Market conditions have changed," "User reactions were different from expected"
• Based on this, the Product Backlog is adjusted for what comes next

So the Review serves not just as "inspection of the past" but also as "input for future planning."

Sprint Retrospective — Tips to Avoid Empty Ritual

Retros are often thought of as "run with KPT (Keep/Problem/Try)," but any format is fine. Changing the format to suit the team's situation is useful, but it's a means, not an end.

Variations the FitLog team is trying:

And narrow down Tries to just one, and start on it at the beginning of the next Sprint. "Let's do everything" is the same as doing nothing.

Deep Dive into Artifacts

Product Backlog — The Right Granularity for Items

Product Backlog Items (PBIs) are often written in User Story format:

As a [what kind of user]
I want to [what they want to do]
So that [why they want to do it]

Good PBI example for FitLog:

Title: Display 30-day training progress graph

As a user who regularly jogs, I want to see a graph of my running distance over the past 30 days, because I want to maintain my motivation by visualizing my effort.

Acceptance Criteria:

• A "Progress" tab is added to the home screen
• Daily running distance for the past 30 days is displayed as a line graph
• Days with 0 data appear as blank on the graph
• Tapping the graph navigates to the detail screen for that day

❌ Bad PBI example: "Implement graph feature" ← unclear for whom or what purpose

PBIs should ideally satisfy the INVEST principle (Independent / Negotiable / Valuable / Estimable / Small / Testable).

Sprint Backlog — Connection to the Product Goal

The Sprint Backlog is not a "task list"; it's a plan consisting of three elements:

1. Sprint Goal (why): The state to achieve in this Sprint
2. Selected PBIs (what): Items selected from the Product Backlog
3. Execution Plan (how): Task breakdown and approach

Sprint Goal: Users can check their training progress for the past 30 days via a graph
├─ PBI 1: Progress graph display screen [8 pt]
│   ├─ Task: API endpoint design
│   ├─ Task: iOS implementation
│   ├─ Task: Android implementation
│   └─ Task: E2E testing
├─ PBI 2: Navigate to detail on graph tap [3 pt]
│   └─ ...
└─ PBI 3: Improve empty data state display [2 pt]
    └─ ...

Increment — The "Definition of Done (DoD)"

The Increment is described as "working product," but what counts as done needs to be clearly defined by the team. This is the Definition of Done (DoD).

FitLog team's DoD example:

• 2 or more Approvals in code review
• Unit test coverage of 80% or higher
• E2E tests pass
• Accessibility check complete (VoiceOver / TalkBack)
• PM has confirmed acceptance criteria and approved
• Draft release notes created

Anything that doesn't meet the DoD is considered "unfinished" and carried over to the next Sprint. Finishing 5 features at 100% is better than accumulating 10 features at 80%—that's the Scrum mindset.

Velocity — Measuring the Team's "Speed"

If you've read this far, you might be wondering: "What was that [8 pt] next to PBIs?" This leads to the topic of Velocity, which is important for running Scrum in practice.

Definition

Velocity is the total size of backlog items a team completes per Sprint. It's generally defined as:

Velocity = Sum of Story Points of PBIs that met the Definition of Done in that Sprint

Key points:

• Only count completed PBIs (80% done = 0)
• The unit is generally Story Points (SP) (not hours)
• Measured per Sprint; often viewed as a moving average over multiple Sprints

What Are Story Points?

Story Points represent the relative size of work. Rather than absolute values like "person-days" or "hours," you estimate by comparing to a reference task: "How big is this compared to that baseline task?"

The commonly used scale is the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21...). The increasing gaps reflect the idea that "larger tasks have higher uncertainty, and fine-grained distinctions don't matter."

FitLog team's estimation baseline:

Example: FitLog Team's Velocity Trend

Let's look at FitLog team's results over the last 6 Sprints:

Sprint 1: 18 pt (completed PBIs: 5 + 5 + 3 + 3 + 2)
Sprint 2: 22 pt (completed PBIs: 8 + 5 + 5 + 2 + 2)
Sprint 3: 25 pt (completed PBIs: 8 + 8 + 5 + 3 + 1)
Sprint 4: 23 pt
Sprint 5: 26 pt
Sprint 6: 24 pt
─────────────────────
Last 3-Sprint average: 24.3 pt ← This is the current velocity

This tells us the team can handle approximately 24 points per Sprint.

How to Use Velocity

Once velocity stabilizes, you can use it in the following ways:

1. Understanding Capacity for Sprint Planning

PO Alex: "The candidate PBIs for the next Sprint total 32 points."
Developer Chris: "With a recent average of 24 points, it's realistic to take on the top 26 points worth (8+8+5+3+2)."

Rather than "we'll make it work through effort," this allows evidence-based agreement.

2. Predicting Release Plans

If the entire Product Backlog is 180 points and velocity is 24 points, the estimate is 180 ÷ 24 = about 7.5 Sprints to completion.

With this, you can explain to stakeholders "We're likely able to release around the end of Q3" with a concrete basis.

3. Continuous Improvement of Estimation Accuracy

When you can see discrepancies like "estimated 5 points but actually took 10 points of effort," it becomes material for discussion in the Retro.

Common Anti-Patterns

Velocity is useful, but when misused, it can destroy a team.

❌ Anti-pattern 1: Making Velocity a KPI

"This month's velocity needs to be higher than last month's," "Having lower velocity than another team means you're slacking"—this is the worst way to use it.

Velocity is a relative value specific to each team, and comparing across teams is meaningless. Also, pressuring teams to "increase velocity" just causes them to inflate estimates, and actual productivity doesn't change (in fact, it decreases).

❌ Anti-pattern 2: Story Points = Time

Starting to use "1 point = 4 hours" as a fixed conversion makes Story Points meaningless. The advantages of relative estimation (expressing uncertainty, efficient discussion) are lost, and it degrades to just effort estimation.

❌ Anti-pattern 3: Counting Partial Credit for Incomplete PBIs

"An 8-point PBI is 70% complete, so let's count 5.6 points"—this must not be done. PBIs that don't meet the Definition of Done count as 0 points.

Reason: Velocity is a metric for predicting "how much we can complete in the next Sprint." Counting in-progress work distorts the prediction.

❌ Anti-pattern 4: Trusting Values Right After Team Changes

When members join or leave, or the tech stack changes, velocity resets. After establishing a new team structure, the rule of thumb is to run 3–4 Sprints first before recalculating the average.

The Option of Not Using Velocity

In recent years, more teams are "not tracking velocity." Alternative metrics include:

• Throughput: Number of completed PBIs (no points assigned; keep PBI granularity consistent and count numbers)
• Cycle Time: Time from when a PBI is started to when it's completed
• Lead Time: Time from when a PBI is created to when it's completed

Particularly when combined with Kanban, or for mature teams looking to reduce estimation overhead, these metrics can be more effective.

Essential Glossary

Scrum/Agile has a lot of unique terminology, and whether you know it significantly affects communication efficiency within a team. Let's go deeper with real examples.

Planning Poker

What It Does

Planning Poker is a technique where the entire team estimates Story Points for PBIs. Rather than one experienced engineer deciding "this is 5 points," all members simultaneously reveal their cards and reach consensus.

Why the "Poker" Format?

To prevent the "anchoring effect," where people get pulled toward the opinions of the most vocal or most experienced person. If someone says "this is 8 points, right?" beforehand, other members find it hard to say "I think it's 3." Everyone shows their cards simultaneously to prevent this.

How It Works (FitLog Team Example)

Cards use the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, ?, ☕). "?" means "I don't know," and "☕" means "I need a break."

Step 1: Explain the PBI

PO Alex: "Next is 'Send push notification reminders.' If a user has set a time and hasn't logged a workout that day, send them a notification."

Step 2: Q&A

Developer Chris: "Can the notification message be customized?"
PO Alex: "No, a fixed message is fine."
Developer Riley: "Are we planning to use the existing notification infrastructure on the server side?"
PO Alex: "Yes, assuming we use the existing infrastructure."

Step 3: Everyone Shows Cards Simultaneously

Step 4: Have the Highest and Lowest Explain

Lowest, Riley: "The BE side is just adding a call to the existing notification infrastructure, so 3."
Highest, Tyler: "On Android, I need to implement 3 things: saving user settings, a periodic job, and notification handling. I've struggled with similar things before, so I gave it 13."

Step 5: Re-vote After Discussion

After discussion, everyone converges around "8." Final agreement on 8 points.

Key Points

• Don't rush voting: Show cards only after Q&A aligns the assumptions
• Don't blame the person who diverged: Divergence is due to information gaps; sharing that information is the goal
• Don't spend too much time: Aim for 5–10 minutes per PBI. PBIs that can't be decided go back to Refinement.

Backlog Refinement

What It Does

Refinement is the ongoing activity of grooming the Product Backlog. Specifically:

• Split PBIs that are too large
• Clarify acceptance criteria for top PBIs
• Remove outdated PBIs
• Estimate (often used as a Planning Poker session)

When to Do It

The Scrum Guide doesn't define it as an independent event, but most teams dedicate 1–2 hours weekly. Many teams schedule it around the middle of the Sprint.

Definition of Ready

A concept sometimes discussed in contrast to the DoD in practice is the Definition of Ready. The idea is that once a PBI reaches a Ready state through Refinement, it can be brought to Planning.

FitLog team's Ready definition example:

• Written in User Story format
• Has 3 or more acceptance criteria
• All team members understand the content
• Split to 8 points or less
• If there are external dependencies, they have been agreed upon

The INVEST Principle (Deep Dive)

The 6 qualities a good PBI should satisfy. Let's look at each with examples.

User Story Hierarchy — Theme, Epic, Story, Task

The Product Backlog is a one-dimensional list, but in practice it's often thought of in 4 levels.

Theme: Improve user engagement
└─ Epic: Mechanisms to promote training continuation
   ├─ User Story: Can see progress for past 30 days via graph [8 pt]
   │  ├─ Task: API implementation
   │  ├─ Task: iOS UI implementation
   │  └─ Task: Android UI implementation
   ├─ User Story: Can receive reminder notifications [8 pt]
   └─ User Story: Display consecutive days recorded [3 pt]

PBIs that appear in the Backlog are mainly Epics and User Stories.

Burndown Chart / Burnup Chart

Burndown Chart

A graph that visualizes the progress of remaining work during a Sprint. You observe how actual progress moves relative to the ideal line (a line that decreases evenly).

Remaining pt
24┤●
22┤  ●
20┤    ●─ Ideal line ────
18┤      ╲╲
16┤        ●(Actual, slightly behind)
14┤          ●
12┤            ╲
 0┤──────────────●
    Day1 Day3 Day5 Day7 Day10

If the actual line stays above the ideal line → sign that the Sprint Goal is at risk. Consider acting early (scope reduction, requesting help).

Burnup Chart

A chart that displays completed work and scope on separate lines. It's easier to see the situation than a Burndown when scope changes occur, so it's often used for tracking release plans.

MVP and MMP

MVP (Minimum Viable Product)

The minimum product needed to validate a hypothesis. A concept popularized by Eric Ries's "The Lean Startup."

FitLog's MVP example: "Users can open the app, manually record running distance, and view a list of past records." No graphs, notifications, or social features. Use this to validate the hypothesis "Will people pay for a training tracking app?"

MMP (Minimum Marketable Product)

The minimum product that can be sold on the market. A step richer than MVP. MVP is for internal/limited user validation; MMP is for general release.

Timebox

Scrum events have maximum time limits. This is the timebox.

Effects of timeboxing:

• Prevents discussion from spreading: Limited time forces focus on essentials
• Prevents meetings from growing: Allowing extensions leads to infinite growth
• Finishing early is OK: If the goal is achieved, it can be shorter

Spike

Time-boxed work done to investigate technology or resolve uncertainty. A term originating in XP but widely used in Scrum.

When to use it:

• "It's unclear whether this can be achieved with the new library" → Validate in a 1-day timebox
• "Can't gauge the refactoring cost of this part of existing code" → Investigate for half a day
• "It's unclear whether API response speed meets requirements" → Build a prototype

The deliverable of a spike is knowledge, not code. Code written for validation is basically discarded.

WIP Limit (Work In Progress Limit)

A rule that limits the number of items being worked on simultaneously. Originated from Kanban but increasingly adopted in Scrum teams.

Example: "A maximum of 3 items in the 'In Progress' column at a time"

Effects:

• Focus on completion: Delivering 3 items completely is more valuable than partially advancing 5
• Bottlenecks become visible: Where things get stuck becomes clear
• Reduces multitasking costs: Context switching significantly reduces productivity

Technical Debt

A concept, coined by Ward Cunningham, that uses debt as a metaphor for the state where you'll have to pay interest (additional costs) later because you took a shortcut at the cost of future maintainability.

Types:

• Intentional debt: Implemented hastily with full awareness: "Shipping deadline first, refactor later"
• Unintentional debt: Arising from lack of knowledge or design mistakes
• Environmental debt: Arising relatively as surrounding technology becomes outdated (legacy)

Other Useful Terms to Know

Common Misconceptions and Pitfalls

"Don't Write Documentation" Is Wrong

Misinterpreting the Agile Manifesto's "working software over comprehensive documentation," some teams charge ahead with zero documentation. The correct interpretation is write the documentation necessary for operation.

"Don't Plan" Is Also Wrong

Abandoning planning while hiding behind "responding to change" is also wrong. Scrum has planning at multiple levels (Product Goal, Sprint Goal, daily plan). Agile doesn't mean not planning; it means adaptive planning.

The Daily Scrum Becomes a Status Report

A Daily Scrum that has turned into a progress report meeting for the PM or manager has lost its original purpose. The Daily is a place for inspection and adaptation by developers, for developers.

Sprint Length Changes Frequently

Changing Sprint length to "3 weeks this time because we're busy" or "let's try 1 week next time" makes it impossible to measure velocity (team speed). Sprint length should be fixed.

Cases Where Agile/Scrum Doesn't Fit

It's not a silver bullet. In situations like the following, a different approach may be more appropriate:

• Requirements are completely fixed with virtually no changes expected (e.g., regulatory compliance)
• Areas where safety is extremely critical and incremental releases are not permitted
• Cases where the team is extremely large and coordination costs outweigh the benefits

However, since scaling methods for large-scale Scrum (LeSS, SAFe, etc.) exist, it's premature to immediately conclude "too big for this."

Summary

• Agile is a mindset and set of values. The core is "deliver working software in short cycles" and "welcome change."
• Scrum is a representative framework for practicing Agile.
• Scrum consists of "3 Accountabilities, 5 Events, and 3 Artifacts" and repeats fixed-period Sprints.
• Copying only the form leads to empty ritual. Understanding the values comes first, the framework comes after.

The goal is not "to do Scrum" but "to continuously deliver valuable products." Thinking of the framework as a tool for that purpose is, I believe, the key to a long-lasting relationship with it.

References

• Agile Manifesto
• Scrum Guide 2020
• Jeff Sutherland, "Scrum: The Art of Doing Twice the Work in Half the Time"