What is Scrum — Roles and Outputs
Understand the structure of Scrum through three roles (PO, SM, Development Team) and three artifacts (Product Backlog, Sprint Backlog, Increment).
Agile Manifesto and Beyond: Understanding Scrum
After reading the Agile Manifesto, a question remains. "Okay, I understand the philosophy. So what exactly am I supposed to do when I come to work tomorrow?"
Scrum is the most widely used answer to this question. It's a framework that materializes the Agile mindset into concrete roles, meetings, and deliverables. While the name is familiar, many people don't actually know what it looks like in practice. It's common to think that Daily Scrum is all there is to Scrum, or to mistake a Scrum Master for a project manager.
When first learning Scrum, you don't need to memorize all the terminology at once. Once you grasp just three roles and three deliverables, the structure becomes clear.
Why is it Called Scrum?
The name Scrum comes from rugby. In rugby, a scrum is a formation where both teams put their shoulders together and push in one direction.
The reason this name was applied to software development is clear. If Waterfall is a relay race — A must finish before B can start — then Scrum is rugby. The entire team moves simultaneously, and when circumstances change, the direction shifts immediately. It's not a structure where one person becomes a hero, but a structure where the entire team moves together.
The Three Pillars of Scrum
Scrum is built on the philosophy of Empiricism. Instead of making a perfect plan in advance, it's an approach of learning and adjusting by actually doing. This philosophy is expressed through three pillars.
Transparency. The entire team shares all project information. Facts like development is falling behind, or a particular feature is more complex than expected, are not hidden. The earlier uncomfortable truths are shared, the more time there is to respond.
Inspection. It regularly checks whether you're moving in the right direction toward the goal. The core of inspection is directly examining the deliverables at the end of each sprint.
Adaptation. If inspection results show that course correction is needed, change direction immediately. Sticking to the original plan is not a virtue. Quickly adjusting to reality is the core competency of Scrum.
These three pillars are not mere principles. All of Scrum's roles, events, and deliverables are designed around these three pillars.
Three Roles
In Scrum, roles are not job titles.
They are not a mechanism to determine who is above and who is below, but a distinction to clarify who is responsible for what. Scrum has three roles: Product Owner, Scrum Master, and Development Team.
Product Owner
The PO is the person responsible for the product's direction. They decide what to build and in what order.
The PO's core tool is the Product Backlog. All features and requirements needed for the product are gathered in one place, with priorities constantly adjusted. The most important role of the PO is to ensure the team is doing the most valuable work at this moment.
There are two common misunderstandings about the PO. First, the PO does not tell the development team how to build. They only define what to build and why; the team decides how. Second, the PO is not someone who accepts all customer requirements. They must be able to select the most important ones from dozens of requirements and defer the rest.
Scrum Master
The SM is often mistaken for a project manager. But it's a completely different role. The SM is not a position that directs work to the team or receives progress reports.
The SM is a Servant Leader. They are the person who removes obstacles so the team can perform at their best. They guide the Scrum process to proceed correctly, actually solve obstacles raised in Daily Scrum, and protect the team from external disruptions. They mediate conflicts and communication issues within the team and coach teams new to Scrum.
In teams where the SM does their job properly, developers can focus more on building the product. This is because unnecessary meetings are reduced, conflicts with stakeholders are coordinated, and the environment is organized so the next sprint is not disrupted.
Development Team
The Development Team is 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, and so on.
The most distinctive characteristic of the Development Team in Scrum is self-organizing. No one assigns today's tasks. The team itself looks at the backlog and decides what and how to accomplish in this sprint.
Scrum teams shouldn't be too large. Too few people and necessary skills are lacking; too many and communication costs increase dramatically. Previously, teams of 3-9 people were often recommended, and the recent Scrum Guide typically assumes small teams of no more than 10 people.
Three Deliverables
Scrum's deliverables always keep visible what the team is currently moving toward. Everything to do, what to do this time, and what's done.
Product Backlog
A list of all features, improvements, and bug fixes needed for the product. It is owned and managed by the PO.
Backlog items are typically written in User Story format.
As a [user],
I want [feature],
So that [purpose].
For example:
As a shopping mall customer, I want to save my card information for quick checkout.
This format is important because it focuses on user value, not functionality. 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 unnecessary items are deleted.
Sprint Backlog
An action list of items the team will actually complete in this sprint. It's a subset of the Product Backlog.
The team selects items together in the Sprint Planning meeting, and owns them during the sprint. Even the PO cannot change Sprint Backlog items during sprint execution. This is the key mechanism for protecting the team's focus.
Increment
A working deliverable produced at the end of each sprint. Incomplete or in-testing features are not included.
The team must agree on the Definition of Done before starting the sprint.
✅ Code review complete
✅ Unit tests passed
✅ QA testing passed
✅ Staging environment deployment complete
Only features meeting these criteria are included in the increment. Without clear completion criteria, "almost done" goes on forever.
The Power of Simple Structure
Scrum's overall structure is intentionally simple. It was born as a reaction against existing methods that had become heavy with complex processes and documentation.
Three roles clarify who decides what. Three deliverables always make visible where the team is heading.
The simpler the structure, the more space the team has to focus on actual problems.
The purpose of Scrum is not to make the team busier. It is to create a rhythm of checking more frequently, learning faster, and fixing in smaller increments.