Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 31, 2014
arrowPress Releases
October 31, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Sprint Retrospectives
by Trevor Hilz on 11/08/12 05:29:00 pm   Featured Blogs

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.

 

Sprint Retrospectives

Projects that use Agile with Scrum use sprints to promise features to their product owner (customer/manager); sprints usually take place over a 30 day period. At the end of a sprint, teams conduct sprint retrospectives. These meetings discuss what was delivered from the team during the sprint, what processes were effective or ineffective (or could be improved upon), as well as actions to take place during the next sprint. In essence, they are small postmortems during development.

Features Delivered:

This section is simply a list of features the team completed during the sprint that the product owner receives. It is important to note that these are not tasks, but features. In Agile with Scrum, the features are found in the Product Backlog (List of the game’s features).

  • Examples might include:
    • All main character sound effects
    • Level 1 Whitebox
    • Jump Component

What Processes Were Effective:

This section lists the processes team members found effective during the sprint and would like to see in future sprints. Additionally, a vote is taken to see how many members of the team feel that way about that process.

  • Examples might include:
    • Communication processes were effective – 4 votes
    • Daily backups to external hard drives – 5 votes
    • Daily scrum to gain knowledge of group progress – 4 votes

What Processes Had Negative Effects (Or could be improved):

This section allows members to voice what processes they felt impeded progress due to inefficiencies, or need improvement to be made effective. Team members vote to see how many people in the team feel the same way.

  • Examples might include:
    • Playing music out lout is distracting to the work environment– 4 votes
    • Uploads to source control need to be more frequent – 5 votes
    • Bug reporting needs to be maintained by all members – 4 votes

Sprint retrospectives provide a way for team members to reflect on the past sprint and analyze what they liked and disliked during the sprint. I have seen many great things come out of these meetings and future sprints have truly improved based on members voicing their concerns to the team. I believe sprint retrospectives should be applied to all game developments. Even if the team isn’t using Agile with Scrum, a postmortem at every milestone still provides useful insight.


Related Jobs

Forio
Forio — San Francisco, California, United States
[10.31.14]

Project Manager / Producer (Games)
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.30.14]

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[10.30.14]

Multiplayer Level Designer - Treyarch
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States
[10.29.14]

Producer






Comments


Will Buck
profile image
Nice summary on Agile/Scrum/Retros Trevor!

It might be worth pointing out, though, that sprints don't really have a 'usual' time frame, they really differ from workplace to workplace. I've seen them primarily as 2-week increments, for example, but have seen them as short as one week or as long as four depending on the business / product / etc. Be flexible with your process and find what best suits your team's needs!

Greg Quinn
profile image
Agree with Will.
We usually work in 2-week sprints. Although there is no rule of thumb, our team over a few years determined that this was the most effective.
Many companies also state that a sprint should never start on a Monday and end on a Friday, yet we found this worked better for us too.

But the bottom line is.. do what works for your team.. and agile/scrum methodology is so great because of it's adaptibility.

Trevor Hilz
profile image
Thanks very much for the comments and praise!

You're absolutely correct about the time frame of sprints. The most I have heard is 30 day intervals, with many organizations using two week sprints as the norm. Scrum is really a fantastic process to use in development since it is so adaptable and caters to what the team needs. Interesting approach on never starting on a Monday, I haven't heard of that, but it sounds like a way to break up the monotony that typical organizations use.

Elizabeth Stringer
profile image
Nice summary.

Clinton Keith
profile image
Trevor,

Nice writeup! I like the team voting approach that you use.

Some comments:
- The "Features" section is usually part of the separate "Sprint Review", where the Product Owner, stakeholders and everyone else who wants to see the progress of the game attends. This is usually a much larger audience than you need, or want, in a retrospective.
- I usually coach teams to use a shorter sprint than 30 days. The reason is that 30 day sprints are often hard for a team to plan & commit to, but if it's working for you....ignore the advice! ;)
- Mixing up your retrospective meeting formats is essential. Over time the same approach tends to get stale. I highly recommend this book:
http://tinyurl.com/a7gr6et

Again, nice writeup!
Clint


none
 
Comment: