Sponsored By

Guildhall Producer Series, Part 2: The Sprint Retrospective Process

The second of four blog posts in the Guildhall Producer Series discusses sprint retrospectives and their role in helping three small teams plan for future sprints.

Benjamin Roye, Blogger

November 12, 2012

12 Min Read

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 GameTeenage 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.


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.

Salvage Runner Logo

Salvage Runner Logo

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.

Proof of Concept Gameplay Kleenex Report
Salvage Runner
Assistant Producer: Ben Roye
Level Designer: Marc S.
Level Designer: Hakan B.
Artist: Nathan M.
Programmer: Trevin L.


E. Clune

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

  1. 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

  2. Tester never used barrel rolls

  3. Tester felt that the mines were not aggressive enough

  4. 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)

  5. 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



5 secs

Tester doesn’t understand controls

26 secs


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

Salvage Runner Concept Art courtesy of Nathan M.

Salvage Runner Concept Art courtesy of Nathan M.

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.

Retrospective Report
Sprint 2 - Proof of Concept Gameplay
10/29/2012 - 11/2/2012

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

  • POCG asteroids level whiteboxed and tested

  • Placeholder HUD containing shield, juggernaut directional arrow, and player’s score

  • Placeholder controls screen for kleenex tester

  • 7 bug fixes

3. Release Quality Statistics
Below are some statistics from the prior two sprints:


# Playtest Hours

# Defects Found/Fixed

Sprint 1 – Proof of Concept Technology



Sprint 2 – Proof of Concept Gameplay






4. Process Review
4.1 Processes That Were Most Effective for the Sprint

# of Votes

Things Done Well


Scrum boards helped the team keep organized and on track for milestone completion.


The team feels glad that they are learning scrum processes now so that they can be more effective in later TGPs.


The team is excellent at making decisions effectively and expediently.


The team likes that core hours are productive.

4.2 Processes That Had a Negative Effect on the Sprint

# of Votes

Need Improvement


The team feels that scrum boards feel like micro-management for a team of four developers.


The team feels that locks are hard to stick to and poorly defined.


The team felt that adding new milestone requirements in mid-sprint impeded their work.


The team feels that administrative assignments such as documents get in the way of development.

5. Action Items
Below are the action items we will immediately put into place to improve our next sprint:

Action Items

Add player feedback for every aspect of the game. This includes moving the HUD onto the ship itself so that the player does not have to avert his or her eyes from the gameplay.

Get rid of the juggernaut directional arrow in the HUD because the juggernaut is always behind the player.

Complete level 2 for the vertical slice.

Start working on level 3.

Add warp drive art.

Make the end of the level more apparent with sounds and art.

6. Variances 


Est Hrs

Act Hrs


% Variance

Sprint 1 – Proof of Concept Technology





Sprint 2 – Proof of Concept Gameplay










Read more about:

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like