Monday, October 28, 2013

Potentially Shippable

“At the end of every sprint, a game must be “potentially shippable”

Agile pundits use the phrase “potentially shippable” a lot, but don’t always agree on what it means.  
To me, it depends on the deployment cycle of the game we’re making.  Some games are deployed every sprint and “potentially shippable” for such games means they are ready to ship.  That’s easy!
Other games don’t release every sprint, perhaps releasing once every few years.  Requiring these games to be fully shippable every sprint is unfeasible for a few reasons:
  •  Games often have large minimally marketable feature sets (content and features) that take months to prepare.  Think of a sports title, with all the stadiums, teams and game features.  An NFL game with only six stadiums that only had running plays implemented wouldn’t sell very well!
  • First-party approval processes take weeks to pass.  Sony, Microsoft nor Apple would enjoy running your game through their testing group every few weeks.
  • Major features take more than one sprint to achieve a marketable quality.  Try shipping an FPS with two weeks of effort spent on online multiplayer!

This difference between potentially shippable and shippable leads to multiple definitions of done, each of which is a checklist of activities that developers need to perform every sprint.  These activities might include ensuring that the game runs at an acceptable frame rate, it doesn’t crash and the code has a high level of quality, etc.  The goal is to reduce the debt of unfinished work throughout development to a predictable level.  The reason is that debt (bug fixing, polishing, optimizing) grows with interest over time and can derail the best of plans.  For example, if your game has to stream levels off a disc in 40 seconds or less, wouldn’t it be best to test this before you’ve created all your levels?  Have you ever been on a team that discovered they had to chop half the textures out of their levels a month before they were supposed to ship?  I have, and it wasn’t fun!  Having such a test as part of a definition of done is a good idea.
My next blog entry will cover the definition of done and how it guides the creation of potentially shippable builds and evolves as the team’s development practices mature.

No comments: