Testing at this stage still tends to be manual, but is more likely to be based on a written test case or a quick discussion during the morning stand-up meeting (see below). When a task is 'Done' it usually means that the task is complete, tested, and the resulting implementation has been included in a working build of the game.

Teams at Large Animal recognize that there is room to improve the level of rigor with which quality is built into their games, and adopting a more disciplined approach to test driven development and integrating other XP techniques is one of their future goals. The sprint board shows how work during a sprint is tracked, but does not describe how the team works together to actually complete that work.

Teams at Large Animal typically use the following meetings to structure the collaboration and development that happens during the course of a sprint (the sprint preparation meeting and the mid-sprint meeting vary somewhat from team to team but are included here to give a complete picture of the types of interactions that take place during the sprint):

• Sprint preparation meeting. Held a day before sprint planning. The preparation meeting is a time set aside for the team to get familiar with stories that have been added to the product backlog during the previous sprint and to assign story point estimates to those stories (via planning poker).
  
  Once new stories have been estimated and before the planning meeting for the next sprint, the product owner will prioritize the new stories on the product backlog board. Not all teams use this meeting. Some teams combine the sprint preparation meeting with the sprint retrospective meeting.

• Sprint planning meeting. Held on the first day of a sprint. The team identifies which stories from the product backlog it will commit to completing over the course of the new sprint during the sprint planning meeting. For each story that the team pulls off of the product backlog into the new sprint, the team breaks the story down into tasks that are each given more specific time estimates (in hours).
  
  The time estimates on story tasks help the team ensure that they are not over committing. Teams can easily add up the estimated number of hours needed to complete all tasks during the sprint and compare that number to the number of hours available in the sprint.

• Stand-up meeting. A 15 to 20 minute discussion held daily at 9:35AM during which the team updates their progress and ensures that all team members are in synch at least once a day. For most teams, updates to the sprint board are reserved for the stand-up meeting. Moving cards on the board only during the stand-up meeting ensures that everyone on the team is explicitly aware of each move.
  
  Completion of the sprint backlog is the collective commitment of the entire team and the stand-up meeting allows each team member to have a clear picture of whether or not they are on track to fulfill that commitment. In addition to the sprint board, a burn down chart is also an effective tool teams use to visually illustrate their progress through the sprint (see Henrik Kniberg's Scrum and XP from the Trenches for more information on burn down charts).

• Mid-sprint meeting. Held halfway through the sprint. The purpose of the mid-sprint meeting is to serve as an explicit checkpoint to ensure that the team is on track to completing their commitment. The team also uses the mid-sprint meeting to review the implementation of user stories with the product owner (the publisher or other customer representative). If any issues are identified, the team has an opportunity to make adjustments before the end of the sprint. Not all teams use this meeting, particularly not teams using short (one week) sprints.

• Sprint review meeting. Held at the end of the sprint. The review meeting is an opportunity for the team to show the publisher/customer a working build of the game that includes implementation of the new user stories.
  
  The teams at Large Animal place great importance on the sprint review as an opportunity to validate and challenge the direction in which the game is developing. The sprint review is structured as a formal presentation of the latest build of the game. In addition to the publisher/customer, everyone from the company is invited to attend the review and provide feedback.

• Sprint retrospective meeting. Held at the end of the sprint. The retrospective (a.k.a. the postmortem) is a time for the team to reflect on what worked well during the recently completed sprint and what could be improved. The intention being that the team takes what it learns from every sprint and applies it towards improving the way they work together and improving the way that future sprints are executed.
  
  Many of the process innovations developed at Large Animal originally came from ideas generated in retrospective meetings. Some teams combine the sprint retrospective meeting with the sprint preparation meeting.