User Stories and Adventure Design

Agile project management (and related ideas like Scrum or Kanban) is something that I deal with a lot on a day to day basis. It's too big a topic to fully explain, but in a nutshell, it's a method of doing work in small, achievable chunks that steadily move towards and end goal (in contrast to planning a big project, then building it). It has strengths and weaknesses, and is very well suited to certain types of software development. It also has a strong ethos of programmers having strong influence on what's being done, so it's unsurprisingly popular among programmers.

One of the cornerstone ideas of Agile is the User Story. A story is a structured sentence that explains something that a user can do using your system. It's easy to do these poorly or just treat them as requirements, but done properly they provide a real shape to the work to be done because they're explicitly demonstrable (That's a big deal in agile - producing incomplete things that work as an iterative process). If you have something small and concrete that you can demonstrably do or not to, it becomes a lot easier to ask yourself what work you need to do to accomplish it.

Properly structured, a user story goes something like "As a [KIND OF USER] I want to [DO SOMETHING] so that [REASON]"[1]. For example, "As a student, I want to be able to buy parking passes online so I can park my car at the dorm".

I was thinking about this today, and I realized that I would love to use this in campaign planning - specifically, I want to have a "user story" for each PC.

There are a few reasons for this. First, the DO SOMETHING for a REASON pairing can be easily interpreted as a call to action and a pointer at what might happen next. That is to say, as each story gives the GM clear direction regarding where they want to go, and the reason hints at what the next arc goal for the character might be.

Note that this is slightly different (and more useful) than a goal, because it's got an explicit action component to it. There is no question of how this translates into play - it's something the character intends to do.

It also scales well. In agile, a full project can be made of many user stories. In the same way, a larger goal can be composed of many user stories, but only if the player wants to.

Take for example, a character driven by revenge. As KROM THE MIGHTY I want to FIND MY PARENT'S KILLER so that I can AVENGE THEIR MURDER.

That's nicely concrete, and depending on how it's approached, it could be the story for a session or for an entire campaign (and that distinction should be discussed with the player). For a one shot, then it's right there - in the session, Krom must find his parent's killer so he can confront them. For a campaign, this gives something to work back from. How does he find his parent's killer? Does he know who he's looking for? no? Ok, how does he identify them? Snake Symbol? SNAKE SYMBOL! And now, his user story is:

As KROM THE MIGHTY I want to IDENTIFY THIS SNAKE AMULET so that I can FIND OUT MORE ABOUT MY PARENT'S KILLER.

So how many stories should a character have? Obviously, Krom has a lot of stories that build up to his vengeance, so what do we do with them?

Agile has an idea called "The backlog". Basically, all stories go into the backlog as you think of them, and then at the beginning of a sprint (a period of doing work - in game terms, consider is a session or short arc) you pull out the ones you'll be working on for this sprint. PC user stories could work the same way - a PC might have any number of stories at a time, but only one of them is "active" for a given session. Something else comes up, throw it into the backlog - maybe it's next week's story.

The only rule is that play should be pushing stories to done. If a story has to go back into the backlog, that's a bas sign.

Now, the fact that this is based on Agile doesn't mean you need to follow EVERY rule. For example, if you consider a "sprint" to be 3 sessions or so, you may end up staggering the characters, so that they resolve their stories (and pick up a new one) at different times. You also can play fast and loose with resources, since velocity isn't much of an issue (though that might be worth considering another time). If you have one user story per player and possibly a user story or to for the group, then you should always have enough material to drive a session of play in awesome directions.

1 - Agile nerds will point out that this is not the only structure, and that Reason is far from obligatory. And they will be right. But this particular model works for what I'm trying to accomplish here.