Use Scenarios are Stories That Provide Context

Over the years, product management has attempted many different approaches to describing customer needs. We’ve used traditional requirements, use cases and open discussions. Today, we often use some form of a story. Here’s the Pragmatic argument explaining the power of use scenarios.

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 use scenario—one or more illustrations of a problem for a persona.

Use scenarios are narratives. 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 brainstorming 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.

Learn more about how to utilize and craft use scenarios??

Pragmatic Institute Course: Build?

This course gives you the tools you need to prioritize requirements and plan releases that deliver truly remarkable experiences to your market.??

What you’ll learn in Build:

• Implement a proven approach for working across locations and development methodologies
• Empower product management to focus on the “what,” and development to focus on the “how” of building better products
• Group requirements to ensure releases deliver results
• Provide clear context on who to build for and what problems to solveStreamline estimates for increased efficiency

>> learn More?