Scrum in Practice

Meet Team Phoenix — they "do Agile"

Team Phoenix builds a fitness app. They have a daily standup at 9:15 a.m. Every morning, seven people crowd around a monitor, mumble what they did yesterday, and scatter back to their desks. That's it. That's the whole process.

There's no sprint. Work just... flows in. The CEO texts the lead developer at 11 p.m. with "urgent" feature ideas. Nobody knows what's being released or when. A designer finished three screens two weeks ago — nobody's reviewed them. The QA engineer has nothing to test because nothing is "done." When someone asks "are we Agile?", the manager says "yes — we do standups."

This is Agile in Name Only — sometimes called AINO. It's like calling yourself a chef because you own a frying pan.

Real Scrum is a structured framework with specific roles, events, and artifacts. It's not "just be flexible" or "have meetings." It's a disciplined system for delivering working product in short, predictable cycles.

By the end of this module, you'll know exactly what real Scrum looks like — and you'll be able to spot the fakes from a mile away.

The 3 Scrum roles: who does what

Scrum has exactly three roles. Not four, not seven. Three. Each has a distinct job, and confusing them causes the kind of dysfunction you saw in Team Phoenix.

Product Owner — the "what" person

The Product Owner decides what the team builds and in what order. They own the Product Backlog (more on that later) and represent the voice of the customer, the business, and the stakeholders — all at once.

The analogy: Think of a restaurant owner who writes the menu. They don't cook the food (that's the kitchen team). They don't manage the kitchen schedule (that's the head chef). But they decide what dishes go on the menu, which ones get featured, and which ones get dropped when they don't sell. They know the customers, they know the market, and they make the hard calls about what gets prioritized.

A good Product Owner says "no" more often than "yes." Every feature request, every CEO midnight text, every stakeholder wish — it all goes through the PO, who ranks it against everything else. One person. One backlog. One source of truth.

Scrum Master — the "how" person

The Scrum Master helps the team follow the Scrum framework and removes obstacles that slow them down. They are not a project manager. They don't assign work. They don't approve timesheets. They don't report status to executives.

The analogy: A sports coach. The coach doesn't play the game — the team does. The coach teaches technique, watches for bad habits, and creates the conditions for the team to perform at their best. When the stadium lights go out mid-game, the coach doesn't score goals — they get someone to fix the lights so the team can keep playing.

Common blockers a Scrum Master might remove:

• A third-party API team hasn't responded in five days — the SM escalates
• The standup is running 30 minutes — the SM refocuses it
• Two developers are stuck in a design argument — the SM facilitates a decision
• The Product Owner keeps adding work mid-sprint — the SM protects the sprint commitment

Development Team — the "do" people

The Development Team does the actual work: design, code, test, document — whatever it takes to deliver a working product increment. They are self-organizing (they decide how to do the work) and cross-functional (the team collectively has all the skills needed).

The ideal size is 3 to 9 people. Fewer than 3 and you lack enough skill diversity. More than 9 and communication overhead explodes — every person you add creates new communication lines, and beyond 9 the standup alone becomes a slog.

There Are No Dumb Questions

"Can the Scrum Master also be a developer?"

Technically yes, and it happens in small startups. But it's not ideal — it's like being a player-coach. When you're deep in a coding problem, it's hard to simultaneously notice that the team's standup has become a 40-minute status report. If you have to double up, be deliberate about switching hats.

"What if the Product Owner and the CEO disagree on priorities?"

The PO should have the authority to make prioritization decisions without needing CEO approval for every item. If the CEO overrides the PO constantly, the PO is a secretary, not an owner. That said, the PO should absolutely align with business strategy — they represent business interests, they don't ignore them.

The 5 Scrum events: what happens and when

Scrum runs in Sprints — fixed-length cycles of 1 to 4 weeks (two weeks is the most common). Within each Sprint, four events happen. The Sprint itself is the fifth event — the container that holds everything else.

1. Sprint Planning — "What will we accomplish?"

The whole Scrum team meets at the start of each Sprint. The Product Owner presents the highest-priority items from the Product Backlog. The Development Team discusses what they can realistically commit to. Together, they define a Sprint Goal — one clear sentence describing what the Sprint will achieve.

