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.
My only issue with this is that I game to get AWAY from work.
It’s like the dude in my eclipse phase game who’s playing a multiforking hacker. I keep wanting to write him an integration map to keep his check ins clean.
I totally did not read multiforking.
When you can backup, fork, and re-merge your brain, life becomes interesting.
As a budding Agile nerd, I support this.
As a Kanban nerd, I’m already imagining using Trello to track individual PCs’ story backlog.
As someone who wants to do epic, open-world, large-cast, shared-character gaming, I’m imagining how this tool could be employed to easily track all the necessary information.
And, just in general, I’m thinking now of how to apply Agile to game design.
So, thanks, Rob!
Your idea has a lot in common with this: http://rpg.stackexchange.com/questions/8471/how-do-i-keep-a-long-range-plot-cohesive-and-coherent/8481#8481
Check out the “Who, Wants, So” framwork. It features the goal first, then the action, while User Stories swaps this order (the role/character comes first in both approachs). I really enjoy this framework, but when your friends grows up, it becames hard to from an regular group, so I haven’t used it — yet!
After reading this, you can find me hiding under the bed trembling in fear and making the Ward of Away at Jira and Greenhopper. I’m scared! This is scary! And… kind of horribly seductive!
Also, more examples, plz.
Hmm, I could easily wrap an incentive structure around the backlog. Likewise, using a variant of the Lady Blackbird keys and buy-off economy on user stories is appealing to me.
As KROM THE MIGHTY I want to FIND MY PARENT’S KILLER so that I can AVENGE THEIR MURDER. (Resolve, get 2 more stories)
As KROM THE MIGHTY I want to IDENTIFY THIS SNAKE AMULET so that I can FIND OUT MORE ABOUT MY PARENT’S KILLER.
As KROM THE MIGHTY I want to FIND SOMEONE SPECIAL so that I can LIVE MY OWN LIFE.
Now you have conflicting user stories, and you may have to choose which of these are active and which are in the backlog. That seems like rich design space.
This is very similar to how occult spells work in Orrosh (a Torg worldbook)
You start out with a simple statement: I will kill the werewolf.
Then you expand on it: I will use a magic sword to kill the werewolf.
And then: I will create a magic sword to use to kill the werewolf.
And eventually you get the complete spell: I will find a magic ritual in the Book of Shagmoor that I will use to create a magic sword from virgin silver in order that I might kill the werewolf.
Each additional action increases the potency of the resulting spell.
You cannot find any right or wrong technique to make a website.
We have websites in connection with one specific area of interest and as well internet sites for fully unrelated products.
It’s definitely under your control which in turn way you should
move. One issue though…you advise Digg, so why do spent cash possessing a .
web.. I’ve often pondered if this had been
significant. A remedy could well be awesome!
Here is my homepage … Instant Auto Insurance
Good poѕt. I absolutely аppreсiate
this ѕіte. Ѕtick with it!
Here is my site : Woodworking
Maybe you could pomodoro your sprints 😀
Its a nice read and a good idea, but maybe youre mixing too much work into your play? Backlogging good spontaneous forks in an adventure would make the roleplaying experience more boring, atleast it would for me.
I wonder if such an approach could be combined with FATE to manage what Aspects are active. On thing that is left hazy in FATE is how or why Aspects change. So a typical FATE Aspect might be “Obsessed with Avenging Parents”. But this could be subbed out for whatever relevant story is active in the session. Eh?
As a dev and an agile bigot^h^h^h^h^h evangelist, got the the REASON part of the story is arguably the most important part. The WHO part is mainly there to tell you who to talk to, and the DO SOMETHING part can change.
But it can only change if the REASON is still fulfilled. Without the REASON, you can’t make judgements as to the most appropriate DO SOMETHING. You can’t apply common sense or creativity. You have to stick to the – often sub-optimal – DO SOMETHING you’ve been given.
Also, without the REASON, how can the product owner prioritise?