Search

Wednesday, October 30, 2013

Defining Done


At the end of every sprint, a team must deliver a potentially shippable game that achieves a “definition of done”.

What does “done” mean at your studio?  When I ask this question in courses, we often share 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”).
  • “You can see it in the game.”
  • “It’s first pass” (out of an undetermined number of passes)

There are all sorts of unique “cubicle level” definitions that each developer or group defines and one or two “project level” definitions that are honored occasionally over the course of a project (usually following lots of crunching and hacking).
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.

Non-functional Requirements
A DoD is derived from a set of  non-functional requirements.  These are attributes of the game that are not unique features, 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

Some of these requirements start out as user stories.   If the game is running at 10 frames-per-second, we’ll want to do some work to get it there and then ensure it stays as part of a DoD.  An example of that story might be:  
  “As a player, I want the game to run at 30 frames-per-second, so it doesn’t suck” 
This is a good early story to introduce (IMO, any game that runs at 15 fps sucks).

Creating a Definition of Done
Non-functional requirements aren’t a definition of done, since they are not a specific checklist of things for the team to do.  A DoD for the story above might start out with someone playing the game and telling the team if there are any lags.  Later, the team might automate this testing so that the game plays itself (all levels and missions) overnight, logging the time for every frame and pass/failing against a metric such as “the game must run at 33 milliseconds or better for 90% of the frames”.
While it might be tempting to create a massive DoD when a team starts using Scrum, it’s counter-productive because it’ll end up being ignored or gamed.  It’s best if teams build up the definition over time as they hold retrospectives and improve their practices.

Multiple Definitions of Done
Because potentially shippable doesn’t always mean shippable, there needs to be more than one DoD, including “done done”, which translates to “shippable” or “releasable”.  I’ve seen teams come up with four or more DoDs, which cover anything from “prototype done” to “demo-able done” to “done 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.
I’m OK with one extra “done done” definition, but beyond that I prefer teams to use acceptance criteria for the progress of epics.


I’ll write about these acceptance criteria soon.  For now, I’m done with done.

No comments: