Reference: Clinton Keith, Agile Game Development with Scrum, Chapter 4.

Basic rules of sprints:

• They are timeboxed, usually between two to four weeks in length;
• The team commits to completing a sprint goal;
• No additions or changes are made by anyone outside the team.

At the start of a sprint, teams meet with the stakeholders of the project to plan the next sprint. Planning a sprint requires two meetings: the sprint prioritization meeting and the sprint planning meeting.

The goal of the sprint prioritization meeting is to review the high-priority items on the product backlog and to select a potential sprint goal. The team needs to understand each PBI. This is the team's opportunity to raise any design questions. The team selects the top PBIs from the product backlog they think they might accomplish given the current composition of the team. Reasons for skipping PBI's: lack of qualified personnel in the team and dependencies on implementation of PBI's by other teams.

During the sprint planning meeting, after identifying potential product backlog items for the sprint, the team breaks down the tasks from each PBI, one at a time, to build the sprint backlog. The participants in this meeting include the entire team (including the ScrumMaster and product owner) and any domain expert who may be needed to answer questions or help the team estimate their work better. The ScrumMaster helps the team identify constraints that might impact the team's ability to commit to the sprint goal. The team then discusses design and implementation details for every PBI that is potentially part of the sprint goal. The team starts creating a sprint backlog by taking the highest-priority PBI from the product backlog and breaking it into tasks.

Sprints typically last two to four weeks, but many factors need to be taken into account:

• The frequency of customer feedback and change;
• The experience level of the team;
• The time overhead for planning and reviews;
• The ability to plan the entire sprint;
• The intensity of the team over the sprint.

Teams new to game development, agile, or 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. Experienced teams will design, code, create assets, test, and debug every day. Working this way creates better results and enables the team to iterate more during the sprint and increase the value of their work.

During a sprint, the team needs to share information about their progress and identify any impediments to their sprint goal. The team needs to have the proper information to make the best decisions. They need easy access to the sprint backlog of tasks. They need to understand where they stand in terms of achieving their goals. They need to recognize as early as possible when they won't achieve their goal.

• Task cards (3x5 index cards) are used to record and mark up tasks;
• Burndown charts (number of estimated man-hours vs number of sprint days) are used by the team to gauge how well their efforts are leading to achieving their goal by the end of the sprint;
• Daily sprint backlog trend projects the sprint completion by projecting the latest trend into the remaining days of the sprint (useful if a combination with the ideal trend);
• A task board displays a prioritized list of PBI's (the goal for each sprint), tasks for a sprint, and a burndown chart.

Each day, teams gather for the 15-minute timeboxed meeting to:

• 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 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 accepts or declines 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.

• Advantages of single-team reviews:
• Fosters high-bandwidth communication between the customer and the team;
• Enables more hands-on time for the stakeholders.
• Disadvantages of single-team reviews:
• Does not allow other people on the project to see the team reviews;
• Inhibits cross-team collaboration;
• Time-consuming for the stakeholders.
• Advantages of multi-team reviews:
• The entire project staff is able to see the progress of the entire game;
• Encourages cross-team integration and improved build practices by showing a single build;
• The time overhead for the stakeholders is minimized.
• Disadvantages of multi-team reviews:
• Teams may need more time to prepare;
• Diminished one-on-one customer-to-developer communication.

The retrospective meeting occurs after the sprint review to apply the "inspect and adapt" principle to the way how team members work together and apply Scrum. 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 following three questions are raised at the meeting:

• What things should we stop doing?
• What should we start doing?
• What is working well that we should continue to do?

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 that goal by the end of the sprint. When a sprint is reset, all of the incomplete PBIs are returned to the product backlog. Code and assets in development are regressed, and the team and stakeholders return to sprint planning. This is very costly and should not happen often.

Teams may fail for two main reasons:

• Sprint goal change that cannot be completed before the end of the current sprint;
• Running out of time due to poor sprint planning. Can be resolved by:
• Working overtime;
• Removing lower-priority PBI's from the sprint backlog;
• Sprint reset.

Hitler at a sprint review video