Sprint 2 Retrospective: Proof of Concept Gameplay

Last week marked the Proof of Concept Gameplay milestone for Team Game Project (TGP1) teams here at Guildhall.  These each teams consist of four or five student developers from the Guildhall’s newest class of students, Cohort 19.  I serve as Associate Producer for two of these teams, and lead them through their Sprint Retrospective after each sprint.

For projects this small, each sprint retrospective looks back at about one week of work for the teams.  This is far more frequent than development in a professional environment, of course, but serves as a useful learning tool and puts us in the habit of using good practices.  So far, I found these frequent, scheduled half hours or reflection have already allowed the teams a chance to question and address pieces of the process that are and aren’t (yet) working for them, from significant to mundane.  For example, one team addressed a growing appreciation for the visibility scrum offers, and another brought up a lack of whiteboard space.  More than anything else, the retrospective is an opportunity to discuss the project development and find ourselves all back on the same page. As a producer, it’s a chance to hear out problems.  In the easiest circumstances, they’re whiteboard-sized problems that can be rolled out of storage and into the team’s room.

The Sprint Retrospective consists of:

1)      A quick overview of the sprint, its place in the project, and the goals of the sprint

2)      A review of the playtest hours, and number of bugs logged and resolved

3)      A review of the processes that the team felt were effective and ineffective

4)      A list of action items for the team to implement immediately.  Typically these address the ineffective processes mentioned earlier.

5)      A review of the estimated and actual effort required to complete the sprint, and their variances

At the Guildhall, the Sprint Retrospective takes place on each milestone day.  I sit down with my teams and go over each topic over the course of a half-hour meeting.  We address action items as immediately as possible, and I formalize the meeting into a Sprint Retrospective report later that day.  These reports are useful to look back at each milestone to see if the issues have been adequately handled. 

At the Austin GDC Online this year, I attended an “Agile: Are We There Yet?” roundtable where the importance of the Sprint Retrospective came up.   I regret that I don’t recall the producer who emphasized it, but her point was that she liked seeing the new problems addressed in a retrospective, and saw them as signs of progress.  Repeats of old problems mean we aren’t hitting issues as they arise.