In the previous chapter, we introduced Scrum practices and roles. In this chapter, we’ll go into more detail about Sprints, the iterative cycles of development. We’ll see how they are planned, how they are conducted on a day-to-day basis, and how the team and stakeholders review the progress at the end and reflect on how well they worked together. Finally, we’ll see how Sprints might fail to achieve their full goals and how the teams and stakeholders deal with that.
The Solutions in This Chapter
The solutions we are addressing through proper Sprints are ensuring that:
Developers are part of the planning cycle.
Developers are focusing on the goals of the game, and the studio leadership is focusing on removing any roadblocks to that.
Teams and stakeholders are committed to true transparency of the progress of the game’s progress and emerging value.
The Big Picture
Sprints have the following basic rules:
They are timeboxed, usually between one to three weeks in length.
The team forecasts a Sprint goal they will focus on completing.
The stakeholders commit to do their best not to change the Sprint goal.
Figure 4.1 shows the basic flow of what happens in a Sprint.
At the start of a Sprint, the team and stakeholders establish a Sprint Goal in Sprint Planning. Then the team begins to work on achieving the goal, sharing their progress with one another in the Daily Scrums. At the end of the Sprint, the team demonstrates the improved version of the game to the stakeholders in a Sprint Review. Following the Review, the team conducts a Retrospective, where they discuss how the team worked together during the Sprint and to seek improvements for the coming Sprints.
Meetings by Any Other Name
An initial complaint of Scrum is that it identifies four meetings that have to take place every Sprint. People’s initial reaction to “more meetings” is usually negative, which often has to do with how poorly many meetings are facilitated. Although the Scrum Master should facilitate effective meetings, the Scrum Guide authors attempted to mitigate this initial reaction by renaming “meetings.” Their first attempt was to call them “celebrations,” which fooled no one. Currently, the Scrum Guide refers to them as “events.” In this book, I still call them “meetings.”
At the start of a Sprint, the Development Team meets with the Product Owner to plan the next Sprint. Sprint Planning has two parts: identifying the Sprint Goal and planning how to achieve that goal. The participants in this meeting include the entire Scrum Team (the Development Team, Scrum Master, and Product Owner) and any domain expert who may be needed to answer questions or help the team estimate its work better (such as an online programmer, motion capture technician, and so on).
The Sprint Goal
The Sprint Goal is the coherent objective for the Sprint. It is refined by the Scrum Team during Sprint planning based on an initial forecast or by discussing the highest order of Product Backlog Items (PBIs). As the Sprint progresses, the Development Team will keep its focus on the goal and negotiate the scope of the Sprint Backlog with the Product Owner as needed.
The practices describing how a team estimates, tracks, and manages the Sprint Backlog here are a typical starting pattern for many teams. However, applying the principle of self-organization, teams will explore and improve how to plan and manage their Sprint. We shouldn’t care if a team is using a Ouija-board to plan its Sprint. We should only care about how they improve the game every Sprint.
Part One: Identifying the Sprint Goal
The meeting begins with the Product Owner describing the highest-ordered features on the Product Backlog that the team is capable of implementing. This is an opportunity for the Development Team to raise any design (game design, technical, art, and so on) questions. For example, if a feature requires the main character to jump, there may be some questions about how the current animation and physics technology is applied. This discussion reveals design and high-level implementation questions such as whether a physics-only, animation-only, or blended solution is best.
Sometimes high-ordered PBIs on the Product Backlog are too large for a team to tackle in a single Sprint. These features are split into smaller PBIs that are expected to fit.
The focus of this part is to identify the Sprint Goal for the coming Sprint. The team selects the top PBIs from the Product Backlog it thinks it might accomplish given the current composition of the team. At this point, the Sprint Goal is merely a forecast that will be adjusted in the second part. For example, if a particular feature requires animation, but no animators are on the team, then the team cannot commit to working on that feature unless it finds one to join them.
Another reason to drop a particular PBI from the initial Sprint Goal is because of a dependency from another team. For example, a feature requiring engine work to be completed first should be postponed if the engine team has not addressed it yet. The organization of the Product Backlog and teams reflect the need to avoid such dependencies, but sometimes they do occur. We want to discuss enough PBIs during this meeting that the team has some leeway in which it chooses to work on during the next meeting, all while generally working within Product Owner priorities.
At this point, the team hasn’t committed to any work. It has identified the PBIs it may be able to complete, but until it has broken these PBIs down into a detailed plan to achieve the Sprint Goal—which it does in the planning meeting—it isn’t yet ready to commit.
Part Two: Planning How to Achieve the Sprint Goal
After identifying a potential Sprint Goal, the team creates a plan to implement each PBI, one at a time, creating the Sprint Backlog: the plan to achieve the Sprint Goal.
At the start of the meeting, the Scrum Master helps the Development Team identify constraints that might impact its ability to commit to the Sprint Goal. Here are some examples of these constraints:
Holidays that reduce the amount of time available
Time that will be spent outside of the team (interviews, and so on)
Potential impacts from other areas, such as the integration of a major engine change that has caused problems in the past
The Development Team’s ability to commit to work is based primarily on its past performance. This is best determined by examining what the Development Team has been able to accomplish in past Sprints. For example, if the Development Team was able to finish an average of 400 hours of estimated work in the last few Sprints, then it’s probably a safe bet for it to sign up for 400 hours of estimated work for the coming Sprint. This becomes the limit in the capacity of planned work it can put into the Sprint Backlog during Sprint Planning.
The Development Team then discusses design and implementation details for every PBI that is potentially part of the Sprint Goal. The attendance of the Product Owner is important for this discussion because there are many subjective aspects to what needs to be implemented. For example, the Development Team might want to discuss potential trade-offs on character motion that looks realistic versus motion that is responsive to player input but more jarring in appearance.
The form of the Sprint Backlog is determined by the Development Team. From here out, I’ll describe a typical approach of breaking PBIs into time-estimated tasks, but because the Sprint Backlog is owned by the Development Team, it decides how to make the estimate. Some teams don’t even use estimates (see Chapter 9, “Agile Release Planning”)! If you force teams to plan their Sprint in a particular way, don’t expect them to truly commit to owning the work.
The Development Team then starts breaking the PBIs into work items. Figure 4.2 shows one potential way PBIs are taken from the Product Backlog and employed to build the Sprint Backlog.
The Development Team starts filling a Sprint Backlog by taking the highest-priority PBI from the Sprint Goal and breaking it into work items. Everyone on the Development Team is involved at first because design questions are raised. After the requirements of the feature are agreed upon, the Development Team starts writing individual tasks and estimating the amount of effort each one takes to complete.
The work breakdown takes place within discipline groups. For example, if the Development Team has four programmers, they estimate the programming work together. If only one programmer is on the Development Team, the programmer estimates all the programming tasks alone.
Tasks are often estimated in ideal hours or days, which is the amount of time a task should take without interruption or any problems. This means that an eight-hour task is not the same as a one-day task. An eight-hour task usually takes more than one calendar day to accomplish. The reason is that our days are filled with interruptions, problems, and conversations that vary from day to day.
Ideal time is better to use than actual time. Teams can forecast just as well with ideal time and, as they find improvements in their practices, they can forecast more ideal time in the same timebox.
Estimates for large tasks are less accurate than estimates for small tasks. I can estimate how long a trip to the local store takes to within a few minutes, but a cross-country drive estimate might be off by a day or two. The limit of task size is arbitrary, but a couple of days is a reasonable limit as a size before it needs to be broken down into smaller tasks. Sometimes a Development Team might not have enough information to break down a task larger than a couple of days into smaller tasks. Instead, it will create a placeholder task with a larger estimate until it is ready to work on the task and know more.
After each PBI is broken down into tasks, the total estimated time is added up. This total is then compared with the remaining time available in the Sprint Backlog. If the Sprint Backlog has room for the time the new PBI adds, then the Development Team commits to completing that PBI. Of course, each specialty on the project needs to be within its capacity.
Even though we got 400 hours of combined work done last Sprint, we can’t commit to 400 hours of animations this Sprint if half the Development Team are programmers. Apply common sense. Make sure each discipline (specialty or skill group) is within its capacity, and use the amount of work done during the last Sprint as a guide to what can be completed this Sprint. Part III, “Agile Game Development,” discusses the disciplines in more detail.
If the work for the new PBI would overflow the Sprint Backlog, then the Development Team won’t commit to it. One of three options is available when this happens. First, the PBI is returned to the Product Backlog, and another, smaller PBI takes its place. A second option is to split the original PBI into two or more smaller PBIs. A subset of the original PBI might be identified that fits into the Sprint. As an example, a PBI for creating a level could be broken down into two PBIs, each for one half of the level. A third option is to drop an item already pulled in to enable the new item to fit. The Product Owner can help the Development Team decide which is the best solution.
How to Estimate Your First Sprint
While planning a Sprint, the Development Team considers the amount of work accomplished over previous Sprints to judge the approximate amount of time it uses to estimate its capacity for work in the coming Sprint. A natural question that comes up is, “How do we estimate our capacity for our first Sprint?” I recommend that the Development Team aim for one-third fewer hours/days than it initially estimates. The reason for this is that Development Teams new to Scrum underestimate the effort to create potentially shippable features at first. This includes time for bug fixing and polishing, activities not traditionally included in waterfall task estimates.
If the Development Team runs out of work during the Sprint, it conducts a mini-planning meeting and picks another PBI or two to fit into the remainder of the Sprint. It’ll have a better feel for and be able to more accurately measure the work it can commit to with every successive Sprint.
If the team runs out of work a day or less before the end of the Sprint, it can usually find some tuning, polishing, or refactoring work that needs to be done!
What is the ideal length of a Sprint? Sprints typically last two to three weeks, but many factors influence this:
The frequency of stakeholder feedback and change
The experience level of the Development Team
The overhead time for planning and reviews
The ability to accurately plan the entire Sprint
The intensity of the Development Team over the Sprint
Over the course of a project, these factors will change, and the length of a Sprint may change as well.
The duration of a Sprint depends on the amount of time the stakeholders can go without seeing progress and providing direction on the game. Some core mechanics require frequent feedback in the early stages of development, so a shorter Sprint is required to be sure the game is headed in the right direction. For example, the motion of the character, behavior of the camera, and layout of the controls may require frequent feedback. Some Development Teams don’t need such a rapid cycle of feedback (such as content production teams), so a longer Sprint is more appropriate for them.
The Development Team must not have the goal changed within the Sprint. If three weeks is unbearably long for stakeholders to wait for a review, then it needs a shorter Sprint.
When we first started practicing Scrum, the published wisdom was that one-month Sprints were ideal. After trying and failing at one-month sprints, I asked one of the authors of that advice what we were doing wrong. He told me that we weren’t wrong, but that the original advice was. Apparently he’d chosen that Sprint duration because he didn’t want to fly out to the clients; he was coaching every Sprint more than once a month!
Development Team Experience
Teams new to game development, Agile, or even just working together should start with shorter Sprints. This enables them to iterate on the practices and learn how to develop more iteratively and incrementally. Teams new to Scrum should be discouraged from practicing longer Sprints because they tend to approach a Sprint like a mini-waterfall project (see the top part of Figure 4.3). They’ll spend a couple of days exclusively in design, spend a few weeks creating code and assets, and finally integrate, test, and tune during the last few days of the Sprint and end up crunching to reach the finish line. This doesn’t give them the opportunity to achieve the best possible result because there is little time left to iterate and polish their work.
Experienced Development Teams will perform these activities more in parallel, designing, coding, creating assets, testing, and debugging every day. Working this way creates better results and enables the team to iterate more during the Sprint and increase the quality of their work.
Planning and Review Overhead
Shorter Sprints often require a larger portion of a team’s time for planning and review. Review and planning usually require a good portion of a day regardless of the length of the Sprint. Even though planning for a shorter Sprint may take less time, the remainder of the day following the meeting is never 100 percent effective. Imagine that you had a Sprint that lasted one week. You’d probably spend one day that week in review and planning. That’s 20 percent of the team’s time spent in planning!
Plan to Party
Allow the team to have a little celebration between Sprints, but don’t disrupt the cycle of the Sprint for it. Set a little time aside as part of the Sprint for people to play the game and relax. Besides, game developers don’t need much excuse for a party!
Ability to Plan the Sprint
If the team is uncertain about how to achieve the Sprint Goal or if experimentation or prototypes need to be done, then the Sprint should be shorter. Uncertainty implies that the work eventually required for the Sprint might be significantly different from what was anticipated at the start. If this is the case, it’s better to change direction after two weeks than four.
Some prototype teams have chosen an extremely short Sprint duration of days! I’ve seen web-based games deploy versions of a game twice a week.
Sometimes three weeks is too long for a Sprint because it leads to a low-intensity mini-design phase up front and a high-intensity debug mini-crunch phase at the end. Although the mini-crunch phase isn’t going to kill anyone, it’s not the most efficient way to work.
Choosing a Sprint Duration
On my last team, a one-week Sprint felt too short. It was as though the review was too soon to “do anything too challenging.” A three-week Sprint was too long to create a sense of urgency. We compromised and chose a two-week Sprint because “it felt right.”
When Is the Sprint Too Long?
Stakeholders usually limit a Sprint’s duration to three weeks as the longest amount of time they let pass to direct the goals of the game. Some may argue that some technical areas (such as engine or pipeline development) cannot achieve any significant progress in as little as three weeks. The need for longer Sprints to show value usually indicates that the technical practices need to be more iterative. Any development practice that can’t demonstrate progress at least once every two to three weeks should be addressed. Interim goals should demonstrate a reduction in risk and have value. For example, if a team is implementing the infrastructure for online gameplay, it might demonstrate simple object messaging across a local area network after the first Sprint. The longer a team goes without proving or disproving architectural assumptions, the greater the potential waste.
Who Selects the Sprint Duration and When?
The stakeholders and the Scrum team need to determine the duration of a Sprint. If there is a disagreement, the Product Owner has the final say. The length of the Sprint must be changed only between Sprints, and it shouldn’t be changed too frequently. Frequent changes to the length of Sprints are disruptive. It takes some time for the team to adjust to the rhythm and pace of a particular Sprint length and refine its ability to estimate the appropriate Sprint Backlog.
One of the reasons that the phrase Sprint Commitment is no longer in the Scrum Guide is because it has often been weaponized to force teams to complete everything they had estimated in Sprint Planning regardless of what problems emerge during the Sprint. This has resulted in teams compromising quality to get every feature in the game “done” by the end of the Sprint.
The Sprint Guide now uses the word forecast instead of commitment for Sprints, even though commitment is still a core value. I agree that forecast is an accurate way to express what the plan is, but I think we’ve lost something by dumping the word commitment.
It comes down to what we mean by commitment. Often forecast means “We’ll get done what we get done,” or better yet, “We’ll do our best to get everything done, but we might have to drop some less important features.” To me, commitment goes a step beyond that, but not so far as to mean “We must do everything.”
Commitment means doing our best to achieve a goal, but also being accountable as a team when things don’t go according to plan.
A good example is when you commit to picking up your child at daycare. You’ll obviously do your best to be there on time, but sometimes things go wrong. Let’s say your car breaks down a few miles away from daycare. Do you just say, “Oh well; I tried my best”? No! You call your spouse, friend, and/or the daycare to let them know. You do this because you hold yourself accountable to pick your child up.
Similarly, if teams run into problems with a feature in their Sprint goal, they need to hold themselves accountable. They need to raise the issue. They grab the Product Owner and discuss ways to address it. If they can’t solve the problem themselves, they recruit the Scrum Master to help out. It still might mean the feature gets dropped, but the accountability results in better risk management.
Commitment is a core value for Scrum Masters to grow with a team. Sometimes the first step is to stop solving problems for the team and start asking it, “What should you do about it?”
During a Sprint, the team needs to share information about its progress and identify any threats to its Sprint Goal. The team needs to have the proper information to make the best decisions. It needs easy access to the Sprint Backlog of tasks. It needs to understand where it stands in terms of achieving its goals. It needs to recognize as early as possible when it won’t achieve its goal.
Scrum teams use a number of low-tech practices and artifacts to provide this information to teams. Task cards, burndown charts, task boards, and war rooms have proven their value for tracking progress throughout the Sprint. This section describes these in detail.
The Development Team doesn’t track actual time spent; it tracks the estimated time remaining to accomplish tasks. When first starting Scrum, actual time spent may be double that of the estimated time because the Development Team isn’t used to including debugging and tuning time. This is consistent across all tasks, and so is predictable, but it will improve over time.
Tasks can be recorded and tracked in many ways. The most useful form to store tasks are on 3-by-5 index cards, called task cards. These cards have many advantages that no tool can match. The major benefit is that they enable everyone on the team to participate in task creation and management. The task card enables easy customization using various color cards and markings. For example, a cinematics team decided to categorize the order of asset creation tasks by using stamps with pictures of fruit to help them better prioritize their tasks. The “low-hanging” fruit were picked off the board first. Try doing that as easily with a tool!
Many teams use sticky notes. These work well unless you use cheap off-brand notes or post them in a windy location.
During Sprint Planning, the team commits to accomplishing the Sprint Goal based on the sum of the estimated work expected to complete it. The team updates the estimate of work remaining daily to help track progress toward its goal. The team plots this day-to-day measurement on a graph, called a burndown chart (see Figure 4.4), a tool for the team to use to gauge how well its efforts are leading to achieving its goal by the end of the Sprint.
The Scrum Guide, the definition of Scrum that is maintained by Jeff Sutherland and Ken Schwaber, eliminated Burndown Charts as a standard practice in Scrum a few years back. This was a good decision because the use of any tool or practice used within a Sprint should be decided by the team. It was also good because many managers were “weaponizing” Burndown Charts. I’ve seen managers monitor burn-downs and even reward or punish teams based on “how straight” their burndowns were. Management tracking of a sprint burndown is like measuring how hard a canoeist is paddling. It doesn’t tell you if he or she is headed in the right direction or if the current is pushing the canoeist backwards. That said, I feel that burndowns, when used properly, can be a great benefit to Development Teams.
The Burndown Trend
As described in the planning section, tasks are typically estimated in “ideal” time. An ideal hour/day is an hour/day of work accomplished without interruptions, bugs, tool problems, questions, coffee breaks, friends on the phone, and so on. We’re lucky if we accomplish four ideal hours of work per eight-hour workday with all this competition for our time and attention.
The burndown chart tracks the ideal time remaining to accomplish the Sprint Goal. The rate that ideal time decreases per actual day is called the burndown trend. Measuring this trend is a useful tool for Scrum teams.
The burndown trend is for the team to track its progress toward accomplishing the Sprint Goal. Figure 4.5 shows the burndown chart of a team a little more than halfway through its Sprint. Using this chart, the team, in mid-Sprint, projects its trend (the dotted line) to the end of the Sprint. The trend line is a warning that the team is falling behind and won’t achieve its goal.
The burndown trend is a valuable empirical tool for examining the impact of any change that the team makes to how they work. Teams should see the downward slope of that trend increase over time as they improve how they work.
Some teams will draw an ideal line of progress from estimated time remaining at the start of the Sprint to zero hours on the last day. Figure 4.6 shows this trend line. This shows the team how far it is above the ideal projection of remaining time.
The team needs to understand that the goal isn’t to have its burndown line match the ideal line. The goal is to use the burndown to show progress daily.
We’ll discuss the options available when the team is running out of time later in this chapter.
Burndown Charts are Not New
Long before I learned about Scrum, I encountered the power of burndown charts. When our team entered alpha, the publisher threw a couple dozen testers on the project, and all of us fixed bugs.
Once a week, we triaged the bug database to prioritize the bug “backlog.” We tracked the total bug count and used a “burndown chart” to measure bug resolution velocity, bug discovery velocity, and the projected “zero bugs” date that we were trying to reach. All I had to do was fix bugs and achieve the best possible resolution velocity.
Does this sound familiar? It’s no coincidence that many of the Scrum practices reflect these practices.
Given clear goals, discrete tasks, and an empirical measurement of progress toward a goal, teams achieve a high level of focus and effectiveness.
A task board displays the goal, burndown chart, and tasks for a Sprint. The team gathers around it daily and pulls the work that it needs to accomplish from it. The task board often occupies a section of a wall. Figure 4.7 shows an example task board.
Task cards move from the “not started” column to the “done” column as the work for each card is started and completed. A benefit of this movement, with the addition of the burndown chart on the board, is that the task board provides an immediate view of the progress of the Sprint.
Task boards have at least four columns. The first column contains the ordered list of PBIs that the team has committed to completing (the Sprint Goal). The second column contains all the tasks that have yet to be started. Following Sprint Planning, all the PBIs and tasks are placed in these two columns. The third column contains all the tasks in progress. As team members decide what they will “work on next,” they move the associated task card from the second column to the third column. The last column contains all the tasks that have been completed. Cards are moved into this column when team members finish tasks.
Tasks are usually lined up in rows with their associated PBIs. This enables the team to see the overall progress of work for each feature quickly.
Teams might add columns to task boards to represent additional task states. For example, they could add a “pending” column, between the in-progress and completed columns, for tasks that need external approval before being moved to the “tasks completed” column. For example, tasks to complete models or animations that require aesthetic approval from an art director are placed in a pending column.
Scrum Master Tip: Have the Team Talk to the Board
If the team is quiet when asked the three questions during the daily stand-up, encourage members to talk to the board instead.
The Scrum Master will go to the board and, starting at the highest ordered PBI with unfinished work associated with it (tasks in the “not started” or “in progress” columns) ask the team about what needs to be done to complete that PBI. Remind the team that higher priority PBIs should ideally take precedence over lower priority PBIs.
Some people will speak up more when facing a board than other team members.
The practice focuses the team on finishing PBIs over finishing tasks.
It highlights impediments quickly.
Many Agile teams set aside a small space or room called the war room. The war room is where the team has their Daily Scrums and where the tasks board is displayed. A war room is an austere place. Chairs or other furniture for people to sit on during the Daily Scrum are not allowed. Depending on the wall space, a half dozen teams can share a war room.
Some teams prefer to have the task board in their local team area and have their Daily Scrums there.
The Daily Scrum Meeting
Each day, teams gather for the Daily Scrum. Many teams new to Scrum underestimate the purpose and value of the Daily Scrum. A number of reasons exist for the Daily Scrum:
To synchronize effort among all team members.
To commit to the work to be accomplished in the next day and reaffirm the team’s commitment to the Sprint Goal.
To identify any impediments to be addressed by the team.
To ensure the team members are “on the same page.” The full team needs to hear about the problems facing each member so that solutions can be addressed after the meeting. The Daily Scrum enables them to micro-steer their progress toward their goal together.
A Daily Scrum is a 15-minute timeboxed meeting that every member of the team attends. No one is allowed to sit down in the meeting, which reinforces the idea that this is a quick huddle and not an open-ended laboriously long meeting. Daily Scrums get to the point.
As the team gathers in a circle, each member of the team answers these three questions:
“What have I done since the previous Daily Scrum?” This should relate to anything done for the Sprint Goal or what may have impeded progress (for example, “I spent the entire day trying to get the game to run on my PC!”).
“What am I going to accomplish between now and the next Daily Scrum?” Each team member describes what he or she plans to accomplish by the next Daily Scrum. If there is any work not related to the goal, the team member should mention it (for example, “I need to interview a candidate this afternoon”).
“What are the problems or impediments slowing me down?” Impediments are anything that gets in the way of delivering what was promised during the previous Daily Scrum (for example, “It takes two hours to bake assets for the PlayStation build”).
Scrum Master Tip: Ask a Fourth Question
The three Daily Scrum questions are not fixed and are often modified and supplemented by the team to make the meeting more effective. One example of this is to ask an additional question about the team’s view of the Sprint’s progress.
Sometimes the team can feel a little pessimistic about the Sprint, and this question helps to address any issues as early as possible. One way to do this is to use a Roman vote. Ask the entire team “Are we going to achieve our Sprint Goal?” On the count of three, members either vote thumbs up (if they believe they will achieve it) or thumbs down (if they believe they won’t).
The Daily Scrum is not for solving problems. Keeping all side conversations to a minimum is important so that the meeting doesn’t become protracted and ineffective. Solving problems is part of what occurs throughout the entire day.
The Daily Scrum is probably the most frequently modified Scrum practice, so this definition of the practice is just a starting point. As a team takes more ownership of how it works, it is free to modify the practice as long as the purpose of the meeting (status, commitment, and improvement) remains intact. For example, some teams will answer the questions one member at a time, whereas others will address the progress of each PBI.
If you, as Scrum Master, don’t know whether the team is holding the Daily Scrum for you or its members, disappear a few minutes before it is scheduled. If they hold it without you, it’s serving them. If they ignore it, it might mean they don’t see the value in it.
Improving the Daily Scrum
When visiting a studio, I’ll often ask to observe the Daily Scrums. It’s the best way to sense where a team is and how to focus coaching time for the visit. An effective Daily Scrum is an energetic swarm of engaged Development Team members who need to quickly synchronize their efforts and identify anything that is threatening their shared goal.
Some Daily Scrums aren’t like this. They are monotonous, manager-led, and useless to the Development Team. Teams here lack any sense of commitment or ownership, and they eventually question the merit of the practice and perhaps even abandon it. Unfortunately, abandoning the stand-up doesn’t improve their chances of building commitment or ownership, which are principles of Scrum. I’ve compiled a list of pointers on ways to improve the Daily Scrum and improve commitment and ownership.
The stand-up is for the team. This meeting is for the team to synchronize its efforts towards achieving its goal, not just as a status report. If there are any “management artifacts” that need to be created (such as an update to a tracking tool), it should be done outside the meeting.
The rules aren’t fixed. The “answer the three questions” rule you read about in books is only the starting place. Teams add questions, change the format, and do anything necessary to address their needs.
It’s about the commitment to the goal, not just the tasks. Task tracking is critical, but work will arise on a daily basis that wasn’t considered during Sprint Planning. Teams need to react to this new work and balance it daily against their goal. They need to inform each other about new developments and threats to their goal. They should care about accomplishing the tasks, but they should care about the goal more.
Scrum Masters must know their role. Scrum Masters do not run the Daily Scrum. They facilitate them. The difference is that the rules for the stand-up come from the team and the Scrum Master ensures that those rules are followed. If the team has decided that being late to the stand-up is not acceptable, they’ll likely have a rule in place to humorously chastise those who are late. Paying $1 or singing a song is common. Scrum Masters must not let them off the hook.
It’s a “stand-up” meeting. If you took the same meeting and had everyone sit down, its duration would increase by 50 percent. Standing creates a sense of urgency. Try making another meeting “standing only” and see what happens!
Respect the timebox. Some of the most effective stand-ups I’ve seen were five-minute “hurricanes of energy and activity.” The team members shared what they needed to share and went back to work. Stand-ups that take longer than 15 minutes are just wrong and need to be fixed.
Prefer a physical task board. This is not always possible to have, but there is no electronic replacement that is equivalent. A physical task board with cards allows everyone on the team to handle the tasks simultaneously at the same location. It encourages team ownership.
Avoid projectors. This might seem a bit redundant given the last point, but projectors used in a stand-up meeting should be renamed “engagement killers.” Projectors usually involve a software tool that provides information in a linear, one-at-a-time way with someone, unfortunately often the Scrum Master, at the keyboard/mouse controls. It defeats the non-linear, swarming-on-the-goal, value of the stand-up. Software tools are often a critical part of project planning and tracking, but they have no place in a co-located Daily Scrum.
It’s owned by the team. The team picks the format and time of day of the Daily Scrum. Because the team owns it, it should run the same way, regardless of whether the Scrum Master is there or not. One simple test I recommend to Scrum Masters is to occasionally hide around the time of the Daily Scrum and see what happens. If the team meets and runs the stand-up the same way as when you are there, you are doing a good job. If the team doesn’t meet or stands around wondering what to do, it has some things to fix.
When teams adopt Agile, the Daily Scrum is usually a good practice to start even though they may resist it. However, I’ve noticed that some teams that function well eventually abandon the practice because their communication throughout the day is so effective, they don’t need a separate “ceremony” to communicate.
The Sprint Review occurs on the last day of the Sprint. The Review brings the team and stakeholders together to play the game and discuss the work accomplished. During the Review, the Product Owner officially accepts or rejects the results of the Sprint. If the results for a particular feature are declined, then the Product Owner decides whether it returns to the Product Backlog or is deleted.
The Product Owner is a member of the Scrum Team and should be engaged with the team throughout the Sprint. Although the Product Owner officially accepts or rejects Sprint results at the review, he or she should always know what the team has accomplished before the review. Being surprised there means the Product Owner is not doing his or her job!
Sprint Reviews should be structured to enable the best level of communication between the stakeholders and the teams. This is the opportunity for the stakeholders to inspect the game and communicate with the Scrum Team. If this communication doesn’t occur, the project can go off in directions that won’t return the best results for the stakeholders or players.
Reviews enable a more informal conversation between the team and the stakeholders. They help communicate the progress of the game more directly.
Review Format for Smaller Games
For games with fewer than four to six Scrum teams, Reviews take place with individual teams. The stakeholders visit each team area and review the Sprint results. This creates a casual and comfortable environment for the review.
The meeting starts with a member of the team explaining the Sprint Goal and the overall results. If any of the PBIs were dropped, the reasons are discussed here. Then one or more team members play the game and demonstrate where each goal has been achieved. The controller is often passed to a stakeholder to play.
Team Reviews offer numerous benefits:
It fosters high-bandwidth communication between the stakeholders and the team. Individual team members and stakeholders directly communicate in-depth, which creates an improved vision for the game.
It enables more hands-on time for the stakeholders.
However, small Reviews have some drawbacks:
If other people on the project want to observe the Reviews, it creates a roaming crowd that moves around a studio. This might interfere with some of the benefits previously listed.
It can inhibit cross-team collaboration. Teams might see their work as isolated products, which creates integration issues (among other problems).
Even with smaller games, occasionally having a single review format is useful, as described in Chapter 21.
We always modified Sprint Reviews not only as we learned what worked better, but also as we modified team formations and as teams grew.
One of the biggest challenges for game projects using Scrum is having the publisher’s voice represented in the Sprint Reviews. Many of us have worked on games where the publisher ignores the progress for the first 80 percent of the project and then overwhelms the project with feedback during the last 20 percent, when the opportunities for change are at a minimum. Always include the publisher (if the project has one) to avoid late course corrections.
However, having a representative from a publisher that is thousands of miles distant visit for every Sprint Review is usually impossible. This doesn’t mean publishers cannot provide useful feedback, however. Every effort should be made to have publishers play builds and have their feedback incorporated into the next Sprint. We always demand that the publisher visit at least for Release Planning and Reviews. These are just too critical to ignore. Chapter 17, “Working with Stakeholders,” explores working with remote stakeholders in more detail.
Having publishers present during a Review has a big impact on the project. Have them speak to all Scrum Teams about the progress made. There is nothing like hearing feedback directly from the publisher!
Studio executives and managers need to attend reviews as well. Reviews provide a very concise and transparent view into the progress and challenges of a project.
Agile values and principles emphasize customer collaboration. The ultimate customers for our games are our players. Because our players can number in the millions, we usually can’t invite them to Reviews. With live games, we can use metrics and player forums to measure and hear feedback. Chapter 22, “Live Game Development,” addresses how to incorporate these into the Product Backlog.
It’s critical that stakeholders provide honest feedback to the team. Too often, they see the progress but don’t always insist that Sprints need to deliver vertical slices of functionality. If the team has committed to delivering a character that walks and runs but has a few transition bugs, the stakeholders need to call the team on it. Many stakeholders don’t want to discourage teams by criticizing anything, especially when the team has worked hard and delivered value. However, allowing debt (such as bugs) to accumulate does the team a disservice later by creating further debt. Honesty is the best policy in Reviews.
The Sprint Retrospective is possibly the most important, yet often most neglected practice. The goal of the meeting is to continually improve how the team creates value for the game. This is accomplished in the Retrospective by identifying beneficial practices, stopping detrimental practices, and identifying new practices to be tried in the next Sprint.
The Retrospective is where much of the improvement of development practices occurs. Changes don’t necessarily have to be large ones; a 1- to 2-percent improvement in the effectiveness of the team every Sprint compounds into huge improvements over the long term. Usually an improvement is something small like “Don’t commit anything untested at the end of the day.” That one saved many morning hours!
The Retrospective occurs after the Review. The entire Scrum team attends. It’s facilitated by the Scrum Master and is a timeboxed meeting. The team selects a time limit for the meeting before it starts. Teams will select times from 30 minutes to 3 hours, depending on how much needs to be addressed.
The following three questions are raised at the meeting:
“What things should we stop doing?” The team identifies detrimental practices identified during the last Sprint that it wants to stop.
“What should we start doing?” The team identifies practices that help it improve how members work together.
“What is working well that we should continue to do?” The team identifies the beneficial practices that should be continued. Usually these are changes introduced at recent Retrospectives.
It’s up to the team whether it wants to invite people from outside the team. If a team interacts with people outside the team during the Sprint, then including these people in the Retrospective is valuable.
A lot of discussion should occur during the Retrospective. The Scrum Master should facilitate these discussions to help keep the pace of the meeting within its timebox.
The purpose of the Retrospective is to identify changes in the ways the Scrum team works together, usually in the form of action items. The answers to the questions asked result in action items. These action items aren’t always assigned to individuals during the meeting; it depends on the action item itself. The following are examples of answers to the question “What should we start doing?” and some potential actions that could result:
“Start having QA approve all tasks marked ‘done,’ if possible.” This doesn’t require an action item; it is a working agreement for all of QA to adopt.
“Make sure Joe tests his animations before committing them.” Clearly, Joe has to follow up on his animation testing, but because this has to happen daily, a specific action item isn’t needed.
“Have the build server send an e-mail when the build is broken.” If the team has programmers who can implement this change, then they could implement it themselves. If not, this generates an action item to pass along this request to the team that maintains the build server.
Keeping Retrospectives Fresh
The format of Retrospectives should always be mixed up from time to time. Using the same format leads to them becoming boring and unproductive. The book Agile Retrospectives: Making Good Teams Great (Derby and Larsen, 2006) describes many formats and techniques to use to keep them interesting and productive.
Posting and Tracking Results
Scrum Masters record all the answers given for each question. Following the Retrospective, they post the results of the meeting in the team area and check off all the items on the list that have been fulfilled during the next Sprint. Any items left unchecked from the last Retrospective are discussed at the next Retrospective. These items are either carried forward to the next Sprint or removed from the list based on what the team decides.
Retrospectives help the team become more effective over time. Ignoring this critical practice prevents the benefits of Agile adoption from being realized.
Should the Product Owner Attend the Retrospective?
Some argue that Product Owners shouldn’t attend the Retrospective, that it’s only for the Development Team. I feel that they should be invited. Issues such as improving communication between the Development Team and the stakeholders is something that impacts Team productivity. After all, what’s the use of having a team efficiently create something the stakeholders and players don’t want? It’s important that the discussions in the Retrospective remain focused on improving “how” the team works, not “what” it is working on.
The goal of a Sprint is to advance the value of a game within a fixed amount of time. The team meets with the stakeholders and negotiates to find a goal that it commits to achieve. The team then implements the code, assets, and behaviors. What could be simpler?
Sometimes things don’t work out quite so simply—unforeseen roadblocks slow progress. Stakeholders change their mind. The process has to accommodate the vagaries of life and development.
Scrum handles these problems in a number of ways. Small and large impacts to the Sprint are quickly exposed. The Scrum team addresses these and works with the stakeholders to react to the problems. Sometimes these problems can’t be handled through daily fixes and result in the team’s failing to achieve all or part of the Sprint Goal. This section looks at what the team is able to do when this occurs.
In the fall of 2007, following an unusually warm weekend, we woke up to a different world in San Diego. The southern sky was different; a horizontal column of dark orange sky fell across it like a wall. Blown from the east by a Santa Ana (desert) wind, it could only mean that there was a wildfire out of control again.
A quick check of the news assured me that the fire was distant and no immediate threat to our town, so I decided to head into work. The studio was like a ghost town; many employees had distant commutes, and they decided not to press their luck that day.
Shortly after lunch, our fortunes changed. The main fire had spawned a number of other fires, some of which were a direct threat to the studio and surrounding homes. This happened so suddenly that we found ourselves in an evacuation zone. I faced the imminent threat of being cut off from my family by closed roads, so I raced for the door.
On the way out, I was met by one of our Scrum Masters. Although he was just as determined to escape, he paused to ask, “What do you think this means to Friday’s Sprint review?” I initially thought he was joking, but his expression was one of concern. I had to admire the tenacity of his Scrum Master training. I told him that all bets were off and wished him and his family the best of luck.
Fortunately, none of the studio employees lost their homes (or worse) this time around, and the studio was spared. People trickled back in over the next week, and the Sprints resumed. The studio probably lost close to two weeks of work.
We discussed restarting a new Sprint or finishing the remainder of the Sprint in progress, but we decided to finish. Work picked up smoothly where we had left off, and we had a successful Sprint.
One of the most drastic practices in Scrum is called the Sprint Reset. A Sprint Reset allows the team or the stakeholders to declare that the Sprint Goal needs to change or that the team is unable to complete much of that goal by the end of the Sprint. When a Sprint is reset, all the incomplete PBIs are returned to the Product Backlog, and the team returns to Sprint Planning.
Sprint Resets are costly. Much of the work in progress is potentially lost. Resets should be rare. They must always lead to ways the stakeholders and team improve communication and its ability to plan.
Problems with the Sprint Goal
Although you may not have wildfires and earthquakes, there are a few more common reasons for Sprints to run into trouble. The two main reasons are when the Sprint Goal changes. or the team realizes it will not achieve its Sprint Goal because it has run out of time.
Imagine a team is working on its jump feature when the CEO runs in with an emergency; he’s agreed to demonstrate an online feature in two weeks! This new feature is suddenly more important to him than any other feature. What does the team do?
First, the team does nothing. The Scrum Master must intervene at this point. The first thing that the Scrum Master does is separate the CEO from the team and firmly remind him or her that interrupting a Sprint has great costs. The CEO needs to understand the cost of changing Sprint Goals. Next, the Product Owner is brought into the discussion. The two of them discuss the feature in more detail. The Product Owner then brings in domain experts to discuss the feature, if necessary. For example, if the CEO wants an online feature, an online programmer may be consulted.
If the group decides the online feature should be pursued (or if the CEO is adamant), then a proper PBI encompassing the feature is written. The team best suited to accomplish this feature is gathered to perform a preliminary Sprint Planning session to evaluate the scope of this new feature and whether it could possibly be finished in a two-week Sprint.
If the team determines that the goal cannot be accomplished, then the CEO must be told “no.” Perhaps a smaller portion of the original feature is discussed, but the team must not commit to the work. If the team determines that completing the feature within a new Sprint is possible, then the Sprint is reset, and a new Sprint is fully planned to deliver the online feature within two weeks.
Objection: My CEO Doesn’t Take “No” as an Answer
There is a saying that “A dead Scrum Master is a useless Scrum Master” (Schwaber, 2004). If you are fired for standing up to the CEO because he is not following the “Scrum rules,” you aren’t helping your team. Live to fight the battle another day and to influence stakeholders to do these things less often.
Running Out of Time
Estimating work for even a two-week Sprint isn’t 100 percent certain. Problems can blindside the team; tasks that seemed minimal can balloon into large challenges. Sprint teams sometimes find themselves approaching the end of the Sprint with too much work and not enough time left to accomplish it.
A useful tool in evaluating the progress of a Sprint is the burndown chart. As previously described, the burndown chart is a tool to monitor the work remaining. In some cases (refer to Figure 4.5), the burndown chart shows that the team will not hit zero time by the end of the Sprint. Projecting the burndown trend clearly shows this. The end date of the Sprint is always set and never changes, but sometimes the scope of work isn’t so predictable and expands significantly.
In this situation, the team then has one of three choices:
If the extra work isn’t too great, put in some overtime to make up the difference.
Negotiate with the Product Owner to remove one or more of the lower-priority PBIs in the Goal or remove part of a PBI.
Request a Sprint Reset. Set a new Sprint with more achievable goals.
The team explores the solution to the problem in this order; it committed to the work and should do its reasonable best to accomplish it. If the debt of work remaining exceeds what can be accomplished with a reasonable amount of effort, the team should approach the Product Owner and request that some PBIs be dropped from its list of goals for the Sprint. If the Product Owner agrees to drop some PBIs, they are usually among the lower-priority ones. Dropping individual PBIs may not be possible if they are highly interrelated. In this case, the team and Product Owner should call for a Sprint Reset.
For teams I have been on, we commit to work evenings during the week if we need to catch up, but we avoid any weekend work. After the Sprint we will discuss the reasons for why this extra work was necessary and try to find ways to avoid it in the future. Chapter 16, “The Myths and Challenges of Scrum,” explores overtime and crunch more.
The question is often raised about how much overtime the team should put in before they request that some of the work be dropped. There is no specific answer to this. Teams typically abhor dropping PBIs. They prefer to work some reasonable amount of overtime. Overtime should not be invoked very often. If teams experience overtime every Sprint, they need to reduce the amount of work to which they are committing.
This is a balancing act; as a stakeholder and coach, I expect a team to not deliver all committed PBIs in perhaps one out of every four of their Sprints. If the team never needs to drop something from its Goal, I suspect that the team fears “over-commitment.” If the failure rate is significantly higher, I suspect that the team is not taking its Sprint Goals seriously enough. It’s a fine line, and one of the biggest challenges that Scrum Masters and coaches encounter with teams.
Whatever the cause, when teams need to drop PBIs during a Sprint, the reasons should be discussed in the Retrospective.
Running Out of Work
Occasionally a team accomplishes its goal well before the end of the Sprint. If it’s a day or two away from the end of the Sprint, the team can come up with useful work to fill the time and can usually identify enough housekeeping and polishing tasks. If it runs out of work sooner than that, it can meet with the Product Owner to find a small PBI on the Product Backlog to estimate and complete.
If teams encounter this problem a few times, I encourage them to commit to more work during Sprint Planning.
What Good Looks Like
The challenge of adopting these practices isn’t their complexity. Scrum has been defined as being easy to start but hard to get good at. The hard part is cultural. Culture pushes back on these practices largely because transparency often reveals things we don’t want revealed. But when teams and studios overcome these cultural issues, we see
Teams being trusted to determine their own pace and process within the Sprint and becoming engaged in the work.
Stakeholders increasingly trusting teams to do so and demanding less documentation up front.
Issues being raised as early as possible and risk being communicated and accounted for early, when the cost for resolution is lowest.
True progress is measured, and a game’s plan responds quickly to what the game is telling us, Sprint to Sprint.
Sprints provide the heartbeat of iteration on an Agile game project. They are a contract between the stakeholder and the team to provide value demonstrated within the game rather than promised in a document. However, a game project isn’t made of a series of Sprints that all look the same. We start many projects by iteratively exploring the possibility and end them by creating many assets to provide hours of entertainment. The next part of the book examines practices that help with longer development cycles, called Releases, and how we plan in an Agile way over the entire duration of the project.
Derby, E., and D. Larsen. 2006. Agile Retrospectives: Making Good Teams Great. Raleigh, NC: Pragmatic Bookshelf.