Meet the Ranch Hand Games team

They’re hot off the successful release of Cows Gone Wild IV: The Milk Man Cometh, and about to tackle their most ambitious project yet! But while CGW4 may have sold well, it was far from perfect as a project, and Amy, Brian, and Rick want CGW5 to be an improvement. Agile to the rescue!

Amy: Wow, I’m so glad you said that. I can’t take another project like that. Just staying on top of the last-minute artwork changes was practically impossible.

Brian: Oh man, we can’t have that argument again. You know they were necessary because the levels kept changing. I had my whole team working nights and weekends just to keep up.

Amy: I know, I know. We all got overwhelmed trying to tackle too many things at the same time.

Brian: No matter how much planning we did, our schedules never seemed long enough.

Rick: Yeah, that was definitely a problem—and I’ve been doing a lot of research about how to fix that. What do you guys think about using Scrum?

Amy: I’ve been reading about it, too. I think it could help.

Brian: Look, anything that can help make things less insane around here gets my vote.

Amy: But don’t the Scrum rules say that we need a Product Owner and a Scrum Master?

Rick: Well, I’m looking over what a Scrum Master does, and I think I’m up to that task. Amy, you work with the business side a lot, right? What do you think about being the Product Owner?

Amy: I’ll try anything once. I’ll start letting the business and PR teams know that I’m the Product Owner.

Brian: Let’s do this!

The Scrum events help you get your projects done

Scrum is the most popular approach to agile, and for good reason. The rules of Scrum are simple, and teams all around the world have been able to adopt them and improve their ability to deliver projects. Every Scrum project follows the same pattern of behavior, which is defined by a series of timeboxed events that always happen in the same order. Here’s what the Scrum pattern looks like:

The Scrum roles help you understand who does what

There are three roles that must be filled on every Scrum team. The first role is the one that’s most familiar to us: the Development Team. People on the team may have different areas of expertise, and maybe even different job titles in the company, but they all participate in the Scrum events the same way. There are also two very important roles filled by team members: the Product Owner and the Scrum Master. And when you add them to the Development Team, you get the entire Scrum Team.

The Product Owner helps the team understand the users’ needs so they can build the most valuable product.

The Product Owner works with the team every day to help them understand the features in the Product Backlog: what items are on it and why the users need them. This is a really important job because it helps the team build the most valuable software they can.

The Scrum Master helps the team understand and execute Scrum.

Scrum may be simple to describe, but it’s not always easy to get right. That’s why there’s one person on the team, the Scrum Master, whose whole job is to help the Development Team, the Product Owner, and the rest of the company to do exactly that—get Scrum right.

The Scrum Master is a leader (which is why the word “master” is right there in the name). But he or she demonstrates a very particular kind of leadership: the Scrum Master is a servant leader. This means that the person in this role spends all of his or her time helping (or “serving”) the Product Owner, the Development Team, and people throughout the organization:

• Helping the product owner find effective ways to manage the backlog

• Helping the Development Team understand the Scrum events, and facilitating them if needed

• Helping the rest of the organization to understand Scrum and work with the team

• Helping everyone do the best job they can to deliver the most valuable software possible

The Scrum artifacts keep the team informed

Software projects run on information. The team needs to know about the product that they’re working on, what they’re building in the current Sprint, and how they’ll get it built. Scrum teams use three artifacts to manage all of this information: the Product Backlog, the Sprint Backlog, and the Increment.

there are no Dump Questions

Q: Wait, is that all there is to Scrum?

A: That’s all of the Scrum rules, but that’s definitely not all there is to Scrum. Scrum was designed to be lightweight and simple to understand. But mastering Scrum takes a lot more than just following the rules. You learned in the last chapter how the values of the Agile Manifesto can make a big difference in how a team uses a practice. That same idea applies to Scrum: mindset and experience make the difference between a team with an empty “just following the rules” approach and an effective Scrum team that really “gets” it.

Q: I already break my projects into phases. Aren’t Sprints the same thing?

A: Not at all. Traditional waterfall projects are often broken into phases, with a complete deliverable at the end of each phase. But those phases are still planned at the beginning of the project. And if there’s a change discovered that will affect the next phase, the project needs to be replanned, which usually involves a separate change control process. In other words, the team basically assumes the project plan is mostly correct, and that it’s the project manager’s job to deal with the relatively few changes that happen along the way.

Scrum is different because it’s iterative, which is a lot more than just breaking a project down into phases. The team doesn’t even plan the next iteration until the current one is complete. The team might discover changes partway through the Sprint that affect the next one, or which may even affect the current one. That’s why the Product Owner is such an important member of the team: he or she has the authority to make decisions on behalf of the business or customers about what features the team will build, which gives them the power to make those changes immediately.

Q: What’s the difference between the Product Backlog and the Sprint Backlog?

