Book Notes #21: Essential Scrum by Kenneth S. Rubin

Title: Essential Scrum: A Practical Guide to the Most Popular Agile Process
Author: Kenneth S. Rubin
Year: 2012
Pages: 504

Essential Scrum isn’t a book about rules—it’s a book about better ways of thinking, working, and improving together. It respects your time, trusts your intelligence, and meets you where you are.

Whether you’re just dipping your toes into Agile or leading a full transformation, this book gives you both the mindset and the map to take the next step.

And once you finish it, you’ll see that the real journey is just beginning.

As a result, I gave this book a rating of 8.0/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Essential Scrum

Book Overview

That’s the quiet question running through Essential Scrum. On the surface, it’s a guide to one of the world’s most popular Agile frameworks. But as you read through it, chapter by chapter, something deeper starts to emerge.

It’s not just about roles, backlogs, and sprints—it’s about rethinking how we approach uncertainty, how we plan, how we lead, and ultimately, how we work together.

Kenneth Rubin doesn’t try to impress with jargon or drown you in theory. Instead, he builds a case for why agility matters—using simple language, real stories, and a structure that guides you gently but firmly from concept to practice.

It feels less like a textbook and more like a conversation with someone who’s been in the trenches, seen the chaos, and found a better way forward.

At the heart of Scrum is a surprisingly human idea: we can’t predict everything. And that’s okay.

Rather than trying to lock down scope, budget, and time from day one, Scrum invites us to work in short cycles, learning as we go, adjusting our plans based on real feedback—not just assumptions.

But that doesn’t mean there’s no structure. Quite the opposite. Rubin shows how structure—when it’s designed for adaptability—can be liberating. Roles like the Product Owner, ScrumMaster, and Development Team aren’t just titles; they represent a shift in mindset.

The Product Owner brings focus, constantly prioritizing based on value. The ScrumMaster clears the path, removing obstacles and coaching the team. And the team? They self-organize, plan their own work, and own the outcomes.

One of the most eye-opening ideas is how Scrum redefines planning. In traditional approaches, planning is a front-loaded marathon. In Scrum, it’s a rhythm—happening at multiple levels, from strategic portfolio planning down to daily standups.

Rubin likens it to skiing: you plan your first few turns, but the rest depends on the terrain ahead.

You respond, adapt, and adjust course continuously. That mindset—embracing uncertainty instead of fearing it—is a thread that runs throughout the book.

And then there’s the sprint. It’s where the magic happens. Every two weeks (or whatever cadence you choose), the team picks a goal, commits to delivering something potentially shippable, and gets to work.

There’s a flow to it—planning, execution, review, and reflection. What’s refreshing is how much Rubin respects the people doing the work. He trusts that given the right environment, teams will rise to the challenge.

And the book offers plenty of guidance on how to create that environment—whether it’s swarming to finish tasks, holding honest retrospectives, or learning how to say no to overcommitment.

One story that stuck with me was how teams sometimes hold on to rituals from other cultures—like passing a toy moose to decide who talks in a daily scrum—without understanding the context.

Rubin gently reminds us that agility isn’t about copying someone else’s method. It’s about discovering your own. What works for one team might flop for another.

And that’s okay. The goal is to inspect, adapt, and grow—not to follow a rigid playbook.

The final chapters pull the lens back, encouraging us to see Scrum not just as a framework, but as a tool for organizational transformation. You don’t change overnight. You don’t plan it all up front.

You start with one team, learn what works, and expand from there. You use Scrum to transform Scrum itself. That idea—using agility to become more agile—is both brilliant and deeply practical.

Rubin doesn’t pretend it’ll be easy. Scrum exposes problems. It shines a light on dysfunctions that are often easier to ignore. But by facing them, one sprint at a time, teams and organizations get better. Not perfect. Just better. And that, really, is the point.

It’s easy to close Essential Scrum, feel inspired, and then… get pulled right back into the same old chaos. Meetings pile up. Deadlines loom. The team’s still asking, “What exactly are we doing this week?” So how do you actually take what Kenneth Rubin teaches and put it to work?

The good news? You don’t need a company-wide transformation or a perfect team to get started. You just need the willingness to try, learn, and adjust. One step at a time.

Step 1: Start with “Why” – Before diving into sprints or story points, pause and ask: why are you doing this? Maybe your team is overwhelmed. Maybe your projects always run late. Maybe communication is all over the place. Identify your pain points—not to fix them all at once, but to give your Scrum journey a purpose. Without that, it’s just another process. With it, it’s a change that matters.

Step 2: Form a Real Scrum Team – You don’t need a huge group or perfect structure. You need three things: someone to act as Product Owner (who decides what’s most important), someone to be ScrumMaster (who helps remove obstacles), and a small team willing to try something new. Don’t wait for titles to be official. Play the roles. Learn as you go. The team is the engine—get them talking, planning, and working together.

Step 3: Build Your First Product Backlog – You don’t need a fancy tool—just a clear list. What work needs to be done? Write down the tasks, features, or improvements, and start organizing them by value and urgency. The backlog isn’t static. It will grow, shrink, and shift. That’s the point. But having one place where priorities live will already be a huge win.

Step 4: Plan a Sprint (and Keep It Simple) – Pick a short timeframe—maybe one or two weeks. At the start, hold a sprint planning session. The Product Owner brings the priorities. The team picks what they believe they can finish. Don’t overthink it. Focus on a clear, shared sprint goal: something meaningful to deliver by the end of the sprint. Then break it down into smaller tasks and get to work.

Step 5: Meet Daily, But Keep It Light – Hold a 15-minute daily check-in. Not a status meeting. A sync. Everyone answers: What did I do yesterday? What will I do today? Is anything in my way? That’s it. This rhythm helps uncover blockers early and builds team awareness. Over time, it becomes a powerful pulse that keeps everything moving.

Step 6: Review. Reflect. Adjust. – At the end of the sprint, bring people together for two short but powerful rituals. First, the Sprint Review: show what got done, get feedback, talk about next steps. Then, the Sprint Retrospective: a space just for the team to ask—what went well, what didn’t, and what can we improve? This is where the magic happens. You’re not just delivering work. You’re learning how to work better, together.

Step 7: Repeat—with Curiosity – Scrum isn’t about doing it “right.” It’s about doing it better. Every sprint is a chance to improve—your process, your collaboration, your product. So don’t get stuck chasing perfection. Focus on small gains. Trust your team. Keep adapting. That’s the Scrum mindset Rubin wants you to build.

Step 8: Make It Yours – Eventually, you’ll face decisions. Should you use story points or time estimates? Is two weeks the right sprint length? How do you handle dependencies between teams? Don’t just follow a recipe. Go back to the principles. Ask what supports learning, feedback, and delivery. Use Scrum as a starting point—not a cage.

Step 9: Invite Others – Once your team is rolling, others will notice. Share what you’re learning. Invite leaders to a sprint review. Offer to help another team build a backlog. Slowly, your little experiment becomes a movement. This is how organizations change—not through mandates, but through momentum.

Step 10: Stay Patient, Stay Honest – Some sprints will flop. Some changes won’t stick. That’s okay. The goal isn’t to do Scrum perfectly—it’s to keep improving. If you stay committed to learning and helping your team succeed, you’re doing it right. Rubin makes that clear: Scrum is a path, not a destination.

Essential Scrum isn’t just a manual for how to “do Scrum right.” It’s an invitation to think differently about how we build things, how we plan, and how we lead. It’s one of those books that doesn’t just teach you—it changes the way you see the work around you. And once you’ve read it, you can’t help but start asking new questions, trying new approaches, and nudging your team toward a better way of working.

Because in the end, Scrum isn’t the goal. It’s the path. And this book? It’s one of the best companions you could take on that journey.

Chapter by Chapter

Chapter 1 – Introduction

A personal story with a powerful metaphor

The chapter opens with a personal story. On June 21, 2000, Kenneth Rubin became a father—and shortly after, was asked to step in as the interim head of engineering at Genomica, a company struggling with product delays and poor quality. The contrast between delivering a healthy baby “on time and with delighted stakeholders” and inheriting a failing product development team set the stage for one big question: How can teams deliver high-quality results on time, with happy customers?

This moment led Rubin to bring in Mike Cohn and adopt Scrum, an approach few had heard of at the time. That decision changed everything.

What is Scrum?

Scrum is introduced as an agile framework to develop innovative products and services. It starts with a product backlog—a prioritized list of features. Teams work in short, timeboxed iterations (usually 1 to 4 weeks), selecting the highest-priority items first. By the end of each iteration, they deliver working, potentially shippable features and gather feedback, using it to decide what to build next.

The process is dynamic. It’s about learning fast, adapting quickly, and focusing only on what truly matters. Instead of doing everything upfront, teams work incrementally, always keeping the customer involved and the value in focus.

Where Scrum comes from

Scrum’s roots go back to a 1986 article in Harvard Business Review by Takeuchi and Nonaka. They challenged the traditional “relay race” approach to product development and instead promoted a “rugby” style, where the whole team moves together in a fluid, collaborative way.

Inspired by this thinking, Jeff Sutherland and Ken Schwaber formalized Scrum in the early ’90s, blending ideas from empirical process control, object-oriented development, and complex adaptive systems. It started in software but has since expanded far beyond—used even in hardware, marketing, and sales.

Why Scrum was the right choice for Genomica

Genomica needed fast learning, not rigid plans. They were working on complex, cutting-edge products, and their old waterfall approach just didn’t fit. One particularly painful lesson came after a year-long architectural effort that produced a system so sluggish it took 42 seconds just to tab between fields. Clearly, big up-front design wasn’t working.

They also struggled with siloed teams and poor communication. Scrum, with its cross-functional collaboration and emphasis on frequent feedback, offered a much better alternative.

The results were dramatic

Switching to Scrum wasn’t just better—it was transformational. Genomica required one-tenth the effort and delivered seven times more value compared to their old waterfall approach. Most importantly, they delivered on time, strengthening a key partnership and increasing shareholder value. Scrum wasn’t just a process—it helped save the business.

Can Scrum help you too?

Rubin asks a hard question: Are you happy with how your organization develops software? Most teams he meets say no. The common issues—late delivery, poor quality, low ROI, lack of accountability—are everywhere. But it doesn’t have to be that way.

Organizations that embrace Scrum often see better customer satisfaction, faster releases, improved return on investment, and even happier teams. Scrum isn’t just about process; it’s about transforming how work happens.

Scrum works best in complex domains

Using the Cynefin framework, Rubin explains that Scrum is ideal for complex situations—where outcomes are unpredictable and learning is essential. In contrast:

• Complicated problems are best handled by experts using best practices.
• Simple problems need predefined processes and clear solutions.
• Chaotic problems call for immediate action, not planning or iteration.
• Disorder means you don’t even know what kind of problem you’re facing.

Software development often spans multiple domains, but new-product development is especially complex—and that’s where Scrum shines.

But Scrum isn’t for everything

In highly interrupt-driven environments, like customer support, Scrum might not fit. In these cases, Rubin suggests Kanban, which helps visualize work, limit work in progress, and optimize flow without requiring set-length iterations.

Scrum and Kanban are both agile, but they serve different needs. Sometimes, organizations use both—Scrum for new development, Kanban for ongoing maintenance.

Scrum isn’t magic. It won’t solve all your problems. What it will do is shine a bright light on your team’s issues—misalignments, inefficiencies, broken communication. That can be uncomfortable. But if you’re willing to face those problems head-on, Scrum offers a path to better results, better products, and more satisfaction—for both your customers and your teams.

Rubin ends the chapter where he began: with the hope that, like his son Asher’s smooth arrival, your team can also deliver something valuable, healthy, and on time—with Scrum guiding the way.

Chapter 2 – Scrum Framework

Scrum isn’t a recipe—it’s a framework

Scrum is not a strict checklist you follow to get guaranteed results. It’s more like the structure of a house: a strong foundation, essential walls, and space inside for customization. You can add furniture and paint the walls, but if you knock out a key support beam, the house might collapse. That’s how the author describes Scrum—a set of core roles, activities, and artifacts that you build upon to suit your team.

At its core, Scrum is built on values like openness, courage, focus, and collaboration. It’s about empowering people and creating an environment where the team can thrive. What follows in this chapter is a complete walkthrough of the Scrum framework: the roles people play, the work they do, and the tools they use.

The three Scrum roles

Every Scrum team has just three required roles:

• Product Owner – The single voice for what gets built and in what order. This role holds the product vision, prioritizes work, and ensures the team is focused on delivering the most valuable outcomes. He collaborates closely with everyone and is responsible for maximizing value.
• ScrumMaster – She’s not a boss, but a coach. Her job is to help the team understand and apply Scrum well, remove obstacles, and protect the team from outside disruptions. She facilitates change, encourages collaboration, and helps the team improve continuously.
• Development Team – This is a cross-functional group responsible for delivering working products. Instead of defining team members by roles like tester or programmer, Scrum simply calls them the “development team.” They decide how to do the work and self-organize to meet the sprint goal.

Scrum activities: The rhythm of the process

The real engine of Scrum is the sprint—a timeboxed iteration of up to one month where work gets done. Each sprint follows a cycle of activities designed to help the team plan, build, inspect, and improve.

• Product Backlog & Grooming: The product backlog is a prioritized list of everything that might be needed in the product. It’s constantly evolving. The act of refining, estimating, and organizing this list is called grooming. The product owner leads this effort, often with help from the team.
• Sprint Planning: Before a sprint starts, the team and product owner meet to define what will be built. They agree on a sprint goal and select a manageable set of backlog items. These are broken down into tasks, and the team builds a plan—called the sprint backlog—for how they’ll complete them.
• Sprint Execution: This is the actual work. The development team pulls tasks from the sprint backlog and gets them done. No one tells them how to do it—they decide as a team, often adjusting as new information comes in.
• Daily Scrum: Every day, the team meets for 15 minutes to sync up. Each member answers three simple questions: What did I do yesterday? What will I do today? Is anything in my way? It’s not a status meeting, but a coordination tool to keep things moving.
• Definition of Done: At the end of the sprint, the work should be “potentially shippable.” That doesn’t mean it will ship—it means it could. The team agrees on what “done” means, and sticks to it. That could include coding, testing, documentation—whatever is needed to be truly complete.
• Sprint Review: Once the sprint ends, the team shows what they’ve built. Stakeholders, customers, and team members all participate in reviewing the new work and giving feedback. This is a time to inspect the product and adapt the plan if needed.
• Sprint Retrospective: Finally, the team looks inward. What went well? What didn’t? What can we do better next time? This continuous improvement loop is what makes Scrum more than just a process—it’s a learning cycle.

Commitment vs. Forecast

An interesting point raised in the chapter is whether teams should “commit” to the sprint goal or just “forecast” what they think they can do. Rubin leans toward commitment—not because teams should push through at all costs, but because mutual trust and planning depend on some level of predictability. Still, it’s a nuanced conversation, and some prefer “forecast” to avoid rigid expectations.

A flexible, focused cycle

From start to finish, a Scrum sprint is a loop of planning, doing, and learning. The framework itself is consistent, but how you apply it can vary. Some teams release software every sprint, others wait for larger chunks. Some teams refine backlog items during the sprint; others schedule grooming sessions. The key is adapting while respecting the framework’s integrity.

This chapter gives us a full map of Scrum: who’s involved, what they do, and how the process flows. It’s not a rigid methodology, but a flexible structure that supports learning, collaboration, and value delivery. Every sprint is a chance to get better—at the product, the process, and as a team.

Chapter 3 – Agile Principles

Why principles matter

Before getting deeper into how Scrum actually works, Rubin takes a moment to zoom out and explain why it works. This chapter focuses on the principles that shape Scrum—not just what teams do, but the thinking behind it. And to really understand those principles, Rubin says it’s useful to contrast them with more traditional, plan-driven approaches like waterfall.

Now, this isn’t about saying one approach is “bad” and the other is “good.” It’s about recognizing that different types of work need different approaches. The chapter lays out how agile thinking differs, and why it’s often a better fit for today’s complex and uncertain product development work.

Variability and uncertainty are not the enemy

Traditional development sees variability and uncertainty as problems to eliminate. Agile, especially Scrum, sees them as facts of life—and sometimes even opportunities.

Rubin starts by explaining that product development isn’t manufacturing. In manufacturing, you want consistency and repeatability. In development, every feature is unique. You’re creating a recipe, not mass-producing cookies. Some level of variability is not just acceptable—it’s necessary.

That’s why Scrum embraces iterative and incremental development. Iteration means we expect to get things wrong and improve through rework. Incremental means we build small pieces of value one at a time, learning as we go. Scrum combines both to build the right things and build them right, while staying open to change.

Inspection, adaptation, and transparency

Scrum is built on the idea that we should continuously inspect what we’re doing, adapt based on feedback, and be transparent about everything that matters. This is called empirical process control. Instead of pretending we know everything upfront, we accept that we’ll learn along the way—and we make sure everyone sees the real state of things so we can respond effectively.

This kind of learning isn’t just about the product. Scrum teams also inspect and adapt the way they work, making improvements sprint by sprint.

Reducing uncertainty—together

Rubin makes a big point: in Scrum, we reduce multiple kinds of uncertainty at once. Not just “what are we building?” but also “how will we build it?” and even “who is it for?” Especially in new or complex domains, these questions can’t be answered all at once at the beginning. Instead, Scrum creates a safe space to explore all of them, gradually turning the unknown into the known.

Prediction vs. adaptation: A delicate dance

Scrum doesn’t ignore planning—but it doesn’t worship it either. Rubin walks us through several powerful principles for navigating uncertainty:

• Keep options open: Don’t rush to make decisions just because it’s “time” in the process. Wait until the last responsible moment, when the cost of not deciding outweighs the cost of deciding.
• Accept you won’t get it right upfront: The belief that we can know all requirements or design details in advance is just not realistic. And trying too hard leads to piles of low-quality requirements created too early.
• Favor exploration: With modern tools and fast feedback, it’s cheaper to try something and learn than to plan forever. Today, exploration is often the smarter economic choice.
• Embrace change: Scrum aims to flatten the cost-of-change curve—keeping it cheap to change direction, even late in the process. This counters the waterfall idea that change is expensive and should be avoided.
• Balance up-front and just-in-time work: Scrum doesn’t throw out all early planning. It’s about doing just enough to start smart, but leaving room to adapt as we go. It’s a balance between chaos and control.

Learning is everything

Rubin introduces the idea of validated learning—getting real evidence that supports or disproves what we believe. In Scrum, we organize work to learn quickly. That means:

• Testing assumptions early
• Running multiple feedback loops at different levels (daily scrums, sprint reviews, technical practices)
• Designing workflows for fast feedback, so mistakes don’t sit around festering into disasters

The earlier we learn, the less costly the mistakes—and the better the outcomes.

Work in Process (WIP): A hidden cost

Here’s where Rubin borrows from lean thinking. Too much work in process (WIP) creates waste, delays, and risk. Traditional development often builds huge batches—doing all the requirements, then all the design, and so on.

Scrum takes a more balanced approach:

• Use small, economically sensible batch sizes to improve flow, feedback, and focus
• Be mindful of inventory—not physical parts, but unfinished work sitting around
• Focus on idle work, not idle workers. If people are “100% busy,” work just queues up—and value gets delayed. Rubin uses the analogy of a relay race: you win by getting the baton (the work) across the finish line, not by keeping all the runners constantly moving.

The real cost of delay often dwarfs the cost of someone having a bit of downtime.

Progress is measured in value, not activity

Traditional thinking says you’re making progress if you’re moving through phases of a plan. Scrum says you’re making progress only when you’ve delivered something valuable and validated that it works. That means:

• Replanning constantly as new information arrives
• Measuring working, tested features—not task completion
• Delivering high-value work first, so even if time runs out, the most important stuff is done

And finally, performance with purpose

Scrum values going fast—but never rushing. There’s a difference between speed and hurry. Teams should move quickly, but sustainably.

It also emphasizes building in quality from the start, rather than trying to patch it in later. And it respects the idea of minimal ceremony—do just enough process to stay aligned and compliant, but don’t drown in documentation. If it’s not adding value, skip it.

This chapter is like the philosophical backbone of Scrum. It lays out a set of beliefs that contrast sharply with traditional development—and explains why they work better for complex, uncertain, rapidly evolving environments.

Rubin isn’t saying waterfall is wrong. He’s saying it’s a different tool for a different kind of problem. Scrum is built for agility, learning, and delivering value—and these principles are what make that possible.

Chapter 4 – Sprints

The sprint is the heartbeat of Scrum

If Scrum were a living thing, the sprint would be its heartbeat. Everything in Scrum happens around this regular, repeating cycle—usually between one week and one calendar month long. The sprint isn’t just when the work gets done; it’s the structure that holds the rhythm of planning, building, reviewing, and improving. Rubin dives deep into what makes a sprint tick—and why sticking to the structure matters more than we sometimes think.

Timeboxing keeps us focused and honest

Each sprint is timeboxed, meaning it has a fixed start and end date. This isn’t just about scheduling—it’s a powerful way to limit work in progress (WIP), reduce risk, and avoid the trap of endless perfectionism. Timeboxing forces teams to focus on what matters most right now. It also gives the team a known deadline, which naturally creates urgency and motivation.

Another big benefit is predictability. Even if we can’t forecast a year from now, we can get pretty good at knowing what we can deliver in the next two weeks. The regular cadence helps everyone align, sync calendars, and build a sustainable work rhythm.

Short sprints = faster feedback and better energy

Shorter sprints come with some very real advantages. First, they make planning easier. It’s a lot simpler to figure out two weeks of work than six months. More importantly, they deliver fast feedback. Every sprint is a chance to learn—about the product, the technology, or even how the team is working together.

There’s also a clear economic benefit. With shorter sprints, you can deliver value—and start seeing return on investment—much earlier. You’re also less likely to “boil the ocean,” a phrase Rubin uses to describe massive, drawn-out projects that exhaust teams and kill enthusiasm. Small, quick wins keep morale high and help people stay engaged.

Consistency builds rhythm and trust

While the exact length of a sprint can vary from team to team, keeping that length consistent is key. A regular cadence makes everything else easier—from velocity calculations to stakeholder scheduling. It also reduces the stress of ramping up or down. If every sprint is the same length, teams can settle into a groove, and stakeholders can trust that the process is reliable and repeatable.

That said, Rubin does acknowledge exceptions. Maybe it’s the holidays or a major release that throws things off. But in general, sticking to your sprint length—no matter how tempted you are to stretch it by a few days—helps build healthy habits.

Don’t mess with the sprint goal mid-flight

One of Scrum’s core rules is: once a sprint has started, don’t change the goal. Everyone—especially the product owner—agrees to hold steady until the end. This mutual commitment lets the team focus fully without constantly reacting to shifting priorities.

Rubin makes an important distinction between change and clarification. Clarification is fine—it’s normal for team members to ask questions and refine details as they work. But adding new work, changing priorities, or replacing features during a sprint? That’s a change. And change like that creates waste—wasted planning, disrupted work, broken flow.

Still, there are times when being pragmatic makes sense. If a critical production system goes down or a competitor releases something game-changing, it might be smarter to pivot. In such cases, the team may decide to abnormally terminate the sprint, reflect in a retrospective, and start a new one with an updated goal. But this should be rare, not routine.

The Definition of Done: your team’s quality gate

Every sprint should end with a potentially shippable product increment. But how do you know if something is truly “done”? That’s where the Definition of Done (DoD) comes in. It’s a shared checklist the team uses to confirm that a piece of work is finished—not just coded, but tested, documented, reviewed, and meeting the team’s standards.

Rubin offers a detailed example of what a DoD might include—from unit testing and integration to user documentation and bug fixes. The idea is that you should never reach the end of a sprint with half-done work or untested features. If something isn’t done, it goes back to the backlog to be prioritized again.

The Definition of Done can evolve, especially if a team is just starting out or facing constraints (like no access to a clinical testing lab). But the goal is always to move toward higher quality and more confidence that your work is truly complete.

Done vs. done-done? Don’t go there

Rubin pokes fun at the idea of “done” vs. “done-done.” He shares a funny story about using that term with his son’s homework, and how people sometimes need to invent a second term to signal that something is really finished. But in Scrum, there should be just one standard. If it’s done, it meets the Definition of Done. If not, it’s not done—simple as that.

This chapter lays out the rules and reasoning behind sprints. It’s not just about having short cycles—it’s about using those cycles to bring structure, focus, and regular learning into complex work. With a strong sprint cadence, a shared goal, and a clear Definition of Done, teams can stay aligned, deliver value fast, and keep improving over time.

Chapter 5 – Requirements and User Stories

Scrum flips traditional requirements on their head

This chapter starts by making a bold but relatable point: in traditional product development, requirements are often seen as fixed, highly detailed documents that must be written upfront and followed to the letter. In Scrum, that mindset simply doesn’t work. Rubin explains that requirements in Scrum are living, breathing things—meant to evolve with conversations, learning, and change.

Instead of locking everything down at the start, Scrum encourages you to treat requirements as flexible placeholders. You sketch them out broadly at first, then progressively refine them as your understanding grows. That means less wasted effort, faster reactions to change, and better alignment with what users actually need.

From rigid documents to conversations

Rubin shares a memorable story about a VP who proudly handed developers a 150-page requirement doc and then disappeared for the year. No conversations, no clarification—just “read the doc.” But the truth is, no matter how well-written, documents can’t predict everything or answer every question. People are better at clarifying expectations through dialogue than through paperwork.

In Scrum, the focus shifts to continuous conversation. You start with a product backlog item (PBI), which is a placeholder for a piece of value. It might begin vague and high-level, but through ongoing discussions between stakeholders, product owners, and developers, it gets refined—just in time and just enough to be built.

User stories: a simple, powerful format

While Scrum doesn’t require a specific format for backlog items, Rubin focuses on user stories because they work so well. They’re simple, flexible, and make sure you’re always building something of value for someone.

A user story typically follows the format:
As a [user role], I want [goal], so that [benefit].

But that sentence isn’t the whole requirement—it’s just the start of a deeper conversation.

Rubin explains user stories using the Three Cs:

• Card: The story is written on an index card (or digital equivalent), with just enough detail to spark conversation.
• Conversation: This is where the real understanding happens. Teams talk through what the story means and how to implement it, often many times throughout the story’s life.
• Confirmation: Each story includes acceptance criteria—conditions that define when it’s done. These criteria help guide development and testing.

One size doesn’t fit all

Not all stories are created equal. Rubin lays out a hierarchy of stories based on size and detail:

• Epics are large, broad ideas—great for high-level planning but too big for a sprint.
• Features are smaller but still may span multiple sprints.
• Stories (or sprintable stories) are bite-sized, ready for a sprint, and focused on delivering value.
• Tasks are even smaller—they describe how to build something, not what to build.

Rubin also introduces themes—collections of related stories tied to a common purpose, like grouping all the stories related to search functionality under a “Search” theme.

How to tell if a story is “good”? Use INVEST.

To evaluate the quality of a user story, Rubin uses the INVEST acronym, which breaks down into six traits:

• Independent: Try to write stories that don’t depend heavily on others. Too many dependencies make planning a nightmare.
• Negotiable: A story should be a starting point for discussion—not a rigid spec.
• Valuable: Every story should provide value to a customer or user. If not, it probably doesn’t belong in the backlog.
• Estimatable: If the team can’t estimate a story, it’s probably too vague or too large and needs more work.
• Small: Especially when close to development, stories should be small enough to complete within a sprint.
• Testable: A story needs clear acceptance criteria. If you can’t test it, how do you know when it’s done?

What about technical and nonfunctional work?

Not everything fits neatly into a user story. Rubin acknowledges this and offers thoughtful ways to deal with different types of work.

• Technical stories: These need to be clearly tied to business value. If they can’t be justified in terms of user value, they probably belong as tasks under real stories—not as standalone items.
• Nonfunctional requirements: These are system-level constraints (like browser support or performance needs). Rubin recommends including them in the team’s Definition of Done, so they’re consistently considered during development.
• Knowledge-acquisition stories: Sometimes the team doesn’t know enough to make a decision. In that case, they create a spike or exploration story—essentially, an experiment with a clear goal and cost. If the value of the knowledge outweighs the cost, it’s worth doing. Otherwise, maybe a coin toss would’ve been cheaper!

Gathering stories: it’s a team sport

To build a strong product backlog, you need to co-create stories, not just extract them from users like pulling teeth. Rubin recommends two techniques:

