Agile Development is a well known production methodology for software development. It has been used for around two decades to give structure and organisation to the iterative development process. It has many benefits, but is difficult to successfully apply, especially to a small games studio such as The Voxel Agents. The major difficulty we’ve faced while using the Scrum methodology is the ability to write effective stories.
Scrum provides many rules about what an effective story can contain, but scrum is also about personalising the process to suit your own development requirements. Over the past year, we’ve gradually improved the way we write stories so that what we are writing is appropriate for us. I’ll describe our rules for story creation here.
What is a story?
A “story” is a small chunk of development that brings benefit to the user. For example, “As a player I want helpful hints to appear in the early levels to help me understand the rules“.
This short story tells me quite a lot about what the required outcome is. It tells me who the feature benefits (“as a player“), it tells me what the benefit is (“I want helpful hints to appear in the early levels“), and it tells me why that benefit is important (“to help me understand the rules“). I know that simple debug text isn’t suitable in this situation because that only benefits me, the developer, and not the player. I know that the ability to view the “helpful hints” should occur while playing a level, and I know that the helpful hints should be relevant to the rules that the player is learning.
This story does not tell me how to make this feature. It does not say “Place some red text in the bottom left corner that says ‘Slide a block to interact with the game’ “. It simply describes the required outcome which leaves the implementation of the feature up to the developers – who are, after all, the experts at making this game (one would hope).
Now that have our story which describes a specific benefit to a specific person for a specific reason, we now need to communicate to the team what the minimum requirements of this story are. The minimum requirements are known as “acceptance tests”. They are a list of criteria that must be met for the story to be considered complete. An example of an acceptance test is “when the player is playing an early tutorial level, a legible message that explains the rules to the player must be displayed“. Another could be “the hints must be set on a level-specific basis“.
Ideal acceptance tests are more specific than the general story, but they still don’t tell me to use a specific implementation. Acceptance tests assume that I am smart enough to determine the best implementation in the given situation.
What the acceptance tests should do is constrain the possible outcomes to what is desired by whoever requested the story. For example, it is clear from these acceptance tests that it would be unacceptable to show a randomly selected message during the loading screen. These acceptance tests make it clear that the hint should be relevant to the level that the user is playing and should be displayed while the user is playing the level.
Acceptance tests are important because they describe what the done state of the story is. A story is done when, and only when, all of the acceptance tests have been met. If I do anything more than what the acceptance tests require, then I’m probably just gold-plating this feature and I should instead request a new feature rather than adding functionality that is not yet necessary.
Acceptance tests and Stories are quite standard in scrum. One of the innovations we’ve added to improve the process for ourselves is to write a “Spirit” for each story. The spirit is kind of like an acceptance test but it isn’t binding. A story’s spirit is used to add colour to the acceptance test and to suggest possible implementations that better illustrate the desired outcome.
An example spirit is: “We want to show a helpful hint at the start of each tutorial level that explicitly explains the rule being taught in that level to the player. This will assist the player to understand what they are learning and hopefully speed up the learning curve. For example, we want to show some text at the bottom of each screen that prompts the player to do an action such as ‘don’t be afraid to use undo’“.
This spirit has suggested an implementation to me, the developer. The suggested implementation is what the requester of the story had in mind when they wrote the story. I don’t have to use this implementation, but it helps me to understand the intention so that if I think of a better way of doing it, I can be sure that it still fits the original requirements.
We invented the spirit because we quickly noticed that when we wrote stories we had a misleadingly clear idea of what we wanted. We’d write terrible stories like “At the end of a level show a heap of particles to make the player feel good!”, but then after implementing that feature we realised, for example, that it made levels take too long to finish up so another way of making the player feel good was required. Writing the spirit of each story down allows us to give a quite specific example of what is desired, but still gives us sufficient flexibility to iterate on an idea further during development.
Level Of Done
In typical scrum, each story is brought to a potentially releasable state. Ideally, at the end of each sprint, a release candidate is produced that is just that little bit more feature packed than the last release candidate. This is great for typical software development (release early, release often), but doesn’t necessarily work for games development.
Quite often, we only want to test an idea out in the cheapest way possible. We don’t care if there are red blocks on the screen or if there is debug text all over the place, we just want to see how an idea plays without needing to polish off the edges to make it nice and neat for the players. For this reason, we often don’t want our increments to be release worthy. If we’re just prototyping, it would be a complete waste of resources to make it good enough for a player.
To get around this problem, we specify a Level Of Done for each story. The level of done lets us know how much effort to put into polishing up the feature.
For example, if we’re just making a rough prototype of a half-baked idea, we describe the level of done as “first working“. First working means that it doesn’t matter really matter if it crashes a lot, or if you need to hold down the shift key for some weird reason, we just want to see it up and running as fast as possible. It also means that we don’t want it taken any further than that until another story has been made. This prevents a small prototype from being gold-plated before we know if we actually want it. Therefore if a story requests a “first working” prototype and the developer delivers something beautiful that is ready for the App Store, then that developer has done the wrong thing and loses brownie points.
If we want to take an idea a bit further and see how it plays with the rest of the game, we would say it has to reach “prototype” state. The difference between prototype and first working is fairly subjective, but generally speaking a prototype should be good enough for us to put in front of other people for play testing (i.e. no crashes, no arbitrary keys or insider knowledge). A prototype is not release worthy though. Again this Level Of Done means we only want so much effort put into a story, and any additional effort is potentially a waste of resources.
On the other hand, if we really do want a feature to be good enough for users, we say that it must be “releasable“. Releasable means that we’d be happy selling this bit of functionality. It doesn’t imply that the game is ready to release since other features might not have reached a releasable state yet, but it does mean that if the whole game was of a similar level of quality, then the game is ready. Releasable is a very high standard for us, so we use it sparingly.