A: The Product Backlog contains a list of everything that might be needed in the product. Scrum teams are usually working on ongoing releases of a single product, so the Product Backlog is never complete. The first version they release typically contains the requirements that are best understood by everyone. As the project goes on, the Product Owner will add and remove items based on what’s valuable to the company.

The Sprint Backlog contains the specific items that the team will build during the Sprint, which were moved from the Product Backlog during Sprint Planning. The software that the team finishes during the Sprint is the Increment: the team delivers and reviews a complete Increment in each Sprint. The Sprint Backlog also contains a plan for delivering the Increment. The team builds that plan during Sprint Planning by decomposing backlog items into tasks.

Q: What exactly is a backlog item?

A: Every item in the Product Backlog consists of a brief description, a (usually rough) estimate of how long it will take, the business value, and an order. The Product Owner will routinely refine the Product Backlog. This means going through the items in the backlog, removing ones that are no longer useful, re-evaluating the value of each item, and updating the order so the most valuable ones are first.

Q: Wait a minute—in the story, Brian is a team lead. But there are only three roles in Scrum, and “team lead” isn’t one of them. What’s going on there?

A: Roles and jobs aren’t the same thing. As far as Scrum is concerned, Brian is just another member of the Development Team, even though his job in the company is team lead, giving him more authority than the other the developers, and he has his own skills and expertise. Scrum may not have a distinct role for him to play, but he still plays an important and unique role on the team. It’s just that there are no Scrum-related events or artifacts that are specific to him.

Q: What do you mean by “artifacts”?

A: An artifact is just a by-product specific to a process or methodology. Scrum has three artifacts: the Product Backlog, the Sprint Backlog, and the Increment.

Q: What happens if we get partway through a Sprint and discover there’s some sort of emergency situation? Do we still have to wait for the timebox to expire before the Sprint can end?

A: On very rare occasions the Product Owner has the authority to cancel the Sprint before the timebox is over. When he or she does this, a Sprint Review is held for any Sprint Backlog items that are done, and all other items are put back on the Product Backlog and left for the next Sprint Planning session. Be really, really careful about cancelling a Sprint. It’s an in-case-of-emergency “break glass” action because it can waste a lot of the team’s energy—and more importantly, it causes people in the company to distrust the team, and to lose confidence in the effectiveness of Scrum.

Scrum was designed to be lightweight and simple to understand, but mastering Scrum takes a lot more than just following the rules.

Rick: Hey, there’s no need for insults. We’re all doing our best here!

Amy: Sorry. Things have just been really tense with the business lately, and it’s got me on edge. I spend so much time with Scrum that I don’t have time to do my job.

Rick: What do you mean?

Amy: I mean, you guys constantly ask me to make decisions. Like when we were planning this Sprint, and I had to decide whether Brian’s team should start the strategic silo assault level or improve the milk grenade mechanics.

Rick: Yeah. You had us get started on the strategic silo assault. Was that wrong?

Amy: Oh man, you have no idea! After the demo I got hauled into the CEO’s office and screamed at for an hour. Gamers hated the strategic levels in CGW4, and the last thing our stakeholders want is to see bad reviews for them in CGW5.

Rick: Wait, what? We worked super hard on those. I thought they came out well!

Amy: Me too. But they said that I had no business making the decision to include any strategic levels in the Sprint—or any other decision like that.

Rick: But you’re the Product Owner! Making those decisions is part of your job now.

Amy: Exactly. So I have no idea what to do. Plus, I spend so much time answering the team’s questions about features that I barely have time for my real job.

Rick: Well, it’s no easier for me. It’s getting harder and harder to drag Brian’s team members into my Daily Scrums—you know how programmers hate meetings.

Amy: You know what? We’re following the Scrum rules, it’s kind of helping. I think. Right? Maybe? Um... are we still sure this Scrum stuff is actually worth the trouble?

The Scrum values make the team more effective

We already saw how agile teams are much more effective when everyone on the team has a mindset that’s driven by the values in the Agile Manifesto. Scrum comes with its own set of five values that do exactly the same thing for Scrum teams.

You always know what your team members are working on, and you’re comfortable that they know what you’re working on. If you run into a problem or an obstacle, you can bring it up with the team.

It’s not always easy to talk to your teammates when you run into problems. None of us like making mistakes, especially at work. That’s why everyone on the team needs to share this value: it’s a lot easier to be open with teammates about problems and roadblocks that you run into if they’re just as open with you about theirs—and that helps the whole team.

You and your teammates have mutual respect for each other, and every person on your team trusts everyone else to do their jobs.