• User-story-writing workshops: Gather key players—product owner, ScrumMaster, developers, and stakeholders—and brainstorm stories together. Don’t aim for perfection. Just focus on creating useful placeholders for future conversation.
• Story mapping: This technique, championed by Jeff Patton, helps visualize the flow of user activities. You lay out epics and themes horizontally (representing a workflow), then stack detailed stories vertically under each one. It’s a great way to organize, prioritize, and see the big picture all at once.

This chapter reframes how we think about requirements. Instead of detailed specs written in stone, Scrum treats them as evolving ideas shaped by ongoing conversations. User stories offer a lightweight, flexible way to express value—and with the right structure and mindset, they help teams stay focused on delivering what truly matters. Whether it’s managing scope, encouraging collaboration, or adapting to change, Scrum’s approach to requirements puts learning and people at the center.

Chapter 6 – Product Backlog

The product backlog is the heart of Scrum

In this chapter, Rubin goes deep into the product backlog, describing it as the central hub of all work that needs to be done. It’s a shared, prioritized list of desired functionality that evolves constantly. As long as a product is being built or maintained, the product backlog lives on, adapting to change and helping the team deliver value in a fast, flexible way.

The backlog isn’t just a to-do list. It’s a dynamic tool for organizing work, supporting collaboration, and managing uncertainty—all while keeping everyone aligned on what’s important and what’s coming next.

What goes into the product backlog

Product backlog items (PBIs) are the building blocks of the backlog. They usually represent features that deliver value to the user—like a login screen—but they can also include defect fixes, technical work, or knowledge acquisition. The format isn’t fixed, but user stories are common.

Rubin provides a helpful table with examples: from adding new features, to fixing a bug with special characters in search, to prototyping different architectures. If it’s valuable and needs to be done, it belongs in the backlog.

What makes a good backlog? Think DEEP

To help teams build effective product backlogs, Rubin introduces the DEEP acronym—Detailed appropriately, Emergent, Estimated, and Prioritized.

• Detailed appropriately means near-term items should be small, specific, and ready for action, while items further out can remain big and vague. It’s all about just-in-time refinement. If you break things down too early, you risk wasting effort. Too late, and the team might stall waiting for clarity.
• Emergent means the backlog is never “done.” New info constantly flows in—customer feedback, market changes, technical surprises—and the backlog must adapt. That’s its power.
• Estimated reminds us that each item should have a size estimate. This helps with prioritization and planning. Rubin notes that near-term items get tighter estimates (story points, ideal days), while big epics might get only rough T-shirt sizes like L or XL until they’re refined.
• Prioritized means the backlog is ordered by importance. But not everything needs fine-grained prioritization. Focus on what’s coming up soon. Deep prioritization for features that might never happen is usually a waste of time.

Backlog grooming keeps everything flowing

To keep the backlog in good shape, it needs regular grooming. Rubin defines grooming as a combination of creating/refining items, estimating them, and prioritizing them. This reshapes the backlog over time, adding, adjusting, or even removing items as needed.

Everyone participates in grooming—product owners, stakeholders, developers, and ScrumMasters. The product owner is the final decision-maker, but collaborative grooming ensures shared understanding, reduces miscommunication, and bridges the business-tech divide. It’s also a smart investment of team time—Rubin suggests spending around 10% of each sprint on it.

When does grooming happen?

Scrum doesn’t dictate a specific time. Some teams hold formal grooming workshops weekly or once per sprint. Others spread it out, using time after the daily scrum for incremental refinement. It can also happen naturally after sprint reviews, when feedback sparks new ideas or shifts priorities.

The point is to make grooming part of the rhythm, not an afterthought.

Definition of Ready helps teams commit with confidence

To make sure items at the top of the backlog are truly ready to be worked on, many teams use a Definition of Ready—a checklist that ensures a PBI is clear, sized appropriately, has no blockers, and includes testable acceptance criteria. Just like the Definition of Done, it helps avoid surprises and improves flow.

Managing flow at release and sprint level

Rubin uses great metaphors here. He describes the backlog as a pipeline—ideas enter big and fuzzy, and move through refinement until they’re ready to exit the pipe into a sprint.

For releases, he introduces the idea of drawing two lines across the backlog: one for “must-haves” and one for “won’t-haves.” This helps teams focus on delivering what’s essential while still keeping an eye on possible extras. It also creates flexibility—if time runs out, “nice-to-haves” can be dropped without derailing the release.

The key is to maintain just enough ready work—not too little that you run dry, not too much that it goes stale. A practical heuristic Rubin suggests is having two to three sprints’ worth of ready PBIs at all times.

How many product backlogs should you have?

The simple rule is: one product, one product backlog. But of course, real life isn’t always that simple.

• Defining what is a product can be tricky. Is Microsoft Word a product? Or is Microsoft Office the product? Rubin shares IBM’s practical approach: if it has a product ID and you can sell it, it’s a product.
• Large products may need hierarchical backlogs. For something like a phone, with many teams working on independent components, it helps to have area-specific backlogs under one master product backlog.
• Multiple teams, one product works best when teams are interchangeable. If not, you may need team-specific views of the shared backlog so everyone works on what fits their expertise—though this limits prioritization flexibility.
• One team, multiple products is tricky. The best scenario is to work on one product at a time. If not possible, merging the backlogs or pre-allocating time to each product can help manage the juggling act.

The product backlog isn’t just a list—it’s a living, breathing structure that guides everything the team does. Done right, it enables smooth, responsive development in the face of constant change. Rubin emphasizes that with thoughtful grooming, clear structure, and collaborative care, the product backlog becomes a powerful tool for delivering real value, sprint after sprint.

Chapter 7 – Estimation and Velocity

Estimating size, measuring speed

This chapter tackles two essential ingredients for agile planning: estimation and velocity. Rubin starts with a simple yet powerful question—how do we figure out how long something will take, how much it will cost, and how much we can get done? His answer: estimate the size of what you’re building and measure how fast your team usually works. From there, everything else—duration, cost, scope—falls into place.

The math is simple, the practice is nuanced

Say you estimate that a release will require 200 points of work. If your team finishes about 20 points per sprint, it should take 10 sprints. That’s the basic formula: estimated size ÷ velocity = number of sprints. But of course, real life is never that neat. The chapter goes on to unpack what we estimate, when we do it, and how to do it well.

Three levels of estimation

Rubin outlines three levels of estimation that happen in most organizations:

• Portfolio backlog: Very high-level, often estimated with T-shirt sizes (S, M, L). It’s too early for detailed specs, so rough sizing helps prioritize and compare investments.
• Product backlog: When features move up in priority, we estimate them more precisely, usually with story points or ideal days.
• Sprint backlog: Here, we break things into tasks and estimate effort in ideal hours, helping teams assess whether their sprint plan is realistic.

Each level uses the right amount of detail for its purpose, and no more. Rubin stresses that estimation should be about learning and communication—not precision for precision’s sake.

Why estimate at all?

Some agile teams argue that they don’t need estimates if all their stories are small and similar. Rubin gets that, but still recommends estimating—mainly because of what happens during the process. Estimating forces discussion, surfaces assumptions, and promotes shared understanding. Even if the numbers are thrown away later, the conversation is worth it.

Who should estimate? The people doing the work

In Scrum, only the development team estimates. The product owner provides context and answers questions, and the ScrumMaster facilitates the conversation—but neither of them estimates. This is important. People who will build the thing are the ones best qualified to judge how big it is.

Estimates are not commitments

This part is especially striking. Rubin tells a story about holding up a sticky note and asking for an estimate. Then he adds, “Your bonus depends on being right.” Suddenly, the estimates get bigger—much bigger. His point is clear: when we tie estimates to performance or rewards, they stop being honest. Estimates should reflect what we believe, not what we fear.

Focus on accuracy, not precision

Rubin has no love for hyper-precise estimates like “10,275 man-hours” or “$132,865.87.” They look serious but are often wildly wrong. He urges teams to stop pretending they know more than they do. Instead, get a good-enough estimate—roughly right beats precisely wrong.

Estimate relatively, not absolutely

One of Rubin’s favorite principles is that people are much better at estimating by comparison than by guessing raw numbers. He uses a clever classroom story: ask people how far away a wall is in meters, and you get wildly different answers. Ask them how far a projector is between two walls, and almost everyone agrees—it’s halfway. That’s why Scrum teams use relative sizing: compare one story to another and ask, “Is this twice as big?” instead of “How many hours?”

Story points vs. ideal days

Rubin breaks down the two most common units for estimation:

• Story points: These represent relative size, combining complexity, effort, and unknowns. They don’t map directly to time, but are great for comparing work items.
• Ideal days: These represent pure effort, not calendar time. The problem? People often misinterpret them as actual days, which creates confusion.

Neither unit is right or wrong, but Rubin warns that if your organization can’t handle ideal days without slipping into time-tracking, go with story points.

Planning Poker: estimates through conversation

To actually estimate backlog items, Rubin recommends Planning Poker. It’s a structured game where team members privately choose a card with their estimate, then reveal them all at once. If there’s disagreement, they talk it through and try again. The goal isn’t to average the numbers—it’s to reach consensus based on shared understanding. The game exposes different perspectives, uncovers hidden assumptions, and helps teams converge on realistic estimates.

Rubin even shares a fun twist: Planning Poker cards can include symbols like “?” (I don’t understand), “∞” (too big to estimate), and “π” (let’s take a break!). Estimating is valuable, but it shouldn’t become a marathon.

Velocity: your team’s speedometer

Once your team starts delivering, you can measure velocity—the amount of work completed in each sprint. It’s simple: add up the size of all done items. But it’s not about how hard you worked or how many hours you logged. It’s about output: how much product was actually finished and usable.

Rubin makes a key point—velocity measures output, not value. A 5-point story isn’t necessarily more valuable than a 3-point one. That’s up to the product owner. Still, velocity is useful for planning and for understanding how your team is progressing over time.

Use a velocity range, not a single number

Planning with a single velocity number is tempting, but misleading. Rubin recommends using a range, like “between 17 and 20 points per sprint.” This reflects the natural variation that occurs and gives more realistic answers to questions like “When will we be done?”

New team? Forecast, then replace with reality

What if your team is brand new and has no velocity history? You can forecast it. Plan a sprint, see how much you think you can do, and use that as a starting point. Better yet, plan two sprints and use the range between them. As soon as you finish real sprints, use your actual velocity instead. Forecasting is only a temporary crutch.

Can we increase velocity? Maybe—but carefully

Some leaders expect velocity to increase forever. Rubin says that’s unrealistic. Yes, a new team might improve as they stabilize, reduce technical debt, and get better at Scrum. But eventually, velocity plateaus. Pushing it higher through constant change, new tools, or team reshuffling often causes short-term dips and long-term instability.

And overtime? It might boost velocity briefly—but the crash that follows is usually worse. The recovery can take longer than the gain was worth. Sustained burnout just leads to lower quality and lower morale.

Don’t misuse velocity

Rubin ends with a strong warning: don’t use velocity as a performance metric. If you tie bonuses to velocity or compare teams using it, you’ll get all the wrong behavior—point inflation, cutting corners, and gaming the system. Velocity should help with planning and reflection, not pressure or punishment.

Estimation and velocity are tools to support transparency, learning, and smart planning. When used with care and common sense, they help teams stay grounded in reality while navigating complexity. But when misused—especially as performance metrics—they backfire. Rubin’s message is clear: estimation should spark understanding, and velocity should serve the team—not the other way around.

Chapter 8 – Technical Debt

Technical debt is about shortcuts—and the cost of keeping them

Rubin opens this chapter with a concept that many in software development know all too well: technical debt. Coined by Ward Cunningham, the idea is simple but powerful—writing code quickly can be like taking out a loan. It helps in the short term, but interest starts building fast if you don’t pay it back. Every time we skip good practices, delay fixes, or hold off on refactoring, we’re making that debt grow. And just like with money, ignoring the debt for too long can make things spiral out of control.

Not all technical debt is the same

Rubin breaks technical debt down into three types:

• Naive debt: This comes from immaturity—lack of training, bad habits, or careless shortcuts. It’s usually unintentional and sloppy.
• Unavoidable debt: This one’s more forgivable. Sometimes we just can’t see the future. We build something, learn from it, and realize our early choices don’t fit anymore. That mismatch becomes unavoidable debt.
• Strategic debt: This one is deliberate. Sometimes we knowingly cut corners to meet a critical deadline or get to market faster. If done with clear eyes and a plan to fix it later, this can be a smart move—if not abused.

What makes technical debt such a useful metaphor is that it speaks the language of business. Leaders get it: you can carry some debt, but you better understand the interest—and when to pay it back.

The painful consequences of letting debt grow

Rubin doesn’t sugarcoat it—high technical debt is a ticking time bomb. Here are some of the most common (and painful) side effects:

• Unpredictable tipping points: The damage isn’t linear. A little more debt can suddenly make the system unmanageable. Like the last straw that breaks the camel’s back, things seem fine until they really aren’t.
• Slower delivery: More debt means slower work. Every change takes longer. Your velocity drops, and the backlog starts to feel endless.
• More defects: Sloppy or fragile code means bugs—lots of them. Instead of building new things, the team is stuck fixing old ones.
• Higher costs: What was once quick and cheap becomes painfully complex and expensive. Even small tweaks become huge efforts.
• Product atrophy: With no room for updates or improvements, the product stagnates. Users get frustrated. Some leave.
• Decreased predictability: Deadlines become guesses. Planning turns into wishful thinking. Trust in the development team erodes.
• Burnout and frustration: Developers hate working in messy code. Morale plummets. People quit. Even the business side feels the pain.
• Lower customer satisfaction: Bugs, delays, and broken promises wear down your users. Eventually, they leave too.

How does all this debt happen? Often, it’s pressure

Deadlines are one of the biggest culprits. The team is asked to deliver a lot by a fixed date. Reality doesn’t match the plan. Instead of cutting scope or extending the timeline, leadership often pushes the team to go faster. So corners are cut. Testing is skipped. Designs are rushed. And just like that, technical debt sneaks in—or storms in.

There’s a dangerous myth that skipping testing speeds things up. Rubin debunks this quickly. Less testing means more hidden bugs, which means slower progress later. Smart teams integrate testing from the start—like using test-driven development (TDD)—to avoid building on shaky ground.

Debt builds on debt

One of the scariest ideas in this chapter is that debt compounds. Release 2 inherits all the problems of Release 1—plus new ones. If you keep going like that, your velocity might eventually hit zero. You’re stuck with a system that’s so fragile, even small changes feel like defusing a bomb.