Time-box: Maximum 8 hours for a 4-week Sprint. For a 2-week Sprint, roughly 4 hours.

The output is the Sprint Backlog — the list of items the team commits to delivering.

2. Daily Standup — 15 minutes, standing up

Every day, same time, same place, 15 minutes maximum. Each team member answers three questions:

1. What did I do yesterday that helped the team meet the Sprint Goal?
2. What will I do today to help the team meet the Sprint Goal?
3. Is anything blocking me?

That's it. This is not a status report to a manager. It's a coordination meeting for the team. If a detailed discussion needs to happen, take it offline — "let's talk after standup" is the magic phrase.

Why standing? Because when people sit down, meetings last forever. Standing creates mild physical discomfort that keeps things short. It's a silly trick, and it works.

3. Sprint Review — "Here's what we built"

At the end of the Sprint, the team demos working product to stakeholders. Not a slideshow. Not a PowerPoint. Actual working software (or whatever the product is). Stakeholders give feedback, ask questions, and see real progress.

Time-box: Maximum 4 hours for a 4-week Sprint.

This is where you find out whether what you built is actually what the customer wanted. Spoiler: it often isn't quite right — and that's fine. The point of short sprints is to be wrong cheaply, then adjust.

4. Sprint Retrospective — the team's therapy session

After the Review, the team meets privately (no stakeholders) and asks three questions:

1. What went well this Sprint?
2. What went wrong this Sprint?
3. What will we improve next Sprint?

The Retrospective is where continuous improvement actually lives. A team that skips retros is a team that makes the same mistakes over and over. It's like never checking your rearview mirror — you'll eventually crash into something you should have seen.

Time-box: Maximum 3 hours for a 4-week Sprint.

5. The Sprint itself — the container

The Sprint is the heartbeat of Scrum. Every 1-4 weeks, you plan, build, review, and reflect. Then you do it again. No work happens outside a Sprint. No goals change mid-Sprint (barring genuine emergencies). The Sprint is a protected bubble of focus.

There Are No Dumb Questions

"What if we finish everything early in a Sprint?"

Great — pull the next highest-priority item from the Product Backlog. The Sprint is a commitment to a goal, not a commitment to exactly X number of hours of work. Finishing early means you estimated well or got lucky. Either way, don't sit idle.

"Can you cancel a Sprint?"

Yes, but only the Product Owner can do it, and it should be extremely rare. It happens when the Sprint Goal becomes obsolete — for example, a competitor launches the exact feature you're building, or a major pivot happens. Cancelling a Sprint is like pulling the emergency brake on a train. It works, but everyone feels it.

The 3 Scrum artifacts: what you produce

Artifacts are the tangible things Scrum creates and maintains. There are exactly three.

Product Backlog — the wish list

An ordered list of everything the product could ever need: features, bug fixes, improvements, technical debt. The Product Owner owns it, constantly re-prioritizes it, and refines it. It's never "done" — as long as the product exists, the backlog grows and shifts.

The analogy: A restaurant's master recipe book. It has every dish the owner might ever want to serve — hundreds of ideas. But the menu (the Sprint Backlog) only shows the 15 dishes they're actually making this week.

Sprint Backlog — this week's grocery list

The subset of Product Backlog items the team has committed to for this Sprint, plus a plan for delivering them. The Development Team owns it. Nobody — not the Product Owner, not the CEO, not the Scrum Master — adds items to the Sprint Backlog mid-sprint without the team's agreement.

Increment — the dish you serve

The sum of all Product Backlog items completed during a Sprint, plus all previous Sprints. At the end of every Sprint, the Increment must be in a potentially releasable state. It doesn't have to be released — but it must be able to be released. This is what "Done" means in Scrum.

User Stories: writing requirements that humans can read

Scrum teams write requirements as User Stories — short descriptions of a feature from the perspective of the person who wants it.

The format: "As a [role], I want [feature], so that [benefit]."

Examples:

• "As a new user, I want to sign up with my Google account, so that I don't have to remember another password."
• "As a team lead, I want to see each member's task progress, so that I can spot blockers before the standup."
• "As a shopper, I want to filter products by price range, so that I only see items I can afford."

Notice: every story explains who wants it, what they want, and why. The "why" is crucial — without it, the team builds features in a vacuum.