Trust and respect go hand in hand. People on Scrum teams listen to each other, and when they disagree they take the time to understand each other’s ideas. It’s natural for people on teams to disagree on an approach. On an effective Scrum team, you’ll listen when your teammates disagree with the approach you’re taking, but in the end they’ll respect your decisions, and give you the benefit of the doubt if you take an approach they disagree with.

Scrum teams have the courage to take on challenges. Individual people on the team have the courage to stand up for their project.

What do you do when the boss demands that you and your team meet an impossible goal? What if he demands that they meet a two-week deadline for a project that can’t possibly be done in less than two months? Effective Scrum teams have the courage to stand up and say “no” to impossible goals because they have the planning tools to show what is possible, and users and stakeholders who trust them to deliver the most valuable software that they can.

Every team member is focused on the Sprint Goal, and everything they do in the Sprint helps move them toward it. During the Sprint, everyone works only on Sprint tasks, and does one task at a time until the Sprint is done.

During a Scrum Sprint, every single person on a Scrum team is focused exclusively on items in the Sprint Backlog and tasks that they decomposed them into during the planning meeting. Each person works on one item in the Sprint Backlog at a time, focuses exclusively on one task in the plan, and moves on to the next task only when the current one is done.

People on Scrum teams know that focusing on one task at a time is more effective than trying to multitask.

There’s a myth that switching back and forth between multiple tasks many times a day is more effective than concentrating on one at a time. Think about it this way: let’s say you have two tasks that will each take one week. If you try to multitask and do them at the same time, the best you’ll do is deliver them both at the end of two weeks. But if you don’t start the second task until the first one is done, you’ll finish the first task a week earlier.

There’s one more Scrum value. Flip the page...

Every person on the team is committed to delivering the most valuable product that they can—and the rest of the company is committed, too.

When the team is committed to the project, it means that the tasks that they planned out to meet the Sprint Goal are the most important tasks they have to work on. Each team member feels that his or her personal success at the company is tied to the success of the project. Not only that, but every single person on the team then feels committed to each item in the Increment, not just the items that they’re working on. This is called collective commitment.

But what happens if something comes up that’s important to the company, but not part of the project? For Scrum to be effective, the boss needs to keep that from happening. In other words, the company needs to be fully committed to the project, to respecting the team’s collective commitment to the Sprint Goal, and to following the rules of Scrum.

So how does a company express that kind of commitment?

By giving the team the authority to determine what features are going to be developed during each Sprint, and trusting that’s how the team will deliver the most valuable software possible. The company does that by assigning a full-time Product Owner to the team with the authority (and willingness!) to decide what features will be built and accept them as done.

Collective commitment means that every team member feels committed to delivering the complete Increment, and not just the items he or she is working on.

Story Time

Once upon a time there lived a pig and a chicken who were the very best of friends.

One day the chicken said to the pig, “I have a great idea. Let’s open a restaurant together!”

The pig said, “That is a great idea! What should we call it?”

The chicken replied, “How about Bacon ‘n Eggs?”

The pig thought about it for a minute. Then he said, “You know what? Never mind. You’re just involved, but I’m committed.”

there are no Dumb Questions

Q: Uh... why are you talking about farm animals?

A: Because the fable of the pig and the chicken is a good way to understand commitment (because the chicken just lays eggs, but the pig has to let himself get eaten—a much greater commitment). In fact, some teams even use these terms in practice this way, calling people who are committed to the project “pigs,” and those who have an interest but not a true commitment “chickens.” (Occasionally, they’ll even call themselves pigs in cultures where “pig” is used as an insult!)

The Scrum value of commitment means that when you’re on a Scrum team, you genuinely believe that your professional success or failure rests on your ability to deliver valuable software, and that makes you a committed “pig.” Your users and stakeholders may have a big interest in the project getting done, which makes them “chickens”—they’re very important to the project, but they don’t feel the same sense of strong personal commitment as “pigs” do.

Q: What if the team doesn’t really “get” some of the Scrum values?

A: An important part of the Scrum Master’s job is to help everyone on the team to understand the Scrum values, and to eventually internalize them so that each person has the right mindset for Scrum. Very few teams start out Scrum genuinely believing in all of these values at first. They grow and evolve together over time. The Scrum Master helps by using the Scrum values to help the team understand and deal with project obstacles that come up.

Q: What if my team can’t find a Product Owner with enough authority?

A: If the Product Owner doesn’t have the authority to decide what the team will build, or to accept each item in the Sprint Backlog as done, then the company hasn’t given the team the authority to do their jobs, and they haven’t truly committed to the project—or to Scrum. That can be trouble.

A lot of projects fail because the team did a great job building the wrong software. The Product Owner keeps that from happening because his or her full-time job is to work with the rest of the company and understand what the business needs, decide what features will be built, and help the team to understand those features.

If the Product Owner doesn’t have the authority to decide what features the team builds, then the company isn’t really committed to delivering the project with Scrum.

