Agile Complete Mastery Part 2: Scrum, the Secret to Faster Execution Than Planning

Introduction: Mindset Alone Is Not Enough

In Part 1, we explored why Agile was born and what its 4 core values are.

But this question remains: "Okay, I understand the philosophy. So what am I supposed to do when I come to work tomorrow?"

If Agile is an engine, Scrum is the gear that actually makes that engine run. It's the most widely used Agile framework that converts abstract values into concrete meetings, roles, and deliverables.

There's research showing that approximately 87% of Agile teams worldwide use Scrum, making Scrum the de facto standard implementation of Agile. After reading this article, you'll not only understand Scrum theoretically but will be able to apply it to your team tomorrow or use it on your own.

1. Why Is It Called Scrum?

The name Scrum comes from rugby. In rugby, a scrum is a large formation where both teams come together and compete for the ball, with the entire team putting their shoulders together and cooperating to advance the ball.

The reason this name was adopted for software development is clear.

If traditional Waterfall is like a relay race (A must finish before B starts), Scrum is rugby. The entire team moves simultaneously, and when circumstances change, direction shifts immediately. It's not a structure where one person becomes a hero, but rather one where the entire team pushes in the same direction.

The Theoretical Root of Scrum: Empiricism

Scrum is built on three pillars.

Transparency: All situations of the project are shared by the entire team. Facts like progress being delayed or specific features being more complex than expected are not hidden. The earlier you share uncomfortable truths, the more time you have to respond.
Inspection: You periodically check whether you're moving in the right direction toward your goal. The essence of inspection is directly examining the deliverable at the end of each sprint.
Adaptation: If inspection reveals that a course correction is needed, you change direction immediately. Adhering to the original plan is not a virtue. The core capability of Scrum is to quickly adjust to reality.

These three are not mere principles. Every event and artifact in Scrum is designed around these three pillars.

2. Scrum Components: The 3-5-3 Rule

The entire structure of Scrum is simple. 3 roles, 5 events, 3 artifacts. That's all there is.

What these numbers signify is that Scrum was intentionally designed to be simple. Born from a reflection on the existing approach bogged down by complex processes and documentation, Scrum itself is remarkably lightweight.

3. Three Core Roles

Role 1. Product Owner (PO)

In a word, the PO is the person responsible for the direction of the product. They decide what to build and in what order.

The PO's core tool is the Product Backlog. All necessary features and requirements for the product are gathered in one place, with priorities continuously adjusted. The PO's most important role is to ensure the team is doing the most valuable work at this moment.

There are two common misconceptions about the PO.

First, the PO does not instruct the development team on "how to build." The PO only defines what and why to build; the team decides the method.

Second, the PO is not someone who accommodates all customer requirements. It's the opposite. From dozens of requirements, selecting the three most critical right now requires the courage to say no.

Role 2. Scrum Master (SM)

The SM is often mistaken for a project manager, but it's an entirely different role. The SM is not someone who assigns work to the team or receives progress reports.

The SM is a Servant Leader. They're the person who removes obstacles so the team can achieve its best performance.

Specifically, what the SM does is:

Guide the Scrum process to proceed correctly
Solve obstacles that emerge from Daily Scrums
Protect the team from external disruptions (urgent requests, scope expansion attempts, etc.)
Mediate conflicts or communication issues within the team
Coach teams that are newly adopting Scrum

When an SM does their job well, developers can focus solely on development. The SM handles logistics like scheduling meetings, convincing stakeholders, and preparing for the next sprint.

Role 3. Development Team

The people who actually build the product. It doesn't mean only developers. It includes all roles necessary to complete the product: designers, QA engineers, data analysts, etc.

The most defining characteristic of the development team in Scrum is self-organization. No one assigns daily tasks. The team itself looks at the backlog and decides what and how to do things this sprint.

The recommended size is 3-9 people. Fewer than 3 people reduces collaboration benefits, and more than 9 creates exponential communication complexity.

4. Five Events

Event 1. Sprint

The Sprint is the heart of Scrum. A 1-4 week fixed timeframe where the team runs toward a single goal in a repeating cycle.

The most important rule is fixing the duration. If this sprint is difficult, you don't extend the timeframe. Even if you reduce the goal, you keep the timeline. This fixed rhythm gives the team predictability and psychological stability.

If you're adopting Scrum for the first time, a 2-week sprint is recommended. 1 week is too short and you'll be rushed with planning and retrospectives, while 4 weeks is too long and feedback comes late.

At the end of a sprint, there must be a working deliverable. An 80% complete feature is not a deliverable. It's important for the team to agree in advance on the definition of completion.

Event 2. Sprint Planning

A meeting held before the sprint begins. The entire team collectively decides what to do and how to do it this sprint.

The meeting is divided into two parts.

Part 1 — What will we do?: The PO presents high-priority items from the backlog, and the team selects what can be completed this sprint. Past sprint velocity (the amount the team actually completed) is referenced here.

Part 2 — How will we do it?: The development team breaks down the selected items into specific tasks. The result becomes the Sprint Backlog.

For a 2-week sprint, it's recommended not to exceed 4 hours maximum.

Event 3. Daily Scrum

A brief synchronization meeting held within 15 minutes at the same time and place each day.

Just three questions:

① What work did I complete yesterday for our team goal?
② What work will I do today for our team goal?
③ Are there any obstacles blocking progress?

There's a common mistake here. Making Daily Scrum into a status report session. Team members aren't reporting to each other; the entire team is checking together whether they're moving properly toward the goal.

Also, don't try to solve obstacles that come up during Daily Scrum right then and there. It's enough to identify them. Resolution happens afterward among the relevant people separately. That's how you can stay within 15 minutes.

Event 4. Sprint Review

After the sprint ends, the team directly demonstrates the working deliverable and receives feedback from stakeholders.

The important point is that you're not preparing presentation materials. You show an actual working product. This difference is significant. Things that can be hidden in slides are revealed in actual demonstration.

Feedback from the review is reflected in the next sprint's backlog. This cycle makes the product evolve increasingly toward what customers want. For a 2-week sprint, a maximum of 2 hours is recommended.

Event 5. Sprint Retrospective

If the review examines the product, the retrospective examines how the team works.

It's conducted around three questions.

✅ What went well? (Continue to maintain)
🔧 What can be improved? (Change next time)
💡 What new thing should we try?

For the retrospective to not become just a formality, one thing must be observed. Exactly one improvement from the retrospective must be executed in the next sprint. Simply accumulating improvement lists doesn't change anything.

Also, retrospectives are not places to criticize individuals. You examine the process, not people. Asking "Why did this task take longer than expected?" rather than "Why was this worker late?" is the correct way to conduct a retrospective.

5. Three Artifacts

Artifact 1. Product Backlog

A list of all features, improvements, and bug fixes needed for the product. Owned and managed by the PO.

Backlog items are typically written in User Story format.

As a [user],
I want [feature],
so that [purpose].

Example: "As a shopping mall customer, I want to save my card information so that I can check out quickly."

This format is important because it focuses on the user's value, not the feature itself. It becomes clear why this feature is needed, not just "implement card save feature."

The backlog is a living document. New items are added each sprint, and items that are no longer needed are deleted. The PO continuously readjusts priorities.

Artifact 2. Sprint Backlog

An execution list of items actually to be done this sprint. It's a subset of the Product Backlog.

Selected together by the team during Sprint Planning, it's owned by the team during the sprint. Even the PO cannot change Sprint Backlog items during sprint execution. This is the key mechanism that protects team focus.

Artifact 3. Increment

The working deliverable that comes out at the end of each sprint. Incomplete or test-in-progress features are not included.

The team must agree on a Definition of Done before sprint begins.

✅ Code review completed
✅ Unit tests passed
✅ QA testing passed
✅ Staging environment deployment completed

Only features meeting these criteria are included in the increment. Without clear completion criteria, "almost done" goes on forever.

6. Why Scrum Fails

If you've adopted Scrum and things got harder instead, you likely fall into one of these patterns.

① When Daily Scrum degenerates into status reporting

If it becomes a reporting session to a manager, Daily Scrum becomes a time of fear. Instead of honest obstacle sharing, team members only say nice things. Daily Scrum is where team members synchronize for each other.

② When adopting Scrum without a PO

Without a clear decision-maker for priorities, the team loses direction. Everything becomes urgent and everything becomes important. If you have no real PO and the Scrum Master takes on both roles alone, problems will definitely arise.

③ When requirements keep changing during the sprint

Once a sprint begins, the team should be able to focus for that duration. If requirements keep getting added mid-sprint, the sprint becomes meaningless. Urgent requests should be added to the next sprint's backlog as a principle.

④ When conducting retrospectives formally

A retrospective that ends with "We did well this time. Let's work hard next time." is worse than having no retrospective. Improvement only happens when items from the retrospective are actually reflected in the next sprint.

7. Scrum for Solo Developers and Freelancers

Scrum isn't something you can only use if you have a team. It's perfectly applicable for solo developers, freelancers, and side projects.

The key is one thing. Switch roles by day of the week.

Time	Role	Task
Monday morning	PO mode	Select 3 priorities for this week's backlog
Tuesday-Thursday	Development team mode	Focus on executing only selected items
Friday afternoon	SM mode	This week's retrospective, next week's preparation

There's a reason Scrum is powerful for freelancers.

When you demonstrate working deliverables to clients every week, trust builds. Instead of "This isn't what we wanted" at final delivery, you get feedback every week and adjust direction. A 3-month project becomes 12 checkpoints.

Clients naturally start perceiving you not as a mere service provider but as a partner. This directly impacts rate negotiations and long-term contracts.

Closing

Scrum doesn't hide inefficiency. Instead, it's a mirror that reveals inefficiency.

When you first adopt Scrum, hidden communication problems, priority confusion, and technical debt surface. It's uncomfortable, but that's a signal that Scrum is working correctly.

What matters is not perfect Scrum. It's working in slightly better ways than yesterday. As you improve one thing each sprint, your team's way of working will be completely different in 6 months.

Delivering imperfect results weekly beats perfect planning.

If you fully understand Agile Mindset (Part 1) and Scrum Framework (Part 2) alone, you already understand Agile more deeply than many practitioners in the field.