User stories: How to maintain structure with creativity

As a product manager making a game, you are tasked with balancing many opposing goals. Time, cost, quality, fun, lifetime value, appeal, and retention are the obvious ones that come to mind, but there’s a lot more that go into the final process. Finding the right balance between all these variables is crucial, and becomes the focus of nearly every decision you make. This is a difficult task for you and your team, and is made even more difficult by the fact that the balance you’re looking for is often situational, varying from game to game and company to company. I have a number of “tools” to help find this middle ground, but above all, I've found user stories to be the most valuable in achieving balance.

“User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.”

- http://www.mountaingoatsoftware.com/agile/user-stories

“A true user story is a metaphor for the work being done.  It is not a highly documented requirement but rather a reminder to collaborate about the topic of the user story”

- http://www.scrumalliance.org/community/articles/2010/april/new-to-user-stories

I suppose we should replace “system” with “gameplay” to make this more applicable to our needs. 

User stories are often associated with agile development methodologies like Scrum, but no matter what methodology you use, describing your goals in terms of how they affect your target user is a great way to achieve direction for both your team and your game.  

The prime alternative to user stories is breaking your game development into tasks. While tasks can be derived from user stories, they rigidly confine and constrict your goals. This may be useful for engineering a defined structure like a bridge, but can actually be detrimental to a project as nebulous as a game.

Let’s take a look at some ways that user stories can improve the design and development process for a game: Alignment The first benefit is better alignment for your team, even as things change. Most, if not all, features of your game will be the result of collaboration between many people. These individuals will often be of different experience levels and different disciplines, so user stories can more easily describe your goal in a way that's agnostic to any particular member of the team. This is in contrast to tasks, which tend to be more useful to your team members’ focus, but not the overall result you’re trying to achieve. The vagueness of a user story is also an advantage because it prompts discussion early on in the process. If you encourage the completion of one user story before moving on to the next, you will also derive two benefits: dark matter management and follow through. Dark Matter With traditional tasking, you’ll often find that the integration of individual work happens very late in the process. This leads to padding schedules to make room for all of the things you didn't spot when you laid out your tasks to begin with: aka dark matter tasks. Measuring and optimizing your pace as a metric of your team’s output (i.e. how many user stories can they complete in a given period), rather than individual pace, gives you a more accurate measure of your overall schedule. Follow through Very much connected with dark matter, follow through is the commitment to finish what you started, strongly. In professional cycling, riders learn to pedal their hardest for a point that is slightly over the crest of a hill. Those few yards before the crest is the point where most riders ease up, but that extra push to finish what you started will pay dividends on the next downhill. Tasks make it very easy to say you are done when you aren't, segmented and specialized as they are. Encapsulating the entire process, it’s much harder to fool yourself into thinking you’ve finished a user story when you haven’t. Empowerment I know, management speak, but we employ many talented, passionate game makers who do their best work when they are engaged and committed to what they are doing. This engagement comes from making big things happen with creative problem solving, not following directions. Tasking leaves a team with directions to follow, and management with the responsibility of dictating those steps. User stories keep the whole team focused on the result you want, and allow everyone to determine the best way to achieve it. Agility Even if you use a traditional waterfall approach, your goals will (understandably) change as more information becomes available. Tasks can be easily disrupted by unforeseen circumstances from above, within or outside of your team. Therefore, finishing something before moving on allows you to lump changes in small batches without fear of abandoning an unfinished project. Of course you may still throw work away, but you will be throwing it away based on a finished solution and a complete view of it's value. What not to do The last benefit depends on how you create your user stories. My preferred method is start with a single story that describes the game as a whole, then break that into 3 or 4 pillars. These pillars can be broken down into a number of epics and the epics can be broken again into meaty, but still bite-sized, user stories.

Each layer of this pyramid can align with the layers of your organization: from senior managers, through leads, to individuals. At each layer, the more senior person takes on the what and can delegate the how to the person or persons below him. This structure gets everyone thinking about and solving problems in the same way. In turn, this also allows each team member to consider the big picture and their own upward mobility, as well as the scalability of the organization as a whole. You’ll also (hopefully) find that your team is generating great ideas throughout the entirety of the project, and user stories allow you to incorporate these ideas much more easily into your work. In contrast to task-based schedules, unflinchingly rigid as they are, user stories leave the team plenty of agency with regards to their objectives. The trick with user stories then becomes choosing which ones to follow, and which to leave behind. This decision is made easier if you have your user story hierarchy, because you can rule out anything that can’t be easily integrated into the structure. This management style of course has drawbacks, mainly the risk of losing precise control. I’ve worked on my fair share of games tried very hard to make task-based management work, but more often than not, games end up as the sum of their parts. Focusing on the end result grants your team much more freedom, and can be hugely beneficial as long as your approach is thorough and each step is solvable. In my opinion, user stories accomplish this better than following a rigorous series of tasks. The way I see it, describing games as tasks is a little like describing a painting by the color of the paint, it just doesn’t quite cut it. - Jason Woodward Executive Producer, Kiwi, Inc.