Rick: I... uh...

Alex: Yeah, just what I thought.

Rick: Hey, that’s not fair. I know he’s been working really hard on that feature. It’s just taking a lot longer than any of us thought it would.

Alex: So what are you going to do about it?

Rick: Hey, we’re all on the same team here. And that includes you, Alex. So I think you meant to ask what are we going to do about it?

Alex: OK, fine. Well, since I’m on the team, let me give you an answer. Other teams build contingency and padding into their schedules so they never have to tell a senior manager like me that they’re running late.

Rick: Sure. Yeah. I’ve done that before on other projects I’ve managed. I’d add extra tasks to my schedule to account for things taking a lot longer than we anticipated.

Alex: But you’re not doing that now?

Rick: Well, no. The Scrum rules don’t really give me a way to add contingency, padding, or extra tasks. I don’t really see any way to pad the schedule without breaking the Scrum rules.

Alex: Then maybe there’s something wrong with Scrum.

Question Clinic: The “which-comes-next” question

A task isn’t done until it’s “Done” done

When you’re on a Scrum team, you work on one backlog item or task at a time—that’s what the value of Focus is all about—and you work on it until it’s done. But when, exactly, is it done? Is there still some testing left to do? It’s easy to think that you’re done... except for this one teeny little thing. That’s why Scrum teams have a definition of “Done” for every item or feature that they add to the backlog. Before an item can go into the Sprint Backlog, everyone on the team needs to understand and agree about exactly what it means for it to be not just done, but “Done” done. And since every item in the backlog has a definition of “Done,” the entire Increment has a definition of “Done” and the team is committed to delivering a “Done” Increment at the end of the Sprint.

Scrum teams adapt to changes throughout the Sprint

Project teams have to make decisions every day: Which features will we build in this Sprint? What order will we build them in? How will users interact with this feature? What technical approach will we take? Traditional waterfall teams have one answer: all of the planning is done at the beginning of the project. The problem is that at the time the plan is being built, most of those questions don’t have answers yet. So the project manager works with the team to make assumptions, and relies on a change control process to change the plan when they guessed incorrectly.

Scrum teams reject the idea that every project question can be answered at the beginning of the project, or even at the beginning of a Sprint. Instead, they make decisions based on real information as soon as it’s discovered. They do this using the three pillars of Scrum: a cycle of transparency, inspection, and adaptation:

• The cycle starts with transparency, where the team decides together what items to include in the Sprint, and what it means for each of them to be done. All work done by everyone is visible to the team all the time.

• The whole team meets every day in the Daily Scrum to inspect each item that’s being worked on.

• If they discover changes, they adapt to them (like adding or removing items from the Sprint Backlog when roadblocks happen).

• The next day the cycle begins again, with team members giving complete transparency into what they’re doing at the Daily Scrum. This cycle continues every day until the timebox expires and the Sprint is complete.

• The team also inspects and adapts at the other Scrum events—Sprint Planning, the Sprint Review, and the Sprint Retrospective—by reviewing and modifying the Sprint Goal, items, tasks, and the way they work.

there are no Dumb Questions

Q: This is starting to sound really theoretical. Can you tie it back to the real world?

A: Sure. “Transparency” just means that every single person understands all of the features they’re building in the Sprint, and are open about the work they’re doing, what they plan to do next, and what problems they’ve run into. “Inspection” means that they constantly make sure that knowledge is up to date using the Scrum events (especially the Daily Scrum). And “adaptation” means that they’re constantly finding ways to change what they plan to do next based on this new information.

Q: If the team plans some of the tasks but not all of them, won’t that just cause chaos later on in the project?

A: No. Making all of the decisions at the beginning of the project lets you feel like everything’s under control. But very often they aren’t, leaving you surprised that somehow your project—which seemed fine yesterday—is suddenly late, and now everyone’s in crunch mode. That’s why so many teams turn to agile: because their traditionally planned projects keep blowing their schedules, and something needs to change. Scrum avoids those pitfalls by recognizing that many important decisions depend on information that won’t be known until partway through the project.

Q: Can you give me an example of how that would work in real life?

A: Here’s one that our Cows Gone Wild team might face. Brian needs to program the behavior for a new tractor vehicle for the player to use, but he can’t start until Amy finishes the basic behavior for it. If Rick used traditional project management, he would either have to assume that Amy will finish first (and add padding to the schedule in case she takes too long), or he’d have Brian work on something else first, even if the other task is less important.

Now that they’re using Scrum, the team can give themselves more options. They know Brian can’t start the coding for the tractor until Amy finishes designing its behavior. But they also know they’ll constantly inspect their progress and adapt the plan along the way. So instead of deciding today whether Brian work on the tractor or on a less important task, they can add both of them to the Sprint Backlog—and they’ll put off the decision until Brian is ready to start the code. If Amy is done with her work, he can start coding. If she’s not, he’ll pull the other task off of the Sprint Backlog and come back to the tractor coding when he’s done (but only when he’s “Done” done!).

