How often do you reach an alpha milestone on schedule only to have post-alpha work bite you? Extended crunch, cut features and assets result in burn-out and a game’s quality damaged by last-minute compromises to get it out-the-door. The culprit is usually “debt”. Debt is that extra work which takes a feature from "works on my PC" to a feature that a player who buys the game could use. Like financial debt, development debt has an interest rate; the longer you hold onto the debt, the more expensive it becomes to eliminate. It's also not just technical debt. Art and design debt exists as well.
What does “done” mean at your studio? When I ask this question onsite, I often hear some anecdotes and definitions such as:
• “It compiles on my machine.”
• “I’ll know it when I see it.”
• “It’s 90% complete”
• “It’s coded” (or “it compiles”).
• “It's done, but it needs final assets.”
• “It’s first pass” (out of an undetermined number of passes)
Usually there is no agreed-upon definition. This is a big warning sign on the road to death-march-ville.
One of the initial challenges in adopting agile is defining a more frequent and universal definition of done (DoD). As with all agile practices, it’s emergent; Teams inspect and adapt the game and their work and continually improve the DoD.
For Scrum every sprint must meet this definition of done before being accepted as done by the product owner. For Kanban, a work item cannot be pulled into the next stage until it meets the definition of done in it's current stage. For example, a rigged model cannot be pulled into animation unless all the naming conventions for the skeleton are met.
A DoD is derived from a set of non-functional requirements. These are attributes of the game that apply universally to all work , such as:
• The game runs at a smooth, playable frame-rate
• The game runs on all target platforms
• The game streams off disc cleanly
• The game meets all Facebook API standards
• The code meets the coding standards of the studio
• The assets are appropriately named and fit within budgets
• All asset changes must be “hot-loadable” into the running game
• …and so on
Non-functional requirements are never done.
Any feature added or tuned can impact frame-rate, so by the end of a sprint we must ensure that any work added does not slow frame-rate below a minimum standard. If it does, it's not considered done.
Multiple Definitions of Done
Because potentially shippable doesn’t always mean shippable, there often needs to be more than one DoD, I’ve seen teams create up four DoDs, which cover anything from “prototype done” to “demo-able done” to “shippable done”. These identify the quality and content stages that large features, which take longer than one sprint to be viable (called epics), must go through. Keep in mind, that these definitions shouldn't allow the team to "waterfall" the work. Even if you have a set of cubes flying around for targets, before animating creatures are ready, those cubes can't crash the game or impact frame-rate too much. If cubes are killing your frame-rate, you have more important things to address before adding animating creatures!
The best implementations of DoDs start small and grow (that can be said of a lot of good practices). Start by identifying a few of your larger areas of debt in a retrospective and pick some low hanging fruit DoDs. For example, if basic stability is an issue, a definition such as "the game can't crash while using the feature" is a good starting place. Don't be surprised if this definition impacts how much the team can commit to every sprint: quality costs...but that cost will be recouped with interest over time as practices are improved.
What Post-Alpha looks like with a Good Definition of Done
When we started using agile, I’d hoped we could do away with the alpha and beta stages of game development. In practice, for major initial release of a game, we still needed time after feature-complete to balance the game. What we did lose were the death marches and compromises.