Wednesday, March 9, 2016

Leaving story maps behind

I wrote on the first of this year about how I was excited to try using story maps as a management aid for my Spring Studio team, and in the middle of February I followed up with some of my findings from one iteration's use. The team just finished their second iteration, and after talking about it with them during our end-of-iteration review and retrospective meeting, we are going to drop the story maps and go to Scrum.

The problem with the story map—as we reified it—is that it presumes that the reader already has knowledge of the fundamental processes that are required to complete a story. For example, we had an activity on the story map called "Narrate my friend's story" with a story underneath it called "Read conclusion and result." (StoryConclusion, and Result are all key terms from our game design and are defined in a design log.) When I look at that story, I can imagine the steps required to complete it: sketch the UI, make sure I have actual conclusions and results, make sure it fits with the overall game UX flow, rough it in code with placeholder assets, start replacing placeholders with real assets, test the integration. The problem is that I am not the one doing these steps: rather, it is a team of people who never did this before. What happened in the first two iterations with the story map is that they would look at "Read conclusion results" and, in the discussion, I would explain that these steps were required. These steps weren't tracked explicitly, though, and so we ran immediately into cognitive overload, and the team moved forward with the illusion that they knew how to proceed. Note that this is basically the same phenomenon as in a traditional class, where you can tell the class something and they will nod but not take notes, believing that they understand; of course these students then fail to follow the proper steps when it comes time to execute the task independently.

I am hopeful that switching to Scrum will make it easier for the team to track its progress on smaller tasks. It will mean more attention devoted to planning meetings, as we break down stories into individually-measurable tasks. One reason I was hoping for a leaner approach using story maps is that this is only a three credit-hour course, unlike the six credit-hour studios of the past few years, and so this will eat even more time away from production. However, if we're not producing the right thing, then it doesn't matter how quickly we do it.


  1. I always love taking some time at work to read about the new things you're trying with the courses!

    I'm surprised you were looking away from Scrum though to be honest. It's always worked well in the past, and is one of the better methods to use for game development I would think. But I'm sure there's something you know that I don't! Either way, the nostalgia is strong when I read these! : )

    1. There was a half-baked paragraph that I took out of this post, about how I have an article coming out in ACM TOCE that summarizes a lot of what I've been doing with studio learning the past eight years or so. Partially because that provides a "cap" on the experience, I thought it might be time to try something new. Tried it we did, and now back to something more reliable :)

      I may try story maps on my own projects, or when working with teams that have built games before, but I think they won't work well for novices due to leaving too much unsaid.

    2. Hmm! I'm a little too unfamiliar with story maps to really talk about them myself. Either way, I'm sure it's something I should look into! I would love so much to be doing something other than Waterfall at this point though. It's kind of disappointing how work doesn't use a lot of the practices that I learned in school.

      I really hope this year turns out great! I'm sure I'll be watching semi-closely. I really need to come by the campus some time too and see what's happening.