No—because agile teams make decisions as late as possible.

When a lot of people learn about Scrum, they’re surprised that the Sprint Planning session is timeboxed to four hours for a two-week Sprint (sized proportionally for different Sprint lengths), because they’re accustomed to having every single task in the project completely planned out before any of the work can begin. But we’ve already seen that teams following a traditional waterfall process often have trouble when their plans change partway through the project. In fact, changes that would deliver more value often get rejected during the change control process simply because replanning a months-long schedule is too much work.

Scrum teams rarely (if ever!) run into this problem because they don’t plan every single task at the very beginning of the project. In fact, usually they don’t even plan out all of the tasks at the beginning of the Sprint. Instead of planning everything up front, they make decisions at the last responsible moment. What that means is that they only need to do the planning that’s absolutely necessary to get started with the Sprint. If more planning needs to be done, it can be done later in the Sprint.

That’s right. And it all works because of transparency.

Each team member answers the questions every day, so everyone has current, accurate information about the project. Not to get too theoretical, but this is actually a really good example of empirical process control theory, which tells us that when a process (in this case, an agile approach) is based on empiricism, it lets the team optimize the way they work to reduce risk and give them sustainable, predictable results.

The Agile Manifesto helps you really “get” Scrum

We learned back in Chapter 2 that the most effective way to approach any agile methodology, framework, method, or approach—like Scrum, for instance—is with a mindset that’s driven by the values and principles of the Agile Manifesto. Let’s take a closer look at three of those principles that are especially helpful for Scrum teams.

The Product Owner makes sure the team delivers value

That’s the whole reason that the team needs a Product Owner with the authority to accept items in the Sprint Backlog as Done—or, if they’re not “Done” done, refuse to accept them. If everyone on the Cows Gone Wild 5 team really “gets” this principle, then they won’t be mad at Alex for not accepting this feature as done yet, because they genuinely want to deliver the most value that they can. They want to deliver it early and continuously, and the best way to do that is to finish the current item (which means it’s “Done” and ready to demo to the users in the Sprint Review) so that they can move on to the next one and get as many backlog items done in the Sprint as they can.

Self-organizing means deciding as a team what to work on next

If you’ve worked on a traditional waterfall team with a project manager, then you’ve probably worked on tasks that were part of a project plan created by a project manager and assigned to you by either the project manager or your boss. But that’s not how Scrum teams work. Scrum teams are self-organizing, which is a new way to work for a lot of people.

The whole Scrum team works together to plan the project. There isn’t a single person building a plan and telling them what to do. The Development Team members decide what will be delivered, adding new work to the Sprint Backlog as needed. The whole team decides together how they’ll meet those goals.

But self-organization doesn’t just happen during Sprint Planning. They constantly adapt their plan by checking in with each other at the Daily Scrum: each person tells the whole team what they’re planning on doing next to meet the goals they decided on during Sprint Planning. If a teammate sees a problem with the approach, they’ll work together that day to fix it.

Note

The Daily Scrum is timeboxed, so when two team members discover an issue like this, they’ll meet afterward to work it out (inviting other team members to join if they have input). Brian and Amy will meet and talk about how to handle this situation. Once they’ve got a new plan, they’ll review it at the next Daily Scrum to make sure everyone is on board, and to see if anyone has anything to add.

What did you get for your answer in “ Sharpen your pencil”? Flip the page to find out ours...

Making decisions at the last responsible moment probably sounds really weird if you’ve never done it before. But to someone who genuinely welcomes changing requirements, it really does feel as normal as riding a bike.

Scrum teams make decisions at the last responsible moment. They only make project decisions that need to be made now, and leave the rest for later.

This is a new way of thinking about planning for a lot of teams.

That’s part of the mindset shift that we talked about in the last chapter. Here’s how it works on a Scrum project in the real world:

• There’s just enough written down about each item in the Product Backlog to be able to start Sprint Planning.

• During Sprint Planning, the team decomposes enough of the Sprint Backlog to get everyone started, but they don’t feel like they need to decompose everything. (Have a look at the Sprint Planning section in the Scrum Guide, which says the team decomposes work planned for the first days of the Sprint by the end of the meeting.)

• Self-organizing teams don’t need to decide the exact order of every single task in painstaking detail when they’re planning a Sprint. They trust themselves to make good decisions when the time comes.

• As the team works through the Sprint Backlog over the course of the Sprint, they discover new tasks and changes and bring them up in the Daily Scrum, and they use that information to work together to create a plan for the next 24 hours.

• They’re constantly inspecting and adapting, so they trust themselves to make good decisions in the future.

