How Does Scrum Work — Five Events
Understanding the rhythm of repetition created by Scrum's five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) and how Scrum actually works in practice.
I understand the roles now. I understand what a product backlog is. But I'm still unsure about how Scrum actually 'works' in practice.
It's the five events of Scrum that create that rhythm. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Sprint itself—the container that holds all of these. Each is not an independent meeting, but rather parts that form one iteration cycle.
Sprint, the unshakeable minimum unit
The Sprint is the heart of Scrum. It's typically a fixed period of 1-4 weeks during which a team focuses on a single goal. The other four events all happen within this Sprint.
Why must it be short? To know when you're heading in the wrong direction. If you execute a six-month plan to completion only to realize "this wasn't it," it's too late. Checking every two weeks means you'll make at most two weeks' worth of mistakes. The shorter the Sprint, the faster you can course-correct from a wrong direction.
During a Sprint, goals don't change. Once a Sprint has started, the Sprint goal isn't easily shaken. When urgent requests come in, they usually go into the next Sprint's backlog. It's a fence to protect the team's focus.
How to open a Sprint
When a Sprint starts, the entire team gathers to decide what will be done in this Sprint—this meeting is called Sprint Planning.
Two things are decided. First is the goal. The PO brings high-priority items from the product backlog, and the team agrees on this Sprint's goal together. It's not simply a to-do list, but rather a time to agree on what we can say we've accomplished when this Sprint ends.
Second is the method. The development team breaks down the chosen items into concrete tasks for how to implement them. This result becomes the Sprint backlog.
There's a common mistake in Sprint Planning: enthusiastically putting in too much. A plan that doesn't reflect the team's realistic velocity leads to pressure and incomplete deliverables by the end of the Sprint.
The reason for 15 minutes daily
The Daily Scrum is a brief synchronization held at the same time and place every day for no more than 15 minutes. It's also an event that's often misunderstood.
It's not a progress report. It's not a place to tell the SM or team lead what you did yesterday—it's where team members align direction with each other. Traditionally, three questions have been used.
What did you do yesterday?
What will you do today?
Is there anything blocking you?
Recent Scrum Guides don't enforce this format. What matters is confirming you're moving properly toward the Sprint goal. Purpose comes before form.
The reason for strictly adhering to 15 minutes lies here too. This isn't a time to solve problems. It's a time to identify that problems exist. If deeper discussion is needed, the relevant people meet separately after the Daily Scrum ends.
A place to confirm what you've made
When a Sprint ends, Sprint Review is held with stakeholders to check the deliverables.
The development team shows what was created in this Sprint, and stakeholders provide feedback. This feedback is reflected in the product backlog and influences the direction of the next Sprint. Conversation with customers or business teams is the key mechanism for adjusting the product's direction.
What's important is showing what's actually complete. A feature that's "almost done, just needs a bit more" can't be the focus of the review. What stakeholders need to judge is an increment that's actually usable.
Sprint Review is not a meeting to prepare a presentation. The more effort a team puts into this, the higher the likelihood they're stealing time from development.
A place to fix how you work
Coming right after the Sprint Review, the Sprint Retrospective is a time to reflect on how the team works, not on the product itself.
Many confuse Review and Retrospective. Review asks "what did we make?" and Retrospective asks "how did we work?" Stakeholders participate in the Review, but the Retrospective happens only within the Scrum team. This is to enable honest conversation.
Usually, discussion centers on three things.
What went well?
What needs improvement?
What will we actually change in the next Sprint?
The last question is the key. A team that discovers problems but says "let's see next time" and puts it off isn't holding a Retrospective—they're just collecting grievances. Improvement items from the Retrospective must be reflected in the next Sprint immediately.
Many teams skip the Retrospective because they're exhausted by the end of the Sprint. And they repeat the same problems in the next Sprint. Scrum without Retrospective is a structure that only increases speed while repeating the same mistakes.
How Scrum falls apart
Some teams say that adopting Scrum made things harder. The reasons are usually similar.
Daily Scrum becomes status reporting. When a manager participates, it naturally becomes a reporting format. A 15-minute meeting becomes stressful, and team members focus on explaining what they did yesterday.
There's no Sprint goal. When backlog items are just added to this Sprint, the Sprint becomes a to-do list. Without a goal, there's no priority, and at the end of the Sprint it's hard to know what the team has accomplished.
Requirements keep changing during the Sprint. When stakeholders or the PO add or change items mid-execution, the team can't focus. This problem usually stems from the backlog for the next Sprint not being prepared.
Retrospective is skipped. The most common and most expensive mistake. When Retrospective disappears, the team repeats the same problems without officially facing the fact that they're repeating them.
Things you can use without a team
Scrum is a team framework, but solo developers or freelancers can also borrow its structure.
Set a Sprint in 1-2 week units and choose what to focus on within it. Every day, briefly organize what you did yesterday and what you'll do today. When the Sprint ends, confirm what you've completed and lightly reflect on what you'll do differently next time.
You can't run a complete Scrum alone. In a situation where you're both PO and SM, the roles blend together. But you can create a rhythm of completing small goals in short cycles, reviewing, and adjusting on your own. And that's the most essential part of Scrum.
When rhythm takes hold
As Sprints repeat, the team develops a rhythm.
The first few Sprints feel awkward. Daily Scrums feel awkward, it's hard to find things to say in Retrospectives, and Sprint Planning doesn't go as planned. But you keep repeating. When you see what's wrong, you fix it in the next Retrospective.
Scrum is not a perfect process. It's a tool for teams to find their own way within repetition. When this rhythm takes hold, even when change comes, the team won't be shaken and can move forward toward the next Sprint.
In the end, what Scrum creates is not meetings, but the rhythm of a team that keeps learning.