The INVEST criteria — what makes a good story

Good user stories follow INVEST:

**I — Independent.** Stories should not depend on each other. You can build them in any order.

**N — Negotiable.** Stories are conversation starters, not contracts. Details get refined during planning.

**V — Valuable.** Every story must deliver value to a user or the business. "Refactor the database" is not a story unless you can explain *who* benefits and *how*.

**E — Estimable.** The team must be able to estimate the effort. If nobody can guess the size, the story needs to be broken down or researched first.

**S — Small.** A story should fit within a single Sprint. If it can't, split it into smaller stories.

**T — Testable.** You must be able to write a test or define acceptance criteria that prove the story is done.

Story Points & estimation: why hours lie

How do you estimate how long a user story will take? Most people's instinct is to say "that'll take about 3 days." But hours and days are terrible for estimation, because:

• A senior developer might finish in 2 days what a junior takes 5 days to do
• Interruptions, meetings, and context-switching eat into "actual" work time unpredictably
• People consistently underestimate — studies show developers are optimistic by 25-50%

Instead, Scrum teams use Story Points — a measure of relative effort, not time.

The analogy: Imagine you're moving house. You look at a bookshelf, a sofa, and a grand piano. You don't estimate "the piano will take 47 minutes." You say: "If the bookshelf is a 2, the sofa is a 5, and the piano is a 13." You're comparing items to each other, not predicting clock time. Once you know how many "points" you moved last Saturday, you can predict how many you'll move next Saturday.

Common scales:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21 (gaps get bigger as uncertainty grows — there's no meaningful difference between 14 and 15, but a big difference between 8 and 13)
• T-shirt sizes: XS, S, M, L, XL (simpler, less precise, good for early estimates)

Sprint velocity: your team's speedometer

Velocity is the number of Story Points the team completes per Sprint. After a few Sprints, a pattern emerges: "We tend to finish about 30 points per Sprint." This becomes the team's velocity — a planning tool, not a performance metric.

Velocity is useful for:

• Predicting how many Sprints a set of features will take
• Noticing trends ("velocity dropped — something changed")
• Sprint Planning ("we do about 30 points — let's not commit to 50")

Common Scrum anti-patterns — and how to fix them

Real teams break Scrum in predictable ways. Here are the most common anti-patterns and what to do about them.

There Are No Dumb Questions

"Our Sprints always feel rushed at the end. Is that normal?"

It's common, but not healthy. If you're consistently cramming at the end of every Sprint, you're overcommitting. Lower the number of points you commit to. A team that consistently delivers 25 points is more reliable (and less stressed) than a team that commits to 35 and scrambles to finish 28.

"Do we have to use Scrum exactly as described? Can we adapt it?"

Scrum's creators say: try it by the book first. Once you understand why each piece exists, you can make informed modifications. Teams that modify Scrum before understanding it usually end up removing the parts that hurt (retros, sprint commitments) and keeping the parts that are easy (standups). That's how you get Team Phoenix.

Back to Team Phoenix

Team Phoenix had daily standups and called themselves Agile. They had no sprints, no backlog, no Product Owner, no demo, and no retrospective. The CEO texted features at 11 PM and nobody knew what was being released or when. Real Scrum would have given them a Product Owner to say "no" to midnight feature requests, a Sprint to protect the team's focus, a Review to demo working product, and a Retrospective to improve every two weeks. The standups were not the problem — they were the only ceremony the team had, and one ceremony out of five is not a framework. It is a frying pan without a kitchen.

Key takeaways

• Scrum has 3 roles (Product Owner, Scrum Master, Development Team), 5 events (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective, and the Sprint itself), and 3 artifacts (Product Backlog, Sprint Backlog, Increment).
• The Scrum Master is not a project manager. They coach, facilitate, and remove blockers — they don't assign work or demand status.
• User Stories follow "As a [role], I want [feature], so that [benefit]" and should meet the INVEST criteria.
• Story Points measure relative effort, not hours. Velocity is points completed per Sprint — a planning tool, never a cross-team comparison.
• Every Sprint ends with a potentially releasable Increment. If it's not releasable, it's not really "done."
• Skip the retrospective at your peril. A team that never reflects is a team that never improves.