there are no Dumb Questions

Q: Is the Cows Gone Wild team’s story realistic? Can you really use Scrum for something like a video game, which requires a lot of creativity and on-the-fly—and sometimes last-minute—changes with heavy deadline pressure?

A: Not only can Scrum be used for a complex and dynamic project that constantly changes, it’s actually better suited to an environment like that than a traditional waterfall process. Scrum teams constantly look for changes and find ways to adapt to them, which makes them much better at dealing with complexity and even chaos. And the timeboxed nature of Sprints helps the team meet their deadlines. Alex just showed us a good example of the kind of decision that video game teams make in real life. The team built a feature but it turned out not to be fun enough in its current form, so they shelved it for now and might revisit it to sell later as downloadable content. Scrum gave the team the flexibility to handle this on the fly, while a traditional waterfall team would probably have to go through a lengthy change control process. More importantly, a Scrum team sees this change as a victory because they’ll welcome any change that delivers more value to the product. A traditional waterfall team is likely to see it as a defeat because it “wasted” effort and required a change to the plan.

Q: Does “self-organizing team” mean that there’s no boss?

A: Of course there’s a boss. If you work in a company and you’re not the CEO, then you have a boss. But an effective self-organizing team typically has a manager who doesn’t micromanage, and who trusts all of his or her employees to deliver the most valuable software they can. Self-organizing teams are given the authority to decide which features to include in the software, usually by having a Product Owner assigned to the team who’s senior enough to make those decisions. They’re given the freedom to plan the work so that they can build those features in the way they feel is most effective. And they’re given the flexibility to make decisions at the last responsible moment, because that’s the most effective time to make important project decisions.

Q: What exactly happens during the Sprint Retrospective?

A: The Sprint Retrospective is how the team inspects the Sprint that just ended and tries to find ways that they can improve. They look at all sorts of things: the people on the team can improve the processes and tools that they use to do the job, find ways to improve the quality of the software they’re building, work on their relationships with others in the organization, and do anything else that might have an impact on the work—especially anything that can make their work more enjoyable or effective. By the time the Sprint Retrospective ends, the team has put together a plan for improvement. This plan typically consists of a small number of discrete and specific tasks that individual people on the team will carry out. Before the meeting, the Scrum Master helps everyone understand how it works, and makes sure that they all respect the timebox. This happens before the meeting because the Scrum Master and Product Owner have to participate in the retrospective as team members, offering their own opinions and ideas.

Q: Hold on—the Product Owner goes to the retrospective too? Does the Product Owner really need to be at all of the Scrum events?

A: Absolutely. The Product Owner is a real member of the team, and participates in the Scrum events just like everyone else. In fact, on a lot of Scrum teams the Product Owner does his or her share of the development work. But even in that case, that person still has the authority to make decisions about what items will go into the backlog and how to maximize the value of what the team delivers, and the company still respects his or her decisions.

Q: I’m having trouble finding anyone who has the clout to be the Product Owner but also has enough time to attend all of the Scrum events. Can the Product Owner be a committee instead?

A: Absolutely not. The Product Owner definitely must be a person. That person must have the authority to make the decisions about what goes into the software and what doesn’t, and the Product Owner role must be his or her top priority.

Modifying Scrum like this almost always renders it much less effective, usually by removing the parts that make its empirical process control work. Teams often try to “customize” Scrum by bending or breaking any rules that highlight a serious flaw in the way their team is structured. In this case, Scrum makes it really obvious that the team doesn’t have the authority to decide what features go into the software. It’s scary for a manager to say, “The team should build this feature, but not that one.” The wrong decision will cost the company a lot of money, and there will be a lot of blame if it goes wrong. That’s why Scrum requires the team to have a Product Owner who has the authority to make that call.

Teams often try to “customize” Scrum when they don’t have a true Product Owner who can make tough decisions about what to build.

Things are looking good for the team

Cows Gone Wild 5 is this year’s most anticipated video game release! Now they just have to get it out the door. (Easier said than done?)

Answers in “ Scrumcross”

Exam Questions

1. The Scrum Master is responsible for all of the following except:

   1. Helping the team understand what goes on during the Daily Scrum

   2. Giving the Product Owner guidance in effectively managing the Product Backlog

   3. Helping the team understand customer requirements

   4. Giving the rest of the organization guidance on understanding Scrum and working with the team

2. Which of the following is NOT an attribute of a Product Backlog item?

   1. Status

   2. Value

   3. Estimate

   4. Order

3. Juliette is a Product Owner on a Scrum project in a healthcare organization. She was called into a meeting with a steering committee made up of her company’s senior managers because she decided to include a planned health privacy feature in the most recent Sprint. At the meeting, the senior managers told her in the future that she must consult with the whole committee before making business decisions like that.

   Which of the following BEST describes Juliette’s role?

   1. She is in a servant-leadership role

   2. She is not committed to the project

   3. She needs to concentrate on focus and courage

   4. She does not have the authority to adequately fill her Product Owner role

