Over the years, product management has attempted many different approaches for describing customer needs. We’ve used traditional requirements, use cases and have tried open discussions. Today, we often use some form of story.
Most teams have adopted a user story formula for writing requirements: “As a <role>, I want <a feature> so I can <achieve an outcome>.”
Structure is nice. But the problem with today’s user stories is that they aren’t interesting. And they aren’t stories.
A story should be a usage scenario—one or more illustrations of a problem for a persona. It’s a narrative. It explains the problem in the form of a real-life story. And it doesn’t mandate the implementation. And it doesn’t have to be boring.
Jennifer is a divorced working mom and she worries about her daughter, Sally. After all, who doesn’t worry these days? To make things worse, Jennifer’s ex-husband is unreliable; he often makes commitments to pick up Sally at school or at after-school projects, and then forgets completely.
For example, one afternoon at 3:30, Jennifer learned that Sally was still at school when she was supposed to be at soccer practice. Jennifer wondered, “Why did I ever marry that jerk?” as she raced from the office to pick up Sally.
Jennifer would feel a lot better if she always knew where Sally was—that is, when she was where she’s supposed to be, and more important, when she’s NOT where she’s supposed to be.
The question for your product team is: What can we do for Jennifer and Sally?
Bring a group of smart designers and developers together to talk about Jennifer and Sally and their problems. Tell the team about the business opportunity found in solving those problems and participate in a brain-storming session on how you might solve them with your organization’s expertise and innovations.
Ron Jeffries, one of the three founders of Extreme Programming (XP), advocates the form of “card, conversation, confirmation” for stories. By itself, the card isn’t valuable, it is merely a placeholder for the story. Each story requires a discussion with the product team and a method for determining when the story capabilities have been delivered successfully. Unfortunately, many teams seem to have forgotten the conversation and confirmation parts.
Don’t wait until the end of planning to involve your product team. Good stories and use scenarios are written with the team, not for the team.