At that point, your only options are painful: do nothing (and sink), throw tons of money and time at cleanup, or kill the product entirely and start over.

Managing technical debt means taking it seriously

Rubin says the goal isn’t to eliminate technical debt completely. Some debt is fine. But it should be managed. That means having honest, informed conversations between technical and business people. The product owner plays a key role here—balancing the desire for new features with the need to clean up the mess.

There are three core activities in managing debt:

• Managing accrual: Avoid adding unnecessary debt in the first place. Use good practices—like clean design, TDD, continuous integration, and a strong definition of done—to keep things clean from the start.
• Making debt visible: You can’t fix what you don’t see. Business folks need to understand the technical debt situation just like they do financial debt. That might mean showing the impact of declining velocity, using special backlog items, or creating a visual “debt board.”
• Servicing the debt: Once you know where the debt is, you need a plan to pay it down. That doesn’t mean dropping everything to refactor. Rubin encourages a smarter, steady approach.

How to pay the debt down (without going broke)

Rubin lays out several practical ways to tackle debt without derailing your sprints:

• Don’t repay all debt: If the product is nearing its end, or was always meant to be short-lived, repaying the debt might be a waste of effort.
• Apply the Boy Scout Rule: Clean up a little every time you touch the code. Leave things better than you found them.
• Make small, steady payments: Don’t wait until the mess is huge. Avoid “technical debt sprints” if possible. Instead, fix things a little at a time, inside regular work.
• Focus on high-interest debt first: Clean up the parts that hurt the most—code that’s fragile, frequently changed, or central to the product.
• Pay debt while adding value: The best time to fix things is when you’re already in the code to add a feature. Combine cleanup with real work to keep things efficient and aligned with priorities.

One trick Rubin shares is putting the technical debt board right next to the sprint backlog. When planning a sprint, the team looks for debt items in the same area they’ll be working on. If there’s a match, they pull it in. This way, they’re cleaning while building.

This chapter paints a clear picture of why technical debt matters—and what to do about it. Rubin’s message is balanced: a little debt can be okay, but unmanaged debt is a silent killer. With thoughtful strategies and steady habits, teams can keep debt in check, stay productive, and avoid the burnout and chaos that come from ignoring the mess.

Chapter 9 – Product Owner

The product owner is the voice of the product—and the people

This chapter takes a deeper look at the product owner role, revealing just how central and demanding it really is. If Scrum were a machine, the product owner would be the part that connects strategy to execution, ideas to features, and people to outcomes. It’s not just a role—it’s a balancing act, facing two directions at once: inward toward the Scrum team and outward toward users, customers, and stakeholders.

On one side, the product owner understands what users want and what the business needs. On the other, they guide the development team by deciding what to build next and what “done” really means. They don’t code or test everything themselves, but they make sure everyone is aligned and clear on what success looks like.

A role with weight—and lots of hats

Rubin lays out the product owner’s key responsibilities, and it’s immediately clear this is a full-time job. From managing economic decisions to backlog grooming, planning, acceptance testing, and constant collaboration with both team and stakeholders—the product owner wears many hats.

They’re part product manager, part business analyst, part tester, and definitely a decision-maker. And while one person often fills the role, Rubin also opens the door for teams and proxies in more complex situations. But even then, there must always be one single person ultimately responsible. Scrum doesn’t work with decision-making by committee.

Economics at every level

A standout part of this chapter is how seriously the product owner must take economic responsibility. They don’t just prioritize features—they constantly evaluate whether the time and money spent are delivering real value. This happens at three levels:

• Release level: Should we keep going? Add more? Stop early? The product owner weighs cost, time, scope, and potential value. Maybe it’s worth slipping a deadline slightly to capture a high-revenue opportunity—or maybe not.
• Sprint level: The product owner should treat the company’s budget like their own. Would they pay for this sprint’s outcome from their personal account? If not, maybe it’s not a good investment.
• Backlog level: Priorities shift as new info surfaces. A once-promising feature might turn out to be costly and low-value. The product owner needs to spot those shifts and adapt.

Planning isn’t a one-time event—it’s constant

The product owner plays a vital role in all planning stages—from long-term portfolio strategy down to the nitty-gritty of sprint goals. During sprint planning, they help define what the team will work on, ensuring there’s clarity, feasibility, and value behind each item. They also stay engaged throughout the sprint to answer questions and provide feedback.

Grooming the backlog is not optional

The product owner ensures the backlog is in good shape—detailed where needed, prioritized appropriately, and ready for development. While they don’t do all the work themselves (others can write or refine items), they’re ultimately responsible for ensuring that the process happens effectively and continuously. A well-groomed backlog makes the entire Scrum process smoother.

Acceptance criteria are non-negotiable

It’s the product owner’s job to define what “done” means for each backlog item. This means setting clear acceptance criteria and, when possible, writing or overseeing the writing of acceptance tests. These must be ready before sprint planning—otherwise, the team won’t know what success looks like, and the sprint will suffer. Testing during the sprint, not just at the end, is key to catching problems early.

Constant collaboration with the team is a must

Rubin makes a strong point here: many new Scrum teams fail because the product owner isn’t engaged enough. This isn’t a role for someone who pops in once a week. The product owner needs to be available daily—to clarify, prioritize, test, and support. Rubin contrasts this with traditional development where business involvement drops off during coding and resurfaces only for final review—often leading to disappointment and blame. Scrum flips that on its head with tight, regular feedback loops.

And it doesn’t stop with the team—stakeholders need love too

The product owner is also the single voice for the stakeholder community. They gather input, mediate conflicting interests, and shape a clear product vision. This means juggling a lot of perspectives and turning them into a coherent direction the team can follow.

What makes a great product owner?

Rubin outlines four core areas:

• Domain skills: They need to understand the product and its market deeply. You can’t prioritize features if you don’t know what matters.
• People skills: A product owner negotiates, motivates, communicates, and builds consensus. They’re the bridge between tech and business.
• Decision-making: Empowered and decisive. They make tough calls and don’t hide behind indecision or layers of approval.
• Accountability: They own the outcome. If the product fails to deliver value, the product owner is responsible.

A day in the life (or a few weeks)

Rubin walks through what a product owner actually does over several weeks, from portfolio discussions and story workshops to sprint planning, reviews, and daily questions from developers. It’s a hands-on, full-contact role. Not just attending meetings, but shaping what gets built, when, and why—every single day.

Who should be the product owner? It depends

Rubin explores different development contexts:

• Internal projects: A business-side person from the team benefiting from the system should be the product owner—not someone from IT.
• Commercial products: Usually a product manager or marketer who knows the market and speaks for the customer.
• Outsourced work: The paying company (not the contractor) should provide the product owner.
• Component teams: More technical product owners may be needed to prioritize backend or infrastructure work.

Can one person cover it all? Sometimes, but not always

For small efforts, one person can usually handle it. For bigger or more complex products, Rubin discusses a few options:

• Product owner for multiple teams: Possible if the teams are closely aligned and the workload allows.
• Product owner + another Scrum role?: Serving as both product owner and ScrumMaster is discouraged—too much conflict of interest.
• Product owner team: This can work as long as there’s one ultimate decision-maker. It’s not a committee. Everyone can help, but one person needs to have the final say and full accountability.
• Proxy product owner: A practical solution when the actual product owner isn’t always available. The proxy helps with day-to-day communication but doesn’t make major decisions.
• Chief product owner: For huge efforts (like 250 teams), a hierarchy may be needed. Just ensure that product owners at lower levels stay empowered to make decisions without endless escalations.

This chapter reveals the depth and weight of the product owner role. It’s not a glorified backlog manager—it’s a leadership role, central to the success of any Scrum effort. The product owner holds the vision, manages the economics, guides the team, and stays deeply connected to users and stakeholders. Rubin’s message is clear: Scrum works best when this role is filled by someone empowered, available, and fully committed to guiding the product toward delivering real value.

Chapter 10 – ScrumMaster

The ScrumMaster is the team’s guide—not the boss

Rubin begins by placing the ScrumMaster right in the middle of the Scrum world. If the product owner is focused on building the right product, and the development team is focused on building it right, the ScrumMaster is the one making sure the whole system works smoothly. They’re the coach, the guide, the protector, and the change agent. Not a manager, not a project lead—but someone who helps the team grow and thrive using Scrum.

Coaching is at the core

The ScrumMaster is a coach to both the development team and the product owner. Like a good sports coach, they’re not there to solve every problem or call all the plays. Instead, they help people solve their own problems, get better at what they do, and build trust in the process. Rubin emphasizes that great ScrumMasters don’t jump in with answers—they guide people toward discovering their own.

This role also involves helping the product owner succeed. Whether it’s learning how to groom the backlog or how to balance business expectations, the ScrumMaster is there to offer support, manage expectations, and translate frustrations into improvements.

A true servant leader

One of the most powerful images in this chapter is the ScrumMaster as a servant leader. Instead of asking, “What can you do for me?” they ask, “How can I help you do your best work?” It’s a humble role, grounded in service, but with clear authority in one key area: the Scrum process.

The process guardian, not the task manager

Rubin draws a clear line: the ScrumMaster has process authority, not people authority. They don’t tell the team what to do or how to do it. They don’t manage performance or assign tasks. But they do make sure that Scrum is being applied properly and continuously improved. They help the team inspect and adapt its way of working.

Shielding the team from distractions

One of the more tactical parts of the role is acting as a shield. ScrumMasters protect the team from outside interference—whether it’s a manager trying to redirect someone mid-sprint or other teams introducing confusion. They intercept those disruptions so the team can stay focused.

Removing obstacles (big and small)

The ScrumMaster also steps in when the team hits a roadblock they can’t clear themselves. Rubin gives a great example of a team whose servers kept crashing during testing—something they couldn’t fix alone. The ScrumMaster worked with leadership and other departments to resolve the issue. That’s a key part of the role: identifying and eliminating what’s slowing the team down.

Driving change—not just fixing things

Beyond removing blockers, the ScrumMaster is also a change agent. Scrum often shakes up the status quo, and people naturally resist change. The ScrumMaster helps others understand why the shift matters, how it benefits them, and what needs to happen at all levels of the organization. They’re the voice that says, “Yes, this is hard—but it’s worth it.”

What makes a great ScrumMaster? It’s not just skills—it’s mindset

Rubin outlines six key qualities:

• Knowledgeable: They need a solid understanding of Scrum and some knowledge of the tech and business context. Not a developer or domain expert—but familiar enough to coach effectively.
• Questioning: Great ScrumMasters ask powerful, probing questions that help others see things in a new way. They use Socratic questioning to spark insight rather than giving direct answers.
• Patient: Sometimes the team needs time to work things out. The ScrumMaster may “know” the answer, but part of the job is letting others discover it for themselves.
• Collaborative: They must work well with everyone—inside and outside the team—and help others collaborate better too.
• Protective: Like a sheepdog guarding the flock, they shield the team from harmful interference and gently guide people back when they drift away from agile practices.
• Transparent: No hidden agendas. They communicate clearly and openly, modeling the transparency Scrum relies on.

What does their day look like?

Rubin breaks down how a ScrumMaster might spend time across a sprint. They facilitate ceremonies, coach the team, assist the product owner, remove impediments, drive change, and communicate constantly. The time allocation varies depending on the team’s maturity. New teams need more support. Established teams need less, but the ScrumMaster may then shift focus toward organizational change.

Is ScrumMaster a full-time job? Often, yes—but not always

In a new team or one facing lots of challenges, it definitely is. But as teams mature, the ScrumMaster might not need to be present all the time. Still, the role doesn’t disappear. Even with a seasoned team, the ScrumMaster plays a vital role in improving the larger organization and helping other teams grow.

Can ScrumMasters wear other hats?

Sometimes, yes—but with caution. A person might serve as both a ScrumMaster and a developer, as long as they can balance both without compromising either. Rubin prefers that experienced ScrumMasters support multiple teams if they have extra capacity, instead of taking on non-Scrum roles.

But one combination he strongly warns against? ScrumMaster and product owner in the same person. The conflict of interest is too big. The ScrumMaster is supposed to coach the product owner and balance their demands with what the team can do. That’s hard to do when you are the product owner.

The ScrumMaster is the glue that holds Scrum together. They’re not a manager or taskmaster, but a servant leader who helps the team grow, stay focused, and navigate the ups and downs of agile development. With the right mix of patience, knowledge, curiosity, and collaboration, they can turn a group of people into a high-performing Scrum team—and drive change that reaches far beyond it.

Chapter 11 – Development Team

The development team builds the product—but they’re more than just builders

Rubin opens the chapter by clarifying a common confusion: in Scrum, the term “development team” doesn’t mean just coders. It refers to the cross-functional group of people—designers, testers, architects, database experts, and more—who collectively turn product backlog items into potentially shippable features. Whether you call them delivery teams or cross-functional units, Scrum simply sticks with “development team,” and Rubin rolls with that.

Scrum breaks the habit of role-specific teams

Traditionally, companies split people into silos—testers over here, designers over there, developers somewhere else. Work gets passed around like a relay baton. Scrum breaks that pattern. Every sprint, the development team should do all the work necessary to produce working functionality: design, build, test, integrate. That’s why the team needs to have all those skills under one roof.

Rubin does recognize that some specialized testing—like certain regulatory checks—might require separate teams. But most testing, he insists, should be embedded directly in the sprint and handled by the development team itself.

The team’s five key responsibilities

First, the development team spends most of its time doing what Rubin calls sprint execution—actually designing, coding, testing, and building features.

Second, they inspect and adapt daily, participating in every daily scrum to sync up, spot problems, and adjust course. Everyone’s voice matters here.

Third, they help groom the product backlog—refining, estimating, and breaking down upcoming items. Rubin suggests teams spend about 10% of their time on this. It’s a shared responsibility with the product owner, not a one-person job.

Fourth, they plan the sprint, selecting the items they believe they can complete and setting the sprint goal together with the product owner.

Finally, they participate in the sprint review and retrospective, inspecting both the product they just delivered and the process they used, to keep improving continuously.

What makes a great Scrum team? Ten key traits

Rubin outlines ten powerful characteristics that define strong development teams.

Self-organizing teams don’t wait for instructions. Like geese flying in formation, they naturally coordinate and adapt. There’s no “lead goose” barking orders—it’s a system that emerges from interaction and shared direction.

Cross-functionally diverse and sufficient teams have all the skills needed to do the job, minimizing handoffs and delays. Having a mix of backgrounds and perspectives improves solutions and fuels innovation.

T-shaped skills are essential. A good team member has deep expertise in one area (like UX design), but can also pitch in elsewhere when needed. You don’t need everyone to do everything—but some overlap allows the team to be flexible and swarm when bottlenecks appear.

The Musketeer attitude—“All for one and one for all”—means the team wins or loses together. No finger-pointing. If a designer sees a testing problem, they speak up. Everyone takes responsibility for the team’s success, not just their own tasks.

High-bandwidth communication is key. Fast, clear conversations—especially face-to-face—help the team adapt quickly. Rubin prefers colocated teams, but says distributed ones can also work well with the right tools and habits.

Transparent communication means no hiding the ball. Information should flow openly, clearly, and without surprises. Rubin tells a story of someone who used vague updates during daily scrums to avoid scrutiny—an approach that killed trust and derailed the team.

Right-sized teams are typically five to nine people. That size keeps communication manageable and reduces overhead. If you need more people, add another Scrum team—not more people to the same one.

Focused and committed team members stick with one or two products at a time. Juggling too many projects kills focus. Rubin backs this up with data: productivity plummets as people split across more efforts. It’s better to do less, better.

Sustainable pace means no more death marches. Scrum encourages steady, reliable delivery—no all-nighters, no burnout. When work is done every sprint with strong practices like test automation and continuous integration, the crunch time disappears.

Long-lived teams are the real asset. When people work together longer, they gel, trust each other, and become more efficient. Too often, companies shuffle people between teams, breaking that hard-earned chemistry. Rubin argues that instead of moving people to products, we should move products to stable teams.

The development team in Scrum is a self-organizing, cross-functional unit that owns delivery from end to end. It thrives when members share responsibility, communicate openly, help each other, and stay committed over time. Rubin makes it clear: the team isn’t just a group of skilled individuals—it’s a living system. And when that system is nurtured well, the results can be extraordinary.

Chapter 12 – Scrum Team Structures

When one Scrum team is no longer enough

Rubin kicks off this chapter with a simple truth: if you’re building one small product, a single cross-functional Scrum team will probably do just fine. But once things grow—whether it’s the team, the product, or the number of products—you’ll quickly find yourself needing to coordinate the work of multiple Scrum teams. That’s where structure really starts to matter.

This chapter explores the different ways to organize Scrum teams, starting with the classic debate: feature teams vs. component teams.

Feature teams vs. component teams

A feature team is a cross-functional group that can pick up a product backlog item (PBI) and deliver it end-to-end. These teams are ideal in Scrum because they can deliver customer-facing value without depending on other teams.

A component team, on the other hand, focuses on a single part of the system—like routing in a GPS app or the UI layer across products. They deliver pieces of a feature, but not the full thing. These teams often form around areas of technical expertise and tend to report to the same functional manager.

While component teams are common—often because organizations believe it’s safer to let “experts” handle certain parts of the code—they introduce a big coordination burden. The work of one feature must be split into smaller tasks and handed out to various component teams. These teams then have to sync up later to deliver the full feature.

This approach might seem manageable with one or two products. But as Rubin shows, the complexity snowballs quickly. With 10 or more products, the chance that something gets delayed or dropped increases dramatically. You start hearing things like, “Our part is done, but another team is still working on theirs,” or “They couldn’t prioritize our feature because they had requests from five other products.” At that point, even if nine out of ten teams deliver, the feature still isn’t complete.

Why Scrum prefers feature teams

Scrum’s answer is to create cross-functional feature teams that have all the necessary skills to deliver complete features themselves. This removes the handoff delays and reduces the risk of coordination failure.

But what about the common fear—won’t multiple teams modifying the same component create chaos and technical debt?

Rubin argues that if feature teams are formed thoughtfully and share code ownership over time, this risk is minimized. You build trust and collective responsibility, and you don’t need a “gatekeeper” team guarding each component.

The blended model: feature and component teams working together

A more practical, transitional approach is to blend both models. Feature teams take ownership of delivering complete features, but component teams still exist to maintain the health of specific systems. These component teams focus on things like reducing technical debt, improving shared libraries, or supporting reuse.

In this hybrid structure, someone from a component team might temporarily join a feature team to provide expert knowledge. Rubin uses the metaphor of “pollinators and harvesters”: pollinators spread knowledge of the component areas to feature teams, and harvesters gather changes made by feature teams to ensure coherence across systems.

This model helps transition the organization toward shared code ownership while keeping important architectural areas stable.

How to scale and coordinate multiple teams

When you’ve got multiple Scrum teams working together, structure alone isn’t enough. You need smart coordination techniques. Rubin introduces two key ones: scrum of scrums and the release train.

Scrum of scrums (SoS) is a lightweight way to sync up multiple teams. Each team sends a representative (often a developer or sometimes a ScrumMaster) to a separate coordination meeting. They discuss:

• What their team has done that might affect others.
• What they plan to do next that could impact others.
• What problems they’re facing that others might help solve.

It’s similar to a daily scrum, but across teams. These meetings can be short and frequent or more extended for problem-solving. In very large organizations, you can even scale this further with scrum of scrum of scrums—kind of like a program-level scrum.

Release trains: synchronized delivery at scale

When things get even bigger, the release train model steps in. Think of it as a scheduled rhythm that all teams follow, aligning their planning and delivery around fixed dates. Like a train, it departs on time whether you’re ready or not. If your feature isn’t finished, you wait for the next train.

The release train:

• Aligns sprint lengths and start/end dates across all teams.
• Creates a fixed cadence for inspecting, adapting, and releasing.
• Encourages continuous integration and system-wide testing.
• Often includes a hardening sprint at the end to finalize integration and quality.

It starts with a massive planning event—Rubin describes hundreds of people in a giant room mapping out their sprints, identifying dependencies, and talking face-to-face to make sure the plan holds together.

It ends with a release-level review and retrospective, covering not just what got delivered, but how the process worked across all teams. Then it’s time to plan the next train.

This chapter tackles one of the toughest parts of scaling Scrum: how to structure and coordinate multiple teams. Rubin shows that feature teams are ideal, because they reduce dependency and increase delivery speed. But many organizations start with component teams—and that’s okay if you’re moving toward shared ownership.

When scaling up, scrum of scrums helps teams stay in sync, and release trains provide a reliable cadence for complex product delivery. There’s no one-size-fits-all solution—but with thoughtful structure and coordination, even the largest Scrum organizations can stay agile.

Chapter 13 – Managers

Yes, managers still matter in Scrum

One of the most common concerns about Scrum is this: “If teams are self-organizing, where do managers fit in?” Rubin answers that right away—managers absolutely have a role. Just because Scrum doesn’t mention them in the framework doesn’t mean they’ve disappeared. Think of it this way: Scrum also doesn’t mention accountants, but no one would say a company doesn’t need them. The same logic applies to managers.

This chapter takes a deep dive into how functional-area managers (like dev managers, QA managers, art directors) and project managers fit into a Scrum world. It’s especially useful for organizations transitioning to agile that still have traditional roles in place.

What functional managers do in Scrum

Rubin organizes their responsibilities into four major areas: fashioning teams, nurturing teams, aligning/adapting the environment, and managing value creation.

Fashioning teams is about setting the structure. Managers define boundaries—deciding which products or projects teams will work on. They form teams by selecting people from different functional areas, ensuring each Scrum team has the skills needed. While team members can offer input, managers make the final call to balance business needs. Managers are also responsible for adjusting team composition when needed—whether it’s removing someone who’s underperforming or shifting a specialist to another team for urgent needs.

But forming teams is not just about structure—it’s also about empowering them. Rubin refers to Appelo’s “seven levels of delegation,” ranging from “tell” (managers make the decision) to “delegate” (team decides completely). Managers need to pick the right level and stick with it. That builds mutual trust, which is essential for self-organizing teams.

Nurturing teams means helping them grow. That includes energizing people with purpose, supporting skill development, providing leadership in functional areas, and maintaining team integrity. Rubin emphasizes that functional managers should inspire, not control. They support learning—through training, feedback, and mentorship—not through micromanagement.

On feedback, he makes a bold point: annual performance reviews may do more harm than good in Scrum. Teams work in short cycles and learn continuously, so feedback should match that pace—more frequent, more aligned with team goals, and less about individual competition.

Aligning and adapting the environment is about helping the whole organization—not just the Scrum teams—operate in an agile way. That means promoting agile values, removing blockers, and aligning internal groups like marketing, HR, finance, and deployment. A strong agile team can’t deliver value if the rest of the company is still stuck in old ways.

Rubin shares a real moment with a manager who said, “I do that all the time and didn’t know it was a bad thing.” This highlights how often managers unintentionally undermine agility—because they haven’t been coached themselves. Promoting agile values means more than approving a process—it’s a mindset shift.

Aligning partners matters too. If external contractors or suppliers still use traditional engagement models, the organization will hit a wall. Rubin suggests leasing Scrum teams from partners or finding more collaborative ways to work, rather than locking into rigid, fixed-price contracts.

Managing value-creation flow is the final big area. Here, managers step up as strategic thinkers. They need to take a systems perspective, manage the economics of what’s being built, and monitor the right metrics.

Rubin warns against metrics that focus on “keeping people busy.” Instead, he encourages measuring flow—like cycle time, validated working software, and how fast the team learns. Innovation accounting (from Eric Ries) is a key idea here: managers should be looking at how fast they’re learning, not just how fast they’re delivering.

What about project managers?

This is where the chapter takes an important turn. Rubin breaks down the common misconception that the ScrumMaster is just a rebranded project manager. They’re not. Scrum spreads traditional project management responsibilities across all three roles—product owner, ScrumMaster, and development team.

There’s a helpful table that shows how tasks like integration, scope, time, quality, communication, and risk are now shared. This means a project manager moving into Scrum might find themselves becoming a ScrumMaster, a product owner, or even a team member—depending on their strengths.

But Rubin also admits that in large, complex environments, sometimes you still need someone focused on logistics and coordination. If a product involves 50 Scrum teams, multiple vendors, and non-Scrum departments, the teams can’t do all the coordination themselves. In that case, having a project manager makes sense—as long as they support the teams and don’t take over responsibility that should stay with the teams.

Managers in Scrum aren’t going away—they’re evolving. Their role shifts from command-and-control to enabler and systems thinker. They create the conditions for high-performing teams, align the environment around agile values, and help the organization grow stronger as a whole.

Project managers, too, have a place. But it’s not about controlling the work—it’s about helping the system stay connected and running smoothly, especially at scale. The key is clarity: know who does what, let teams self-organize, and support agility at every level.

Chapter 14 – Scrum Planning Principles

Planning is essential in Scrum, but it’s different from traditional approaches

The myth that Scrum doesn’t require planning is dispelled right away in this chapter. Rubin emphasizes that Scrum planning doesn’t mean “no planning” but rather “just-in-time planning.” Unlike traditional, detailed up-front plans, Scrum focuses on keeping plans flexible and adapting to new information. The chapter builds on the principles from Chapter 3, showing how they apply specifically to planning.

Key Scrum Planning Principles

Rubin outlines several core principles that shape Scrum’s approach to planning, all rooted in its empirical nature of inspecting and adapting:

• Don’t assume we can get the plans right up front: Traditional methods emphasize detailed planning at the start, but Scrum doesn’t believe you can get everything right from the beginning.
• Up-front planning should be helpful, not excessive: Some planning is necessary, but it shouldn’t be overdone. Think of it like skiing down a mountain: you need to plan the first few turns, but beyond that, it’s all about reacting to the terrain.
• Keep planning options open until the last responsible moment: Delay major decisions until you have the best information possible, so you don’t waste resources on plans that might change.
• Focus more on adapting and replanning than conforming to a plan: Scrum values the ability to change course over rigidly sticking to a plan. Rubin compares this to projects where huge plans were built up front, only to be ignored or altered as the project evolved. Scrum stresses that adapting based on new learning is far more valuable than staying stuck to the original plan.
• Correctly manage the planning inventory: In Scrum, planning artifacts (like Gantt charts) should not accumulate unnecessarily. The focus should be on delivering value, not creating excessive documentation that becomes irrelevant over time.
• Favor smaller, more frequent releases: Smaller releases provide faster feedback, greater flexibility, and more frequent opportunities to adjust based on actual results. Rubin illustrates this with a model showing how releasing in smaller increments improves the overall return on investment (ROI).
• Plan to learn fast and pivot when necessary: The idea of pivoting—adjusting the course based on what’s learned during the process—is a central theme in Scrum. Rubin highlights the importance of structuring plans so that fast feedback and rapid learning can occur.

The problem with excessive upfront planning

Traditional development often involves creating detailed plans that are assumed to be correct from the start. However, in Scrum, Rubin points out that this kind of planning is based on early ignorance—we don’t know what we don’t know yet. Trying to predict everything upfront is like planning every ski turn from the top of the mountain without knowing how the terrain will change.

He uses the example of a Gantt chart, where the level of detail is often absurd. Instead of planning every step in detail, Scrum advocates for quick, small planning bursts with room for adjustment as you go. It’s all about balancing the need for early plans with the reality that those plans will inevitably change.

Managing the planning inventory

Managing the “planning inventory” refers to the importance of not over-planning or over-committing resources to plans that may change. Rubin explains that if we spend a lot of time up front planning something that will ultimately need to be changed, we’re wasting valuable resources. Scrum focuses on just-in-time planning, where plans are created based on validated learning, rather than assumption.

The risk of over-planning is seen in the example of a Gantt chart that plans tasks 18 months in advance. It’s highly probable that those plans will need to be adjusted, making long-term planning inefficient. Instead, the goal is to plan just enough, when it’s necessary, based on current knowledge.

Smaller, more frequent releases bring better ROI

Scrum champions smaller, more frequent releases, which leads to faster feedback loops and quicker adjustments. Rubin uses a model comparing single and multiple release strategies to show that releasing smaller, more frequent updates leads to better ROI. The sooner a product is released, the quicker it can start generating revenue, leading to a faster breakeven point and better overall profitability.

Rubin points out that while there are limitations to smaller releases (like the necessity for a minimum viable product), when the market allows, this approach maximizes the product’s return on investment.

Plan to learn and pivot

Finally, Rubin stresses that Scrum planning isn’t just about following a set path—it’s about learning and adapting along the way. Pivoting is a core concept, defined as changing direction based on what’s been learned. Like the skier adjusting their path based on new terrain, Scrum teams must be ready to change course when they learn that their current approach isn’t working.

The chapter illustrates that Scrum’s approach to planning is focused on flexibility, adaptability, and learning. By balancing just-in-time planning with opportunities for continuous adaptation, Scrum helps teams avoid the pitfalls of rigid, upfront plans that often lead to wasted effort. The key takeaway is that Scrum values responding to change and learning from experience over sticking to a predefined course. By planning in smaller, frequent bursts, teams can deliver value sooner and adjust based on what works.

Chapter 15 – Multilevel Planning

Planning at multiple levels of detail

In Scrum, planning is not a one-time, up-front task. Instead, it happens at multiple levels throughout the product’s lifecycle. Rubin introduces a framework where planning spans from strategy all the way down to daily tasks. Scrum encourages flexibility and frequent updates to the plan, adapting it as new insights and challenges arise. This chapter covers five levels of planning: portfolio, product, release, sprint, and daily planning.

Levels of Scrum planning

Rubin outlines a top-down description of how the planning process unfolds in Scrum, each with a different horizon, focus, and set of deliverables. He also stresses that while Scrum formally defines sprint and daily planning, in practice, portfolio, product, and release planning are just as important for larger organizations.

Here’s an overview of the five planning levels:

1. Portfolio Planning (Possibly a year or more): Involves stakeholders and product owners. Focuses on managing a collection of products and includes a portfolio backlog.
2. Product Planning (Envisioning) (Up to many months): The product owner and stakeholders work on capturing a product vision, developing a high-level product backlog, and possibly creating a product roadmap.
3. Release Planning (Three to nine months): The whole Scrum team and stakeholders collaborate to balance customer value with constraints like scope, schedule, and budget. The deliverable here is the release plan.
4. Sprint Planning (Every iteration, typically one week to one month): The Scrum team decides on the features to deliver in the next sprint, and a sprint backlog is created with tasks to achieve the sprint goal.
5. Daily Planning (Every day): During the daily scrum, the development team decides what work to tackle next, based on their progress and any potential obstacles.

Rubin uses the Scrum Alliance website redesign as a practical example, walking through each level of planning that was involved in revamping the site.

Portfolio Planning

At the portfolio level, the focus is on managing a collection of products, deciding which to work on, in what order, and for how long. The product ideas are generated at the product planning level, but portfolio planning helps prioritize which products should be funded and developed next.

For example, when the Scrum Alliance was reworking its website, portfolio planning involved the board of directors deciding whether to invest in a completely new site after reviewing the strategic value it could bring to the organization.

Product Planning (Envisioning)

Product planning (or envisioning) defines the broad vision for a product. Rubin explains that it begins with crafting a product vision that aligns stakeholders and guides the development. Following this, the product backlog is created, including high-level user stories that define the product’s key features.

In the case of the Scrum Alliance website, the vision was clear: to make the website the trusted source of Scrum knowledge. The high-level product backlog included major features like listing Scrum classes and supporting trainers.

Creating the Product Roadmap

Once the product vision and backlog are in place, the next step is to develop a product roadmap. A roadmap helps communicate the incremental nature of the product’s development and can be used to track releases. Rubin notes that some organizations focus on continuous deployment, meaning they release features as soon as they’re available, but even in such cases, a roadmap can be useful for planning larger groups of features and coordinating the timing of their availability.

For the Scrum Alliance website, the product roadmap included the timeline for the initial release (0.5) and the follow-up release (1.0), with milestones based on both scope and specific launch dates (like the Scrum Gathering conference).

Release Planning

Release planning occurs after product planning and before the first sprint. At this level, the Scrum team needs to make trade-offs between scope, time, and budget. Release planning involves estimating which features can be delivered by a fixed date or within a specific time frame.

Rubin explains that a useful way to visualize release planning is by drawing a line through the product backlog—above the line are the features planned for the release, and below are the features not yet planned. The line can move as more insight is gained during the sprint cycles.

In the case of the Scrum Alliance website, Release 0.5 was a fixed-scope release, while Release 1.0 was a fixed-date release, tied to a specific event (Scrum Gathering).

Sprint Planning

Sprint planning happens at the beginning of each sprint. The Scrum team decides which backlog items they will work on in the sprint and how to break them down into smaller tasks to achieve the sprint goal. During sprint planning, the team creates the sprint backlog, which includes detailed tasks for completing the selected product backlog items.

Daily Planning

The most granular level of planning happens during the daily scrum. The team members check in on what they have completed, what they plan to do next, and if they face any blockers. Rubin notes that this daily checkpoint allows the team to quickly identify potential problems and adjust their course of action. It’s a crucial moment for self-organization and real-time problem-solving.

This chapter lays out the multiple levels of planning that happen throughout a Scrum project, from strategy all the way down to daily execution. Scrum planning happens continuously, at various levels of detail, and each planning phase has a different purpose. By using examples like the Scrum Alliance website redesign, Rubin demonstrates how each of these levels is interrelated and contributes to the product’s overall success.

Chapter 16 – Portfolio Planning

Portfolio planning is about more than just organizing tasks—it’s about making smart, economical decisions

In organizations that manage multiple products, portfolio planning becomes crucial. The challenge is not just deciding which product to develop next but also determining how to manage the portfolio of ongoing and future projects in an economically sound way. This chapter introduces 11 strategies for portfolio planning, grouped by scheduling, product inflow, and product outflow. The goal is to ensure that portfolio decisions align with agile principles, avoiding common pitfalls that disrupt agility.

Portfolio planning is ongoing

Rubin stresses that portfolio planning is not a one-time task. It’s an ongoing process, as long as products need to be developed or maintained. Portfolio planning is crucial for managing a collection of products, and it involves decisions about which products to develop, in what order, and for how long.

Importantly, portfolio planning doesn’t just occur at the start of a product’s lifecycle; it’s a continuous activity that includes reviewing in-process products, products that are under development or already live. Each product’s progress and adjustments are factored in at regularly scheduled intervals.

Who participates in portfolio planning?

This process involves a range of participants. You have internal stakeholders who provide a broad business perspective, product owners advocating for their products, and technical leads or architects who ensure that technical constraints are factored into decisions. The entire team works together to make well-rounded decisions about which products to prioritize, when to develop them, and when to pull them out.

Four main activities in portfolio planning

Rubin breaks down the portfolio planning process into four key activities:

• Scheduling: Determining the sequence in which products in the portfolio will be developed.
• Managing inflows: Deciding when new products should enter the portfolio and how to evaluate them.
• Managing outflows: Deciding when to pull products out of the portfolio, based on various strategies.
• Managing in-process products: Monitoring ongoing products and deciding whether to preserve, pivot, deliver, or terminate them.

These four activities ensure that the portfolio is managed in a way that balances demand, capacity, and economic value.

Scheduling strategies

The goal of scheduling is to sequence products in a way that maximizes lifecycle profits. Rubin suggests several strategies to optimize the order in which products are developed:

• Optimize for lifecycle profits: Focus on the total profit a product can generate over its entire life cycle. When products have different sizes or delays, optimize for the product that brings the highest return relative to its development time (known as weighted shortest job first or WSJF).
• Calculate the cost of delay: This is a crucial factor in scheduling. By calculating the cost of delay, organizations can make more informed decisions about which products to prioritize. For example, a project with a high cost of delay might need to be prioritized over another with a higher return on investment but a lower cost of delay.
• Estimate for accuracy, not precision: When estimating the effort or cost for portfolio items, focus on getting a broad but accurate sense of effort rather than aiming for overly precise estimates. This keeps the planning process fast and practical, avoiding paralysis by overestimation.

Inflow strategies

Inflow strategies focus on managing the rate at which new products enter the portfolio. This involves using an economic filter to decide whether to approve a new product. The idea is to ensure that only the most valuable products pass through the filter, preventing too many low-value ideas from crowding the portfolio.

Rubin advises that organizations should avoid bottlenecks in the portfolio by maintaining a steady flow of incoming products, whether it’s monthly or quarterly, to keep the process smooth and efficient. Moreover, organizations should be prepared to take advantage of emergent opportunities—unexpected chances that arise and could add significant value to the business.

Outflow strategies

Once products are in the portfolio, it’s important to know when to pull them out. Rubin introduces several strategies to manage the outflow of products from the portfolio:

• Focus on idle work, not idle workers: Prioritize getting work done rather than simply keeping employees busy. Avoid the temptation to start new projects just because some team members are available. Instead, focus on finishing existing work first.
• Establish a WIP limit: Set limits on the number of products in the portfolio at any given time. This prevents overloading teams and ensures that they can focus on completing high-priority tasks before taking on new ones.
• Wait for a complete team: Rather than starting a project with an incomplete team, wait until the necessary resources are available. Starting with only part of the team can lead to delays and suboptimal work quality.

In-process strategies

Finally, managing products that are already in development is critical. The overarching strategy here is to apply marginal economics, where decisions about continuing, changing, or terminating a product depend on the additional investment required versus the value it will generate. This avoids falling into the trap of continuing to invest in failing projects simply because money has already been spent.

Portfolio planning is a strategic, ongoing process that allows organizations to make smart, economically sound decisions about how to manage multiple products. It involves balancing inflows, scheduling, and outflows while ensuring that in-process products are handled with a focus on their long-term value. Rubin’s emphasis is on continuous assessment, economic thinking, and avoiding wasteful or inefficient practices. This chapter provides a roadmap for organizations to align their portfolio planning with agile principles, optimizing value and minimizing risk.

Chapter 17 – Envisioning (Product Planning)

Envisioning: The first step to turning an idea into a product

This chapter introduces the concept of envisioning, a product-level planning process that helps bring a product idea to life, with just enough detail to move forward without getting bogged down in over-planning. Rubin emphasizes that envisioning is an ongoing process, not a one-time event. The goal is to generate enough understanding of the product’s potential to move to the next phase of development and make a go/no-go decision. Importantly, envisioning helps you quickly get to customer feedback and validated learning.

What is envisioning?

Envisioning takes an initial product idea and gives it shape. It includes creating a product vision, a product roadmap, and an initial product backlog. The focus here isn’t on having every detail worked out; instead, it’s about crafting a rough plan and generating enough clarity to test the idea against real user feedback. Rubin contrasts this agile approach with traditional, heavy project chartering, arguing that Scrum’s lighter touch makes it more flexible and responsive to change.

The process of envisioning

Envisioning begins with a product idea that has passed through a strategic filter, ensuring it aligns with the organization’s goals. This leads to creating the product vision, which serves as the guiding light for the product development. Once the vision is in place, teams begin defining the minimal first release—the simplest version of the product that can deliver value to users and provide actionable feedback. Rubin emphasizes that the goal is to fail fast if necessary, adjusting the product or abandoning it early if it doesn’t meet the users’ needs.

Participants in envisioning

The product owner plays a central role in envisioning, but the process also involves other stakeholders like market researchers, business case developers, and system architects. Depending on the stage, some of the Scrum team—particularly the ScrumMaster and development team—might participate as well. However, in many cases, the full Scrum team doesn’t get involved until the product development phase begins.

Creating the product vision

The product vision should be clear and simple. Rubin emphasizes that it should be brief, much like President Kennedy’s vision to land a man on the moon—short, specific, and inspiring. A well-crafted vision helps everyone involved understand the purpose of the product. Rubin offers various formats for a product vision, including the press release format (often used by the Scrum Alliance), where you imagine a press release about the product’s successful launch. The vision should also address the value it will deliver to stakeholders, such as time savings, differentiation, or improved customer experience.

For example, for the product SmartReview4You (SR4U), a vision statement was created based on the value it would provide to users, saving time and offering a differentiated, customer-pleasing service.

Defining the product backlog

Once the vision is in place, the next step is to create the product backlog—a prioritized list of features that will be developed. Rubin suggests starting with epics—high-level user stories that align with the product vision. These epics provide the foundation for the more detailed work to follow once development starts. For SR4U, the initial product backlog might include items like creating a simple interface for searching reviews or developing a mechanism to filter out biased reviews.

Product roadmap

The product roadmap is a high-level plan showing how the product will evolve over time. It defines the key releases and goals for the product’s lifecycle. Rubin advises that product roadmaps should focus on incremental releases that deliver value early and often. He also highlights the importance of defining a Minimum Releasable Feature (MRF)—the smallest set of features that must be included in the first release for it to meet customer expectations.

For SR4U, the roadmap might include initial learning and filtering capabilities, followed by more complex features like integrating with mobile platforms and refining the review filtering process based on feedback.

Economically sensible envisioning

Rubin stresses the importance of keeping envisioning economically sensible. This means spending just enough time and resources to get the necessary information to make an informed go/no-go decision. Too much envisioning creates waste in the form of speculative, unvalidated data that might need to be reworked once actual user feedback is collected. Rubin suggests setting a confidence threshold—a point at which the product team has enough data to confidently move forward with development. This threshold should be set carefully, as higher thresholds require more work and can delay the product.

Act quickly, learn fast, and pivot

Rubin advises that envisioning should be a fast, efficient process. The sooner the team can move from planning to execution, the sooner they can gather real feedback and validate (or invalidate) assumptions. If the product isn’t meeting expectations, it’s better to pivot early rather than invest more time and money into a failing direction.

In the case of SR4U, a knowledge-acquisition sprint was used during envisioning to test key assumptions about user preferences for filtered versus unfiltered reviews. This quick validation helped confirm the core value proposition of the product and reduced the risk of investing heavily in development without understanding user needs.

Envisioning is a crucial early step in product development that allows teams to quickly shape an idea into something tangible. It provides just enough planning to test assumptions and validate the product vision with real user feedback. The process is designed to be flexible and efficient, so that teams can quickly move from planning to learning, adapting their product along the way. Rubin stresses the importance of keeping envisioning efforts lean and focused, avoiding over-planning, and making data-driven decisions as soon as possible.

Chapter 18 – Release Planning (Longer-Term Planning)

Release planning is a bridge between vision and execution.

This chapter introduces release planning, an essential process in Scrum that helps teams answer important questions like “When will we be done?” or “What can we achieve by a certain date?” Release planning isn’t a one-time event, but a recurring activity that provides a roadmap for achieving product goals while balancing customer value against constraints such as scope, date, and budget.

Why release planning matters