4. When is the Increment considered done?

   1. When the timebox expires

   2. When every item to be delivered meets its definition of “Done” and the Product Owner accepts it

   3. When the team holds the Sprint Review and demonstrates it to the users and stakeholders

   4. When the team holds the Sprint Retrospective

5. Which of the following is an example of collective commitment?

   1. Everyone on the team feels personally responsible for delivering the entire Increment, not just their individual parts of it

   2. Everyone on the team always stays late and often works weekends

   3. Everyone on the team is responsible for delivering an important part of the project

   4. Everyone on the team participates in the Sprint Planning and retrospective meetings

6. Which of the following is NOT a Scrum event?

   1. Sprint Review

   2. Product Backlog

   3. Retrospective

   4. Daily Scrum

7. Amina is a Scrum Master on a team that is working on adopting Scrum. She wants to make a change to help her team get better at self-organizing. Which of the following is the best area to focus their improvement effort?

   1. Daily Scrum

   2. Sprint Planning

   3. Sprint Retrospective

   4. Product Backlog

8. When is a Scrum Sprint over?

   1. When the team finishes the work

   2. When the team completes the Sprint Retrospective

   3. When the timebox expires

   4. When the team completes the Sprint Review

9. Each person on the team answers all of the following questions during the Daily Scrum except:

   1. What roadblocks are in my way?

   2. What planned work did I fail to accomplish?

   3. What will I do between now and the next Daily Scrum to meet the Sprint Goal?

   4. What have I done since the last Daily Scrum?

10. Barry is a developer at an online retailer. His project manager told him the deadline for the current feature that he’s working on is three weeks from now, even though Barry made it clear that he would need four weeks, and there were no specific deadlines or external pressures that require it to be done earlier than that. Barry’s team is starting to adopt Scrum. Which of the Scrum values will make the team’s Scrum adoption difficult or less effective?

    1. Openness

    2. Respect

    3. Courage

    4. Focus

11. Sandeep is a product owner on a Scrum team working on a telecommunications project. The business users let him know about a major regulatory change in one of his regular meetings with them. Handling this regulatory change is now a very high priority for the team, and will need to be the main objective of the next Sprint.

    Which of the following is used to describe the main objective of the next Sprint?

    1. The Increment

    2. The Sprint Backlog

    3. The Sprint Goal

    4. The Sprint plan

12. What aspect of empirical process control theory involves frequently examining the different Scrum artifacts and making sure the team is still on track to meet the current goal?

    1. Examination

    2. Adaptation

    3. Transparency

    4. Inspection

13. What is an Increment in Scrum?

    1. The items from the Sprint Backlog that the team actually completes during the Sprint

    2. The items from the Product Backlog that the team plans to complete during the Sprint

    3. The result of decomposing the Sprint Backlog items

    4. A statement that describes the objective of the Sprint

14. Which of the following helps Scrum teams focus?

    1. Multitasking

    2. Holding a Daily Scrum

    3. Writing a Sprint Goal

    4. Holding a retrospective

15. Danielle is a Product Owner on a Scrum team. She’s talking to one of her business users, who gives her a new requirement. Which of the following should Danielle do next?

    1. Update the Product Backlog

    2. Hold a Sprint Planning session

    3. Update the Sprint Backlog

    4. Bring up the new requirement at the next Daily Scrum

16. Which of the following BEST describes how the team determines what specific work will be needed to complete Sprint Backlog items?

    1. The Product Owner works with the business users to determine which items go into the Product Backlog

    2. The team decomposes Sprint Backlog items into tasks

    3. The team chooses which Product Backlog items to include in the Sprint Backlog

    4. The team decides on each Sprint Backlog item’s definition of “Done”

17. Which of the following does NOT take place during a Sprint Review?

    1. The Product Backlog is updated to reflect what will probably be in the next Sprint

    2. The team collaborates with business users on what they will work on next

    3. The working software the team built during the Sprint is demonstrated

    4. The team looks back at the Sprint and creates a plan to improve

Exam Answers

1. Answer: C

   It’s the Product Owner’s job to help the team understand customer requirements, not the Scrum Master’s. The other three answers are good examples of the Scrum Master’s servant leadership role.

2. Answer: A

   The Product Backlog does not contain any information about the status of a task. This makes sense—none of the items on in the Product Backlog are currently being worked on, so they all have the same status of not having been started yet.

   Note

   Take a minute and read through the description of the Product Backlog in the Scrum Guide. It says that Product Backlog items have the attributes of a description, order, estimate, and value.

3. Answer: D

   One of the most common problems that Scrum teams run into is that the person in the Product Owner role does not have the authority to decide on behalf of the company what features the team will build during the Sprint, or accept them as done on behalf of the company.

4. Answer: B

   The Increment is done when every item to be delivered by the team meets its definition of “Done” and the Product Owner accepts it. Every item in the Sprint Backlog has a definition of “Done” that the team uses to determine when it’s ready to release to the users. The Product Owner can only accept an item on behalf of the company if it meets its definition of “Done”—any item that isn’t “Done” done when the timebox expires must be pushed to the next Sprint.

5. Answer: A

   Collective commitment means that everyone on the team feels a personal sense of responsibility to deliver not just the piece that he or she is working on, but to do what it takes to help the team deliver the whole Increment at each Sprint.

   Note

   Just because everyone on a team works long hours, that doesn’t mean they feel a genuine commitment to it. In fact, they might resent the project and the organization for interfering with their lives, and only work the extra hours out of pressure to keep their jobs.

6. Answer: B

   The Product Backlog is a Scrum artifact, not an event.

7. Answer: A

   Self-organizing teams take responsibility for their own planning to meet their objectives, assign work themselves (rather than depending on a single manager or project manager to make those assignments), and fix problems with the plan as they come up. Of all of the practlices listed as answers, the Daily Scrum is the only one that impacts the way the team plans their work and executes that plan.

   Note

   One reason the Daily Scrum is so important is that it’s part of the transparency-inspection-adaptation cycle. The team inspects the plan every day, and adjusts it as they uncover new information about the project.

8. Answer: C

   The Sprint is over when the timebox expires. The same is true of any timeboxed event. Answer D seems correct because the Sprint Retrospective is typically the last thing that the team does during the Sprint. But if the timebox expires before the team has a chance to hold their retrospective, the Sprint still ends. (And that’s a good opportunity for the Scrum Master to help them understand how to plan better next time.)

   Note

   The Product Owner is allowed to cancel the Sprint before the timebox is over. But this can waste a lot of the team’s energy, and cause people in the company to lose trust in the team, so it should be extremely rare.

9. Answer: B

   The purpose of the Daily Scrum questions is to give everyone a good idea of how each person on the team is progressing, so they can help identify problems with the current plan that need to be fixed. But none of the questions are about failures—that could create a negative and possibly embarrassing environment, and detract from the environment of openness.

10. Answer: B

    The project manager is having trouble with the Scrum value of respect. Barry gave an honest assessment of the work that needed to be done, but the project manager ignored it and demanded a shorter deadline even though there was no business need to apply the extra pressure. That’s disrespectful.

    Note

    It’s also extremely demotivating!

11. Answer: C

    When the team holds their Sprint Planning meeting at the start of the Sprint, the first thing they do is to decide on the Sprint Goal, a brief description of the objective of the Sprint that will be met by completing backlog items.

12. Answer: D

    The core of empirical process control theory—the theoretical underpinning for Scrum—is the “three pillars” cycle of transparency, inspection, and adaptation. In the inspection step, the Scrum team members frequently examine the Scrum artifacts, as well as their current progress toward the Sprint Goal. They try to detect any differences between where they are versus where they expected to be, so that they can take action (which is what adaptation is all about).

13. Answer: A

    The Increment is what the team actually delivered during the Sprint. The items that the team intended to complete at the beginning of the Sprint often don’t exactly match up with the work they actually did. That’s a good thing—it means the team used the information they learned along the way to change direction. The Increment is the product of what actually happened, and the team doesn’t know exactly what the current Sprint’s Increment will contain until they’ve delivered it.

    Note

    We learned earlier that Scrum takes an incremental approach. It’s the delivery of successive Increments that makes it incremental.

14. Answer: B

    The Sprint Goal helps the team focus on the specific objective that they planned on accomplishing during the Sprint.

    Note

    Retrospectives and Daily Scrums can be very useful, but holding meetings is not typically a tool that teams use to help focus.

15. Answer: A

    The Product Backlog is the single source for product requirements, and it’s maintained by the Product Owner. When the Product Owner discovers a new requirement, she adds it to the Product Backlog.

16. Answer: B

    Scrum teams determine what work will be done during the Sprint to complete Sprint Backlog items by decomposing them into tasks. The other answers are also things that the team does during Sprint Planning, but it’s not how the team determines what work they’re going to do.

17. Answer: D

    During the Sprint Review, the team meets with the business users and customers to review what they’ve done and collaborate on what the next Sprint will accomplish. They’ll review the Increment, which typically involves demonstrating the working software that they built. They’ll also discuss the backlog and update it to show the items that they’ll probably work on in the next Sprint. The Sprint Review isn’t for looking back at what happened and making improvements—that’s what the Sprint Retrospective is for.