We all like a good story – right? But when can a story help shape a great product, predict the success of a project, or guide a software team to success? When it’s a “User Story.” The idea of a user story works like this – when you hire a bunch of experts, they know what they are doing. But how do you guide them? How do they all understand the grand vision? Is it like herding cats?
A story of a single user, and how that typical user would use the product, lets every expert understand the vision of the project. And it’s not just in software. …
The gaming industry hires writers to write a story for the hero, villain, and even the history of the game landscape. These are called “back stories” and they help guide the project. For example, a character designer may be asked to design a dragon. But the back story tells us the dragon eats gold. So the designer, without any further instruction, may loge a single gold coin in the dragon’s teeth. That small detail was not in the notes, it did not come from a creative director or any written instruction. The artist just “felt” that little touch would be right after reading the back story. So it goes with product development.
Today, automobile designers use back stories to decide what features to add to pickup trucks. A good example is the diesel motor option. A diesel engine increases the power of a pickup. But it also adds 300 kilos of weight. And paradoxically, reduces how much cargo the pickup can haul in the bed of the truck … by 300 kilos (the engine’s weight).
Sure, the diesel can pull a heavier trailer, but the300 kilos engine means the struts and shocks limit how much weight can be put in the bed of the truck. A 300 kilos heavier motor reduced how much weight can be placed in the bed. Trucks have a limit to how much weight they can safely be driven with per axil. This is known as the Ground Vehicle Weight Restriction (GVWR).
So when deciding if a pickup should have a diesel option, the car companies look to the user story to see if that optional engine makes sense for the typical buyer. If the story has the pickup owner sitting at a bar with friends, bragging about hauling capacity, then no. The person (normally a guy) does not want to be seen as someone with a “light weight” truck. One the can’t carry as much as his friends.
But things change when the pickup truck owner’s story is one of a person hauling a big trailer. They don’t care about how much they can put in the bed of the truck, they care about total hauling tonnage.
And the same is true in software. When designing an application, the person making the database decision is aided by a story that reduces the application to one idealised customer or user. Do they, like the pickup driver, want to look good to their friends by using the latest app? Is integration with InstaGram or Facebook important to them? The more the software development team knows about the idealised buyer and the story of their life, the more likely the software will be a hit.
A survey may give you the data about typical users, but do you give that data to the development team … no.
Trying to remember lots of data about customers is tough. But our brains are wired to remember stories. Take all the end user data, give it to a writer, and let them create a story – a user story. These stories help the whole team understand, realise and imagine living in the user’s world. And that helps the whole team design better games trucks, or software.
My recommendation: User Stories Applied: For Agile Software Development, Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software. The best way to build software that meets users’ needs is to begin with “user stories”: simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle.