Scrum: Roles, Events, and Artifacts

A team works on a product for six months and has nothing to show the customer: everything is "almost done," but nothing has shipped. The requirements changed three times, part of the work was thrown away, and the deadlines slipped. A familiar story — and exactly the one Scrum tries to solve. It's not a set of rituals for the sake of rituals but a framework for iterative development: instead of a single long dash toward a distant goal, the team runs many short ones, and after each it has something that works.

In this article we'll take Scrum apart piece by piece: why short iterations are needed, who's responsible for what, which artifacts the team maintains, and which meetings it runs. And most importantly — which mistakes turn Scrum from a useful framework into bureaucracy.

The idea: short iterations with a finished result

The central concept in Scrum is the sprint. It's a fixed span of time, usually one or two weeks, during which the team builds part of the product. The key word is "fixed": the length of a sprint doesn't move. If the work isn't finished in time, you don't push the deadline — you push the work itself into the next sprint.

The result of every sprint is an increment: a piece of the product brought to the state of "it works and can be shown." Not "we wrote the code but didn't test it," not "we built the layout but didn't wire it up" — but genuinely finished, verified functionality. Even if it's small.

Why such discipline? It gives feedback. After each sprint you see real progress, not a rough guess. The customer looks at a working product and adjusts course while changes are still cheap. A mistake in the requirements surfaces in two weeks rather than in six months. It's the same principle as in other development models: the shorter the feedback loop, the cheaper the mistakes.

Roles: who owns "what," "how," and the process

Scrum has three roles, and they split the responsibility so that no one pulls the blanket their way.

Product Owner owns the "what and why." They decide which tasks matter more, articulate their value to the business and the user, and maintain the list of requirements. Their job is to make sure the team is always working on the most needed thing right now. The Product Owner doesn't dictate how to write code — they bring problems and priorities, not ready-made technical solutions.

Scrum Master owns the process. They're not a boss and they don't hand out tasks — their job is to make sure Scrum works as intended and that nothing gets in the team's way. Access got blocked, a neighboring department is dragging its feet, meetings have turned into a swamp — that's their domain. In essence, the Scrum Master removes impediments and shields the team from outside interference.

Development team owns the "how." These are the people who build the increment: developers, testers, whatever specialists are needed. The team itself decides how to do the work and how much to take into a sprint. It self-organizes — no one from outside distributes tasks among people.

The split is simple: the Product Owner brings the "what," the team decides the "how," and the Scrum Master makes sure the mechanism doesn't jam.

Artifacts: what the team maintains on paper and in code

Artifacts are what makes the work visible. There are four of them.

Product Backlog — a single ordered list of all ideas, requirements, and fixes. The most important items sit at the top, the ones that can wait at the bottom. The list is alive: priorities shift, things get added, things get dropped.

Sprint Backlog — what the team committed to doing this sprint, together with a plan. It's formed during planning and isn't topped up from outside during the sprint.

Increment we've already covered — it's the result of the sprint.

Definition of Done — the agreement on what "done" means. For example: the code is written, covered by tests, has passed review, and is deployed to a test environment. Without a single DoD, everyone understands "done" their own way, and the increment turns out unreliable.

Events: five meetings and why each exists

Scrum sets the rhythm through five events. Each solves a specific problem, not "because that's how it's done."

• Sprint — the iteration itself, the container for everything else. It begins with planning and ends with a review and a retrospective.
• Sprint Planning — at the start of the sprint the team and the Product Owner decide what goes into the sprint and how to do it. The output is a Sprint Backlog and a clear goal.
• Daily Scrum — a short, up-to-15-minutes team sync. Everyone checks: are we moving toward the sprint goal, and where are we stuck? It's a conversation the team has with itself, not a report to someone.
• Sprint Review — at the end of the sprint the team shows the increment to interested people and gathers feedback. Here they decide where to head next and adjust the Product Backlog.
• Retrospective — the team discusses not the product but the process itself: what worked, what got in the way, what to improve in the next sprint. It's a built-in mechanism for self-improvement.

The first four events are about the product, the last is about how the team works. The retrospective is the easiest to drop from the schedule "to save time," and that's exactly why the team stops growing.

Common mistakes that break Scrum

Scrum is easy to imitate by repeating the outward rituals and losing their meaning. A few typical failures.

Daily Scrum as a report to the boss. Everyone in turn reports to the manager what they've been doing. The point of the meeting is to sync the team, not to control it. The moment the Daily turns into a status meeting with reports, people start reporting "nicely" instead of solving problems, and the meeting becomes empty.

A sprint without a Definition of Done. The team "closes" tasks, but no one agreed on what "closed" means. As a result, the increment is assembled from half-finished pieces: tests missing here, not checked on the environment there. There's nothing to show, and the debt piles up. The DoD is the insurance against "almost done."

The "dictator" Product Owner. The Product Owner doesn't just set priorities but meddles in how the team does the work: dictates technical decisions, assigns tasks to people, pressures with deadlines. The roles blur, the team loses ownership of the "how," and stops self-organizing. The Product Owner is responsible for value, not for engineering decisions.

The common root of all three mistakes is the same: the ritual remains while its purpose is lost. Scrum works not because there are meetings and lists, but because behind every element stands a concrete goal — feedback, transparency, distributed responsibility.

In short

• Scrum is a framework for iterative development: the product is built in short fixed iterations (sprints), each yielding a finished increment.
• Three roles: the Product Owner owns "what and why," the team owns "how," and the Scrum Master keeps the process from jamming.
• Four artifacts: Product Backlog (everything by priority), Sprint Backlog (taken into the sprint), Increment (the result), and Definition of Done (when something is "done").
• Five events: the Sprint and, inside it, Planning, Daily Scrum, Review, and Retrospective — each with its own goal.
• The point of short iterations is fast feedback: mistakes surface in weeks rather than in months.
• The Daily Scrum is a team sync, not a report to the manager.
• Without a Definition of Done the increment is unreliable, and a "dictator" Product Owner breaks the team's self-organization.

What to read next

• Kanban
• Estimation and Planning
• Development Models