Discover Scenarios Within Stories

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.

Share on twitter
Share on facebook
Share on linkedin

Navigate to other Posts

Steve Johnson

Steve Johnson

Steve Johnson was a founding instructor at Pragmatic Institute, a role he held for more than 15 years before he left to start Under10 Playbook. In his return to Pragmatic Institute, Steve supports the complete learning path for product teams, ensuring they are fully armed for success.  Over the course of his career, Steve has helped thousands of companies and tens of thousands of product professionals implement product management processes. He has worked in the high-tech arena since 1981, rising through the ranks from product manager to chief marketing officer. Steve has experience in technical, sales and marketing management positions at companies that specialize in both hardware and software. In addition, he is an author, speaker and advisor on product strategy and product management.

Related Content

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Never miss a thing.

From new podcasts and webinars to events and great content, make sure you’re always in-the-know by subscribing to Pragmatic Institute.

Choose your preferences below and receive only the things you care about most. We’ll keep your information confidential and never share it with third parties.

Stay up-to-date on all the latest news and products. 

Subscribe today.