Daily news, dev blogs, and stories from Game Developer straight to your inbox
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.
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 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.
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.
11/2/2012
E. Clune
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 |
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:
Sprint | # Playtest Hours | # Defects Found/Fixed |
Sprint 1 – Proof of Concept Technology | 4 | 5/5 |
Sprint 2 – Proof of Concept Gameplay | 4 | 7/7 |
Total | 8 | 12/12 |
4. Process Review
4.1 Processes That Were Most Effective for the Sprint
# of Votes | Things Done Well |
4 | Scrum boards helped the team keep organized and on track for milestone completion. |
4 | The team feels glad that they are learning scrum processes now so that they can be more effective in later TGPs. |
4 | The team is excellent at making decisions effectively and expediently. |
4 | The team likes that core hours are productive. |
4.2 Processes That Had a Negative Effect on the Sprint
# of Votes | Need Improvement |
4 | The team feels that scrum boards feel like micro-management for a team of four developers. |
4 | The team feels that locks are hard to stick to and poorly defined. |
4 | The team felt that adding new milestone requirements in mid-sprint impeded their work. |
4 | 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
Sprint | Est Hrs | Act Hrs | Variance | % Variance |
Sprint 1 – Proof of Concept Technology | 44.5 | 38 | 6.5 | 117% |
Sprint 2 – Proof of Concept Gameplay | 72.5 | 60 | 12.5 | 121% |
Averages | 117 | 98 | 19 | 119% |
About the Author(s)
You May Also Like
