Well, not really, but I have been thinking about this approach for awhile and observing it in action. This post describes a variation on how some agile game teams have changed their approach to planning and executing sprints.
A video game usually has several core mechanics that we want to develop in depth. For example, a platformer might have movement/control, environmental challenges/enemies and power-ups/rewards.
Given this, we can start by building three branches of the product backlog:
These are core mechanics. They are core because we have to ship with all three and they are core to the player experience. Outside the game industry, this might be called the minimum viable feature set. This is different.
Mechanic Driven Development (MDD) focuses on delivering a narrow set of features each sprint, which are dynamically linked to move a mechanic's playability forward.
For example, let's say we have three team each centered around a core mechanic. The movement/control team might break down their core mechanic even further:
Now we have running, jumping and offensive moves, each broken down further. In what order does the team develop these items?
In mechanic driven development, the question for the team becomes, "what can we do over the next iteration to move this mechanic forward?". In other words, "what's the most important work we can do for the movement/control to make the game more playable"?
To me, running and jumping would seem to be the most important. Other people might feel differently. We'll talk about it as a team (including the product owner). This conversation builds vision, creates consensus and drives developer engagement. The resultant sprint goal contains progress of some or all of the sub-mechanics derived from that discussion.
When a team does this, the result is a sprint that is measured by the progress of the mechanics rather than a collection of stories completed, etc.
What benefits does MDD bring over more traditional approaches?
- It engages the team in discussing the game's mechanics as a target every sprint, not just the completion of a set of stories.
- It creates opportunities for more creative input from the team. A ton of small user stories from the backlog often suppresses creativity.
- It keeps the product backlog very simple
- It makes the sprint goal very meaningful (again, instead of just a collection of stories)
- It drastically limits design debt
MDD is a direct application of the "working software over comprehensive documentation" value in agile. It'll often result in a direct path to playability and an elimination of excessive work called out in a detailed plan written in a design document. This approach can also be used with a detailed design document. We just prioritize the work and sprint deliverables that grow the mechanic and reflect the emerging game against the plan.
Give it a try!