The purpose of release planning is to set the stage for longer-term development. It ensures teams can manage product releases, aligning scope with deadlines, and most importantly, offering clear communication about what to expect. Whether teams choose to release after every sprint, after multiple sprints, or continuously, a release plan guides them on what features to prioritize and when to release them. Rubin notes that many organizations do not release after each sprint but instead combine the results of multiple sprints into a single release.

When does release planning happen?

Release planning happens early on but is continuously updated throughout the project. After envisioning and product-level planning, teams conduct initial release planning, which typically takes a day or two. However, it’s not fixed and will evolve as development continues, incorporating feedback and adjusting to real-world conditions. This planning ensures that teams are always aligned and can make informed decisions when adjustments are needed.

Participants in release planning

Release planning is a collaborative effort involving the entire Scrum team, stakeholders, and sometimes external participants like technical leads or product managers. These individuals bring different perspectives and expertise, helping make crucial business and technical decisions. As the project progresses, stakeholders may come in and out of the planning process, but the Scrum team stays involved throughout.

Key activities in release planning

Several activities define the release planning process. First, grooming the product backlog is essential to ensure that the items are refined, estimated, and prioritized for the release. This involves breaking down larger epics into manageable user stories. The goal is to create a minimum releasable feature set (MRF), which defines the smallest feature set that must be included to deliver value to the customers.

Another key activity is sprint mapping. In this step, teams start planning which features will be worked on in each sprint, based on their velocity (how much work they can accomplish in a sprint). The sprint map isn’t set in stone but helps visualize the near-term future, ensuring better resource management and coordination between teams. Rubin explains that sprint mapping can also be used in multi-team environments to track dependencies and resource constraints.

Release constraints

A major focus of release planning is managing the constraints of scope, date, and budget. These factors often dictate how the release will unfold. For example, with a fixed-date release, teams must prioritize completing key features within a set timeframe. On the other hand, with a fixed-scope release, the deadline may shift, but the scope of features remains constant.

Rubin explains that traditional project planning methods often lead to a “fixed everything” approach, where scope, date, and budget are all set from the start. This, he argues, doesn’t align with Scrum’s flexible approach. Instead, one constraint (either scope, date, or budget) needs to remain flexible, allowing adjustments as development progresses.

Fixed-date vs. Fixed-scope planning

• Fixed-date release planning: This approach is common in Scrum and aligns closely with Scrum principles. Here, teams agree on a fixed release date and scope flexibility. The priority is to complete high-value features first. When time runs out, lower-value features are dropped.
• Fixed-scope release planning: In situations where the scope is more important than the release date, teams extend the deadline to ensure the full scope is completed. Rubin warns that while this is possible, it often leads to complications like increased costs and burnout, especially if the team is asked to work extra hours or add more resources.

Communication and progress tracking

As with many Scrum activities, communication is key. To track progress in a release, teams use tools like burndown charts or burnup charts. These visual aids show how much work remains for a fixed-scope release or how the range of features will change over time for a fixed-date release. They help teams monitor progress and make informed decisions about whether to proceed as planned or adjust based on real-time data.

Release planning ensures teams know what they are working toward and helps balance the constraints of scope, date, and budget. It’s an ongoing process that evolves with the product, making sure teams stay on track to deliver value while remaining adaptable. Rubin emphasizes that Scrum’s iterative nature provides flexibility—teams can always adjust the release plan based on validated learning and new insights, which helps them stay aligned with both business goals and customer expectations.

Chapter 19 – Sprint Planning

Sprint planning is the foundation for successful sprints

In Scrum, sprint planning kicks off each sprint, setting the stage for what the team will focus on and how they will achieve it. Rubin emphasizes that sprint planning is essential for delivering customer value consistently, ensuring the team knows exactly what needs to be done during the sprint. This chapter dives into the mechanics of sprint planning, highlighting who is involved, how it works, and the different approaches teams can take.

Why sprint planning matters

Sprint planning helps the Scrum team answer two key questions:

1. What can we deliver by the end of this sprint?
2. How will we accomplish it?

The product backlog is a prioritized list of all the features and work that might be done, but it’s too large to tackle in a single sprint. Sprint planning narrows that down, setting a clear sprint goal and selecting which product backlog items (PBIs) will be worked on.

Who participates in sprint planning?

Everyone in the Scrum team is involved in sprint planning. The product owner plays a key role by communicating the sprint goal, presenting the prioritized product backlog, and answering any questions from the team. The development team is responsible for selecting the PBIs they can realistically commit to delivering. The ScrumMaster serves as a facilitator, ensuring the team stays focused and that the process is smooth.

Inputs to sprint planning

Successful sprint planning relies on several inputs:

• Product backlog: It should be well-groomed, with clearly defined, sized, and estimated PBIs.
• Team velocity: The team’s historical capacity helps estimate how much work can be realistically completed.
• Team capabilities: The team’s skills and availability for the sprint, including any known constraints (e.g., team members’ schedules).
• Initial sprint goal: The product owner provides an initial goal, which can evolve during the planning process.

The sprint planning process

Rubin outlines two primary approaches for sprint planning: two-part sprint planning and one-part sprint planning.

• Two-part sprint planning involves:
  1. The team first selects what they will work on (the “what” part).
  2. They then acquire confidence in their ability to complete it by creating a plan, breaking down PBIs into tasks, and estimating the work (the “how” part). This allows for adjustments and refinements to ensure the goal is achievable.
• One-part sprint planning is a more continuous approach where the team alternates between selecting work and confirming that it can be completed, refining the plan as they go.

Determining capacity

Capacity is a critical factor in sprint planning. The team must consider not just the work required for the sprint, but also time for activities like sprint planning, reviews, retrospectives, and backlog grooming. They should also account for personal time off and other commitments outside of the sprint.

Once these factors are considered, the team can estimate its available capacity in story points or effort-hours. The goal is to commit to work that fits within the team’s available capacity while leaving room for unexpected challenges.

Selecting product backlog items (PBIs)

Selecting the right PBIs is crucial for the sprint. If the team has a clear sprint goal, the PBIs that support that goal should be prioritized. If there is no specific goal, the team can start from the top of the backlog, selecting items based on priority and their ability to complete them within the sprint.

Rubin stresses the importance of not starting what you cannot finish. If a PBI is too large to be completed within the sprint, it should be broken down or replaced with something smaller. Having a definition of ready ensures that items selected for the sprint are well-defined and can be completed without major issues.

Acquiring confidence in the commitment

Once PBIs are selected, the team needs to confirm they can realistically complete the work. This is done by breaking each PBI into tasks, estimating the effort required, and ensuring that the total work doesn’t exceed the team’s capacity.

Velocity can be a helpful tool in assessing whether the commitment is realistic. If the team predicts a velocity of 25 story points but has committed to 45, that’s a red flag. Confidence is gained by ensuring the selected tasks fit within the available capacity and by addressing any potential issues that could prevent the team from meeting their commitment.

Refining the sprint goal

The sprint goal is the business objective the team aims to achieve by the end of the sprint. It is initially proposed by the product owner but can be refined during sprint planning based on the team’s feedback and selected PBIs.

Finalizing the commitment

At the end of sprint planning, the team makes a commitment to deliver the selected PBIs by the sprint’s end. Rubin notes that some prefer the term “forecast” instead of “commitment,” but the principle remains the same: the team agrees on the work they believe they can realistically complete, based on their capacity and the sprint goal.

Sprint planning is a crucial process that sets the direction for the sprint. It involves selecting work that aligns with the sprint goal, determining the team’s capacity, and breaking down PBIs into tasks. With careful planning, teams can confidently commit to delivering value in the upcoming sprint. Whether using a two-part or one-part approach, the goal is the same: ensuring that the team is aligned, focused, and capable of achieving its sprint goals.

Chapter 20 – Sprint Execution

Sprint execution is the heartbeat of Scrum

Sprint execution is where the majority of the work happens. After sprint planning, the Scrum team focuses on meeting the sprint goal and delivering a potentially shippable product increment. This chapter emphasizes how sprint execution is guided by principles and techniques that enable the team to manage their work efficiently and effectively.

What is sprint execution?

Sprint execution encompasses all the activities needed to transform the sprint backlog into a completed product increment. It involves planning, managing, performing, and communicating during the sprint. Rubin compares it to a mini-project that happens within the larger product development cycle.

Who participates in sprint execution?

During sprint execution, the development team takes the lead. The ScrumMaster plays a supporting role as a coach, facilitator, and impediment remover but does not assign work. The product owner remains available to clarify questions and verify that the sprint backlog’s acceptance criteria are met.

The development team is expected to be self-organizing, meaning they decide how best to meet the sprint goal without needing a project manager to direct them. They are responsible for task planning and adapting as needed.

Sprint execution planning

Although teams may create a task-level sprint execution plan at the beginning, Rubin argues that trying to detail every step of the sprint up front is counterproductive. The real learning happens during the sprint, and plans must adapt. While some initial task-level planning is useful (especially for uncovering dependencies), too much upfront planning wastes valuable time. Opportunistic task planning is a better strategy: tasks should be planned and re-planned continuously based on evolving circumstances.

Flow management

Managing the flow of work is a critical aspect of sprint execution. The team must decide how much work to handle in parallel, how tasks should be organized, and who will do what. Overloading the team with too many tasks (multitasking) or underutilizing team members can harm progress. Instead, teams should aim for swarming—where team members with available capacity focus on finishing a task before starting a new one. This keeps work flowing smoothly and prevents unfinished tasks from stacking up.

Swarming vs. multitasking

Swarming is the opposite of multitasking. When team members work on too many tasks simultaneously, progress on each one slows down, and errors become more frequent. Rubin uses a simple example—two ways of completing a task involving writing letters, numbers, and Roman numerals—to demonstrate the inefficiency of multitasking. The “row-at-a-time” method (multitasking) takes twice as long as the “column-at-a-time” method (single-tasking). For Scrum, swarming focuses on completing fewer tasks but doing them well and fast.

What work to start?

Teams generally begin by working on the highest-priority items in the product backlog. However, technical dependencies or team capacity constraints may require the team to adjust the order of work. Flexibility is key, and the team must opportunistically make decisions about what to work on next as new challenges arise.

How to organize task work

Rubin emphasizes that teams should not follow a rigid sequence (like waterfall) of analysis, design, coding, and testing. Instead, they should organize work iteratively and collaboratively, with team members working together on all aspects of the product. For example, testers can begin creating tests while developers start coding, ensuring that the process flows smoothly without bottlenecks.

Who does the work?

Tasks should be assigned to the team member best equipped to complete them quickly and correctly. However, Scrum emphasizes collective responsibility, meaning any team member with the right skills can take on a task. Teams with T-shaped skills—where members have deep expertise in one area but also the ability to contribute across other areas—are better equipped to manage flow and keep work moving smoothly.

Daily Scrum

The daily scrum is a key event in sprint execution. This brief, 15-minute meeting allows team members to synchronize, discuss progress, and identify obstacles that might hinder the flow. By meeting daily, the team ensures that issues are addressed quickly and can adapt their approach as needed.

Technical practices for success

Successful sprint execution depends on solid technical practices. Teams need to be proficient in skills like continuous integration, automated testing, refactoring, and test-driven development. Rubin stresses that without these practices, teams risk accumulating technical debt, which could slow progress and prevent them from delivering value.

Communicating progress

Throughout the sprint, Scrum teams communicate progress visually. Rubin highlights the importance of task boards, burndown charts, and burnup charts as ways to track and communicate how much work remains and how quickly it’s being completed. These tools provide clear, real-time feedback and help the team stay focused on the sprint goal.

Sprint execution is where Scrum teams bring their work to life. It involves continuously managing tasks, maintaining flow, and adjusting plans as necessary. The key to successful sprint execution lies in self-organization, collaboration, and the use of visual tools to communicate progress. By focusing on quality, maintaining flow, and keeping the sprint goal in mind, teams can deliver a potentially shippable product increment at the end of each sprint.

Chapter 21 – Sprint Review

Sprint review: Inspecting the product increment

The sprint review is a critical inspect-and-adapt event that occurs near the end of each sprint. It’s the time for the Scrum team and stakeholders to come together and assess the product increment created during the sprint. The review allows everyone to inspect what has been built so far and to adjust the product direction if needed. Rubin emphasizes that the sprint review is vital for making course corrections early, ensuring that the team is creating a successful product.

Why sprint reviews are essential

The sprint review provides transparency about the current state of the product, which helps to identify inconvenient truths early. It’s an opportunity for the team to receive feedback from those who may not be involved day-to-day, such as executives, business owners, or customers. Rubin argues that waiting too long for feedback leads to surprise, disappointment, and frustration, while frequent reviews help the team adapt quickly and keep the product on track.

Who participates in sprint reviews

The sprint review is open to all interested parties. Rubin breaks this down into the following participants:

1. The Scrum team: The product owner, ScrumMaster, and development team should all attend. This allows them to hear the same feedback and answer any questions.
2. Internal stakeholders: Business owners, executives, managers, and subject matter experts should attend to provide feedback and ensure the product is progressing toward a successful outcome.
3. Other internal teams: Sales, marketing, support, legal, and compliance teams may also join to provide input and align with the Scrum team’s progress.
4. External stakeholders: Customers or partners can provide direct feedback, ensuring the product is heading in the right direction.

Prework before the sprint review

Though the sprint review is informal, there are key steps for preparation:

• Determine who to invite: While the core team should always attend, the product owner decides whether additional stakeholders or external participants should be invited based on the sprint’s focus.
• Schedule the review: It’s important to find a time that works for key stakeholders and align the review with the regular sprint cadence. Rubin suggests using a consistent schedule for convenience.
• Confirm completed work: Before the review, the team must ensure that the product increment meets the agreed-upon definition of “done.” The product owner is responsible for confirming this.
• Prepare the demonstration: While the demonstration doesn’t need to be overly polished, it’s crucial that it clearly showcases the work completed and provides transparency.

What happens during the sprint review?

1. Synopsis: The product owner or Scrum team presents a summary of what was accomplished during the sprint, discussing how it aligns with the sprint goal.
2. Demonstration: The team demonstrates the potentially shippable product increment, showing stakeholders the progress made.
3. Discussion and feedback: The sprint review is an opportunity for stakeholders to ask questions, suggest changes, and discuss how the product should evolve. This conversation helps inform the next steps in development.
4. Adaptation: Based on the feedback, the product backlog may be updated, and adjustments to the release plan can be made.

The importance of the demonstration

While the sprint review is often called a “demo,” the true value comes from the in-depth conversation and feedback that follows the demonstration. Rubin stresses that the demo is just a tool to spark these discussions. Stakeholders should focus on the product’s direction, market fit, and value rather than just the technical aspects of the demo.

What if there’s nothing to demo?

If the team doesn’t have a product increment to demonstrate, the sprint review focuses on discussing why this happened and how it impacts future work. Rubin advises that even if a product is hard to demo, such as architectural work, the team should find ways to show progress, even if it’s through automated tests or other relevant artifacts.

Common issues with sprint reviews

1. Sign-offs: Sprint reviews should not be used as formal sign-off events. The product owner is responsible for declaring work “done” before the review. However, feedback can lead to new backlog items or changes to existing ones.
2. Sporadic attendance: Sometimes stakeholders don’t attend sprint reviews. Rubin suggests that if this is a recurring issue, it indicates that the product isn’t valuable enough for stakeholders to attend regularly. In such cases, the team might consider pausing lower-priority work until stakeholders are more engaged.
3. Large development efforts: For larger projects with multiple Scrum teams, Rubin recommends holding a joint sprint review to ensure all teams’ work is integrated and reviewed together.

The sprint review is an essential part of the Scrum process, providing transparency and allowing stakeholders to give feedback on the product. It helps teams stay aligned with customer needs and course-correct when necessary. With minimal preparation and a focus on collaboration, the sprint review ensures that the team is consistently moving in the right direction.

Chapter 22 – Sprint Retrospective

The Sprint Retrospective: A time for continuous improvement

The sprint retrospective is one of Scrum’s two inspect-and-adapt opportunities at the end of each sprint, the other being the sprint review. While the sprint review focuses on inspecting the product, the sprint retrospective is all about examining the team’s processes and ways of working. Rubin explains that retrospectives allow the Scrum team to reflect on the past sprint, make necessary adjustments, and improve how they work together to create value. These meetings are key to fostering continuous improvement within the Scrum framework.

Why retrospectives matter

Rubin emphasizes that retrospectives are vital because they offer the team a dedicated space to stop “bumping along” and think critically about their approach to work. Without this time for reflection, teams risk getting stuck in their old habits, not realizing the inefficiencies or obstacles that might be slowing them down. The retrospective allows the team to adjust and improve incrementally, thus avoiding stagnation and continually enhancing team dynamics and productivity.

Who participates in the retrospective?

All members of the Scrum team—product owners, developers, and ScrumMasters—are expected to participate in the sprint retrospective. Rubin discusses that product owners should be part of the retrospective, although in some situations, having them present might inhibit open discussions. If trust is an issue, the ScrumMaster should help coach the team to create a safe environment. However, stakeholders or managers who aren’t part of the Scrum team should only attend if invited. It’s important that the team feels comfortable sharing openly, which might be compromised if external participants are present.

Preparing for the retrospective

Preparation for the retrospective is critical. The team needs to define the focus of the retrospective and ensure that any necessary data is gathered beforehand. A retrospective’s focus can vary depending on what the team feels needs attention, such as improving a specific technical practice like test-driven development (TDD) or addressing communication issues. Rubin stresses that the prework should be light and flexible, with the team’s focus and exercises chosen based on the current challenges or opportunities for improvement.

Key activities in the retrospective

Once the retrospective begins, the team engages in several activities to explore their experiences and identify areas for improvement. The core activities involve setting the atmosphere, creating a shared context, identifying insights, and determining actionable improvement actions. Rubin suggests several exercises to facilitate these activities, such as creating an event timeline or an emotions seismograph to visualize the team’s emotional highs and lows throughout the sprint.

• Setting the atmosphere: This helps participants feel safe and comfortable. Teams should establish a culture of trust, where everyone feels free to share their thoughts without fear of blame.
• Creating a shared context: The team should align their perspectives by grounding their discussion in objective data, such as task completion rates or defect counts. This helps ensure that the conversation is based on facts rather than personal opinions.
• Identifying insights: After the context is set, the team can begin to explore what worked, what didn’t, and where there are opportunities to improve. Rubin recommends organizing insights through exercises like silent grouping to identify patterns or common issues.
• Determining actions: The most important part of the retrospective is determining concrete actions that the team can take to improve in the next sprint. These actions should be practical and achievable within the team’s capacity.

Prioritizing insights

Given the limited capacity and time available, it’s essential that the team prioritize which insights to act on immediately. Rubin suggests using dot voting, where each participant places a few dots on the insights they believe should be addressed first. The team then decides which improvements to focus on for the upcoming sprint.

Some insights may not be actionable immediately and should be added to an insight backlog for future consideration. This ensures that valuable feedback isn’t forgotten but can be revisited when the team has the capacity to address it.

Following through on actions

Rubin highlights that the real value of the retrospective comes from following through on the improvement actions decided during the meeting. The team should integrate these actions into their sprint backlog and allocate time for them. Improvement actions shouldn’t be treated separately from feature work, as doing so might lead to neglecting them. The ScrumMaster plays an important role in ensuring that the team follows through and that actions are taken to address impediments identified during the retrospective.

Challenges in retrospectives

Not all retrospectives go smoothly. Rubin identifies several common problems:

1. Low attendance: Teams sometimes skip retrospectives or fail to attend fully. This could be due to lack of engagement or scheduling conflicts.
2. Lack of follow-through: Even if actions are identified, teams may fail to follow through, wasting the time spent in the retrospective.
3. Blame culture: If the retrospective becomes a forum for finger-pointing or blame, it loses its value. The ScrumMaster should prevent this by maintaining a safe and constructive atmosphere.
4. Poor facilitation: A retrospective might be ineffective if not facilitated well. Sometimes, an external facilitator can help reset the team and provide fresh perspectives.
5. Being too ambitious: New teams, in particular, can overcommit to improvement goals, setting themselves up for disappointment if they fail to meet unrealistic targets.

Sprint retrospectives are crucial for Scrum teams to inspect their processes and identify improvements. By focusing on continuous improvement and creating a safe space for open communication, retrospectives enable teams to evolve and work more effectively. Rubin underscores the importance of follow-through—without it, the retrospective becomes a wasted exercise. Ultimately, retrospectives are one of the most powerful tools in Scrum for adapting to challenges and driving ongoing improvement.

Chapter 23 – The Path Forward

There’s no finish line in Scrum—just the next step forward

In this final chapter, Rubin emphasizes that adopting Scrum isn’t about reaching some perfect end state. There is no “done” when it comes to being agile. The whole point of Scrum is to embrace continuous improvement. That means no matter how good your team or organization gets, there’s always room to grow, adapt, and do better.

Rubin challenges the idea that agility is a destination. As he quotes Mike Cohn: “Agile is not something you become, it’s something you become more of.” That mindset shift—from trying to “achieve agility” to constantly becoming more agile—is at the heart of this chapter.

Find your own way—there’s no universal Scrum path

Rubin argues that you can’t follow someone else’s path and expect it to work perfectly for you. Every team, product, and organization is different. Sure, you can learn from others, but your context, goals, and challenges will shape your Scrum implementation. You have to discover your own path.

And that means learning by doing—inspecting and adapting based on real experience, not theory. You can’t shortcut the learning process by copying another company’s “best practices.” In fact, Rubin makes a distinction between practices (which are core to Scrum) and approaches (which are how a specific team might implement a practice). Practices are non-negotiable in Scrum—things like daily scrums, product owners, and sprint reviews. But how you do those things? That’s up to your team.

For example, he shares a story of a Canadian team that used a toy moose to choose who would speak first in the daily scrum. It was fun and worked for them. But when a sister team in China tried to adopt it, the cultural translation failed miserably. The lesson? Don’t blindly copy even something as small as how to start a meeting—context matters.

Use Scrum to transform your organization—iteratively

Rubin then tells the story of a large multinational company that adopted Scrum across hundreds of IT staff. They didn’t roll out Scrum all at once. They started with pilot teams and used Scrum to scale Scrum—forming what’s called an Enterprise Transition Community (ETC) to manage the transition itself using Scrum sprints. This group handled bigger organizational changes like compensation models or infrastructure blockers. The key was to take it one step at a time, based on what the teams were learning in real-time.

There was no master plan or final picture of what “Scrum done right” looked like for them. Instead, they focused on making incremental improvements, using feedback from real teams doing real work.

Just get started—you’ll figure it out as you go

One of the strongest messages in this chapter is: don’t wait for the perfect plan before you begin. Rubin finds it ironic that people who believe you can’t get product requirements right up front still think they need to fully plan their Scrum implementation before starting.

He argues that you won’t figure everything out in advance—and that’s okay. The first few sprints might be messy. That’s okay too. The important thing is to improve sprint by sprint. You’ll learn more in one sprint than you will from any amount of upfront planning.

Expect resistance—and keep going anyway

Scrum shines a bright light on dysfunctions in organizations, and not everyone likes that. Rubin warns that some will try to ignore Scrum, change it, or even kill it rather than confront uncomfortable truths. That’s why being a patient, steady force for change is so important.

He encourages readers to educate others, meet resistance with understanding, and chip away at the obstacles over time. Scrum isn’t easy, especially when it challenges deeply held behaviors and systems—but that’s exactly what makes it valuable.

This chapter closes the book with a reminder that Scrum is a journey, not a checklist. There’s no “Scrum certification” for an organization, no final score to reach. The real work is about continuous improvement, discovering your own approaches, and growing more agile over time. It’s messy, it’s hard, and it’s worth it.

So as Rubin puts it: Get going. Don’t wait. Learn by doing. And become better with each step.

4 Key Ideas from Essential Scrum

6 Main Lessons from Essential Scrum

My Book Highlights & Quotes

“… Plan-driven development works well if you are applying it to problems that are well-defined, predictable, and unlikely to undergo any significant change…”

“… The product owner is responsible for what will be developed and in what order. The ScrumMaster is responsible for guiding the team in creating and following its own process based on the broader Scrum framework. The development team is responsible for determining how to deliver what the product owner has asked for…”

“… Grooming refers to a set of three principal activities: creating and refining (adding details to) PBIs, estimating PBIs, and prioritizing PBIs…”

“… A product backlog item can be considered done only when both the item-specific acceptance criteria (for example, “works with all of the credit cards”) and the sprint-level definition-of-done (for example, “live on the production server”) items have been met…”

“… In product development, however, the goal is to create a unique single instance of the product, not to manufacture the product…”

“… Whereas the sprint review is a time to inspect and adapt the product, the sprint retrospective is an opportunity to inspect and adapt the process…”

“… As a general rule, the development team should allocate up to 10% of its time each sprint to assisting the product owner with grooming activities…”

“… The fact is, when developing innovative products, you can’t create complete requirements or designs upfront by simply working longer and harder. Some requirements and designs will always emerge once product development is underway; no amount of comprehensive up-front work will prevent that…”

“… Scrum is a refreshingly simple, people-centric framework based on the values of honesty, openness, courage, respect, focus, trust, empowerment, and collaboration…”

“… Each day during sprint execution, the team members help manage the flow of work by conducting a synchronization, inspection, and adaptive planning activity known as the daily scrum…”

“… Scrum embraces the fact that in product development, some level of variability is required in order to build something new…”

“… Scrum can be used for new product development and Kanban for interrupt-driven support and maintenance…”

“… Iterative development acknowledges that we will probably get things wrong before we get them right and that we will do things poorly before we do them well…”

“… Incremental development is based on the age-old principle of “Build some of it before you build all of it…”

“… With an agile approach, you begin by creating a product backlog — a prioritized list of the features and other capabilities needed to develop a successful product. Guided by the product backlog, you always work on the most important or highest-priority items first. When you run out of resources (such as time), any work that didn’t get completed will be of lower priority than the completed work…”

“… The work itself is performed in short, timeboxed iterations, which usually range from a week to a calendar month in length. During each iteration, a self-organizing, cross-functional team does all of the work — such as designing, building, and testing — required to produce complete, working features that could be put into production…”

“… Typically the amount of work in the product backlog is much greater than can be completed by a team in one short-duration iteration. So, at the start of each iteration, the team plans which high-priority subset of the product backlog to create in the upcoming iteration…”

“… At the end of the iteration, the team reviews the complete features with the stakeholders to get their feedback. Based on the feedback, the product owner and team can alter both what they plan to work on next and how the team plans to do the work…”

“… At the end of each iteration, the team should have a potentially shippable product (or increment of the product), one that can be released if appropriate…”

“… Though Scrum is an excellent solution for many situations, it is not the proper solution in all circumstances. The Cynefin framework (Snowden and Boone 2007) is a sense-making framework that helps us understand the situation in which we have to operate and decide on a situation-appropriate approach…”

“… Scrum is not a silver bullet or a magic cure. Scrum can, however, enable you to embrace the changes that accompany all complex product development efforts…”

“… Although the Scrum framework is simple, it would be a mistake to assume that Scrum is easy and painless to apply. Scrum doesn’t prescriptively answer your process questions; instead, it empowers teams to ask and answer their own great questions. Scrum doesn’t give individuals a cookbook solution to all of their organizational maladies; instead, Scrum makes visible the dysfunctions and waste that prevent organizations from reaching their true potential…”

“… Plan-driven processes (waterfall, traditional, sequential, anticipatory, predictive, or prescriptive development processes )are so named because they attempt to plan for and anticipate upfront all of the features a user might want in the end product and to determine how best to build those features. The idea here is that the better the planning, the better the understanding, and therefore the better the execution…”

“… Plan-driven development works well if you are applying it to problems that are well-defined, predictable, and unlikely to undergo any significant change. The problem is that most product development efforts are anything but predictable, especially at the beginning. So, while a plan-driven process gives the impression of an orderly, accountable, and measurable approach, that impression can lead to a false sense of security. After all, developing a product rarely goes as planned. [P]lan-driven development approaches are based on a set of beliefs that do not match the uncertainty inherent in most product development efforts…”

“… Scrum, on the other hand, is based on a different set of beliefs — ones that do map well to problems with enough uncertainty to make high levels or predictability difficult…”

Conclusion

Essential Scrum isn’t a book about rules—it’s a book about better ways of thinking, working, and improving together.

It respects your time, trusts your intelligence, and meets you where you are.

Whether you’re just dipping your toes into Agile or leading a full transformation, this book gives you both the mindset and the map to take the next step.

And once you finish it, you’ll see that the real journey is just beginning.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: