Thursday, April 16, 2020

Player Stories

In my agile coaching journeys, one of the things I see misused the most is the User Story.

User Stories were challenging for us to embrace at High Moon Studios. We were very document-driven, and User Stories just became another form of detailed documentation for us. Our coach Mike Cohn worked hard to wean us off of our desire to write everything down, but we fought him. At first, we stapled 10-page documents to the 3x5 index cards he told us to use. When he discouraged that, we found ways to fill the index cards with tiny printed fonts.

Even when we switched to the Connecxtra Template:
"As a [someone], I want to do [something], so that [I get some benefit],"
we got it wrong. User Stories simply became structured features or tasks.

For example:
"As a User, I want an ammo pickup so I can keep using my weapon."

So what's wrong with this? As a feature, nothing. It's an excellent feature. But it doesn't represent what User Stories are meant for. They are intended to demonstrate why the user wants something. This finally hit home when we encountered the following User Story:
"As a player, I want police chasing me through an open city."

We might have ignored any problems with this, but we had a short schedule and someone on our team who wouldn't stop asking questions about it.

The first question was about the missing second part of the story:
"so that [I get some benefit]"

The question was, "what is the motivation created by police chasing the player?"

Why would a player want police chasing them? The answer is that police chasing the player is a means to an end.

So what is the motivation? Naturally enough, the motivation is to have a hair-raising time racing through an entire city and getting away, which you can't do if the police catch you.

Expressing that as a User Story became:
"As a Player, I want to race through a city so that I can achieve my goal of getting to the next level."
Notice the reintroduction of the word "to." This communicates a motivation for the player.
Let's instead call this a "Player Story."

Why Do This?
There turns out to be a beneficial reason for writing stories this way. It turns out that when you write Stories about why the player wants something, developers come up with better solutions for fulfilling those desires. This was the case with Player Stories. When we started having conversations about "As a Player, I want to race through a city so that I can achieve my goal of getting to the next level," the focus became more about the player experience and less about the police feature.
With previous games, such as "Midnight Club," we'd spend people years coming up with the best police AI because we were focused on the AI feature. The solution was never great. Police AI in a complex city is tough to implement and very expensive.

On this game, we asked ourselves, "what does the player really need to drive that motivation"? The answer was, "the need to drive fast enough to not get caught or crash." The developers focused on that by simply looking at the player's average speed. When the player drove too slow, they'd play a siren sound. Then, if the player continued to drive too slow, they'd ramp up the threat (flashing lights, police cars appearing and ramming you, etc.) until the player got arrested (cinematic). Not worrying about AI navigation, etc. shaved many months off of the work. The results were better because we kept focusing on the player experience.

Other Benefits
Focusing on player motivation led to other benefits. First, splitting Player Stories like this into smaller Sprint-sized stories became easier. Most of the time, it was about a slice of the whole experience, such as having a cube car racing through a cube city filled with ping-ponging traffic cubes and siren sounds. That showed us what was working or not after the first sprint. The previous approach of splitting features would have resulted in parts of the experience, such as police AI navigation, that wouldn't prove their value for months.

Not all User Stories need to be Player Stories that capture motivation, but more Epic (large) Stories should. When the motivation of the player is at the forefront of design and planning at every level, you get better results for the player.