The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

I am pleased to work currently as a producer for three 2D student-created games at the Guildhall at Southern Methodist University. Each team consists of four underclassmen and I.

Revenge of the Dragon King is a game based on Journey to the West, one of Four Great Classical Novels of Chinese literature. The Dragon Ball manga is also based on the same novel. In Revenge of the Dragon King, players control the Dragon King in a side-scrolling “bullet-hell” game—a game where players must move about the screen in a cautious manner to avoid the bullets of enemies. Raging Sushi: Enter the Roll is a side-scrolling beat-‘em-up in the same vein as The Simpsons Arcade Game, Teenage Mutant Ninja Turtles: Turtles in Time, and ­X-Men arcade game where players move about the game screen in a pseudo-3D manner. Salvage Runner is a game that looks like Galaga in an asteroid field, controls like SkiFree, and plays like a “bullet-hell” game. In Salvage Runner, players try to dodge asteroids and debris while outrunning an oversized antagonist who constantly pursues the player.

The underclassmen are working on their first games at the Guildhall. At the Guildhall, the faculty teaches use of agile development processes such as daily scrum meetings, creating and maintaining scrum boards and product and sprint backlogs, and participating in sprint retrospectives. These three game projects serve as the first time that many of the team members have been exposed to sprint retrospectives. Sprint retrospectives are extremely useful tools because they allow a team to iterate the game, building on the successes and mitigating the risks of the previous sprint.

SPRINT RETROSPECTIVES

For the purposes of demonstrating the sprint retrospective process as we do it at the Guildhall, I will focus on the Salvage Runner team because their development highlights good iterative processes. The retrospective report also demonstrates that some team members are learning processes for the first time and do not yet wholly appreciate the importance of documentation or the healthiness of iterating quickly.

Milestone Day Kleenex Test
At the culmination of every sprint, a free faculty member who has never before seen the game comes to the team's break-out-room and participates in a kleenex test for the game. During this kleenex test, the team cannot talk to the faculty tester. They cannot ask questions when the tester has finished testing the build. The tester gives all feedback that they can think of and then moves on to test another game. Below, I have compiled all of the tester's feedback into a kleenex report.

Overview of Kleenex Tester Reactions and Comments in order of Priority/Severity

Tester never looked at the HUD on the top right of the screen because he was so intently focused on the ship and dodging obstacles

Tester never used barrel rolls

Tester felt that the mines were not aggressive enough

Tester could not gauge well when the indestructible power-up was about to run out. This often hurt him (i.e. he would become vulnerable as he was passing through an asteroid)

Tester thought that while boosting while at the top of the screen, he became stuck

List of Recommendations from Kleenex Tester and Team Action

Tester never looked at the HUD

Resolution: The team changed their design. Now, the HUD displays on the player’s ship

Tester never used barrel rolls

Resolution: The team felt as if this tester just did not prefer to use the ability. The team is not changing anything about the barrel roll mechanically

Tester felt that mines were not aggressive enough

Resolution: The team put mines into the POCG to prove that they had implemented the technology. They plan to improve and polish the mine functionality for Alpha

Tester could not gauge well when the invincibility power-up was about to run out

Resolution: The artist and programmer design and implement a flash animation and mechanic that occurs when the power-up is about to run out

Appendix: Detailed timeline of Kleenex Testers Reactions and Comments while Playing Game

Time:

Description:

5 secs

Tester doesn’t understand controls

26 secs

“Ah!”

35 secs

“Shields are down.”

49 secs

Tester experiences slight lag upon respawn

1 min 15 secs

Tester died for the first time

1 min 23 secs

Tester starting the build over to reread the controls screen

1 min 35 secs

Tester understands the controls now

1 min 49 secs

Tester not sure about barrel roll

2 min

Tester still doing pretty good

2 min 20 secs

Tester is doing really well avoiding obstacles

2 min 37 secs

Tester died again

2 min 38 secs

“No phasers?”

3 min 18 secs

Tester dodging obstacles and having fun

3 min 37 secs

Tester improving

4 min 10 secs

“Only 2 more tries.”

4 min 36 secs

Tester only moving left and right

4 min 50 secs

Tester starting over. He learned he could move up and down

5 min 50 secs

Tester not talking; very into the game

6 min 4 secs

Tester not sure how much further to go. He cannot make it past the final field of asteroids to win the level.

6 min 57 secs

Tester not sure backing up [towards the Juggernaut] is a good idea

7 min 17 secs

Tester has gone past “Last 2 tries.” He is hooked

9 min

Tester not clear as to how much life he has remaining

11 min 12 secs

Tester still focusing hard

11 min 20 secs

Tester mentions he now sees additional health on HUD but would have been more helpful if it was on the ship

11 min 40 secs

“Indestructible is dangerous.”

14 min 30 secs

Tester beat the level

Sprint Retrospective Immediately After the Kleenex Test
After the kleenex test, I lead the team through a sprint retrospective. I facilitate the team in articulating what the kleenex tester said. The most important information gleaned from kleenex tests is often that the tester misunderstood or had no knowledge of a feature. The biggest concern during this test was that the tester hardly ever looked at the Heads Up Display because it was located in the top right corner of the screen. The frenetic gameplay ensured that the tester did not have time to look away from the player ship or else they would collide with an asteroid and die.

1. Introduction
The purpose of the Retrospective Report is to describe in detail the specific activities that were most effective and those that need adjustments prior to the sprint. A goal of the document is to inform future sprint teams of the obstacles encountered during this release. Sprint 2 began on 10/29/2012 and went through 11/2/2012.

2. Release Overview
Sprint 2 was the second and last Proof of Concept sprint before moving to Vertical Slice. It contains:

Voice overs scripts written and outsourced for auditions

Implementation of placeholder music and sound effects

Salvage pickup functionality and placeholder art

Mines enemy functionality and placeholder art

Juggernaut enemy shoots at player

Overshield and temporary invincibility mechanic functionality with no art