34 lines
7.1 KiB
Markdown
34 lines
7.1 KiB
Markdown
|
# Story Crafting Checklist
|
|||
|
|
Testing well requires at least some familiarity with the entire product development life-cycle. Of particular importance, is the very beginning. The point at which we want to start work on a new piece of functionality, or a feature we want to offer our customers. This is the time when we begin the process of designing not just the product feature, but what story we want to tell ourselves about the work. It is the time when we imagine what the journey will be like, and when we set expectations for that journey.
|
|||
|
|
|
|||
|
|
This is why it's essential that we become good storytellers, both as engineers and as testers. As with any genre of storytelling, certain habits will improve the kind of story you are telling. Many authors who have written on the subject of writing itself, have offered various guidelines and tips to that effect. As it turns out, some storytellers in the genre of product user storytelling, have also done this for us. The following is an excerpt from "_User Story Mapping: Discover the Whole Story, Build the Right Product_" [^1] . I recommend reading the entire book, but this excerpt deserves highlighted attention. In particular, note the use of the five questions: Who, What, Why, When, How. These are essential questions in any storytelling effort, and any journalist will tell you they are the central pillars of any crisp, timely narrative, that will help to distill the essential moral of the story we are telling. This will help us focus our stories, and make the journey more enjoyable. Testers, pay close attention: each of these questions will have implications for testing. Namely, the what and the why of the testing story will be heavily influenced by the way these questions are answered.
|
|||
|
|
|
|||
|
|
> ### Really talk about who
|
|||
|
|
> Please don’t just talk about “the user.” Be specific. Talk about which user you mean. For Gary, he could talk about the band manager or the music fan. Talk about different types of users. For many pieces of software, especially consumer software, there are very diverse types of users using the same functionality. Talk about the functionality from different users’ perspectives. Talk about the customers. For consumer products, the customer (or chooser) may be the same person as the user. But for enterprise products, we’ll need to talk about the people who make buying decisions, their organization as a whole, and how they benefit. Talk about other stakeholders. Talk about the people sponsoring the software’s purchase. Talk about others who might collaborate with users. There’s rarely just one user who matters.
|
|||
|
|
>
|
|||
|
|
> ### Really talk about what
|
|||
|
|
> I like my stories to start with user tasks — the things people want to do with my software. But what about services like the kind way beneath the user interface that authorizes your credit card for a purchase, or authenticates you on an insurance website? Your users didn’t make a deliberate choice to get their credit cards pass:\[ authorized\] or have their credentials verified. It’s OK to talk about the services and the different systems that call them. It’s OK to talk about specific UI components and how the screen behaves. Just don’t lose sight of who cares, and why.
|
|||
|
|
>
|
|||
|
|
> ### Really talk about why
|
|||
|
|
> Talk about why the specific user cares. And dig deeply into the “whys,” because there are often a few, and they’re layered. You can keep “poking it with the why stick” for a long time to really get at the underlying reasons why. Talk about why other users care. Talk about why the user’s company cares. Talk about why business stakeholders care. There are lots of great things hidden inside why.
|
|||
|
|
>
|
|||
|
|
> ### Talk about what’s going on outside the software
|
|||
|
|
> Talk about where people using your product are when they use it. Talk about when they’d use the product, and how often. Talk about who else is there when they do. All those things give clues about what a good solution might be.
|
|||
|
|
>
|
|||
|
|
> ### Talk about what goes wrong
|
|||
|
|
> What happens when things go wrong? What happens when the system is down? How else could users accomplish this? How do they meet their needs today?
|
|||
|
|
>
|
|||
|
|
> ### Talk about questions and assumptions
|
|||
|
|
> If you talk about all those things, you’ve likely stumbled across something you don’t know. Identify your questions and discuss how important they are to get answered before you build software. Decide who’ll do the legwork to get those questions answered, and bring them back to your next conversation. You’ll find it takes lots of conversations to think through some stories. Take time to question your assumptions. Do you really understand your users? Is this really what they want? Do they really have these problems? Will they really use this solution? Question your technical assumptions. What underlying systems do we rely on? Do they really work the way we think? Are there technical risks we need to consider? All these questions and assumptions may require deliberate work to resolve or learn. Make a plan to do just that.
|
|||
|
|
>
|
|||
|
|
> ### Talk about better solutions
|
|||
|
|
> The really big win comes when those in a story conversation discard some original assumptions about what the solution should be, go back to the problem they’re trying to solve, and then together arrive at a solution that’s more effective and more economical to build.
|
|||
|
|
>
|
|||
|
|
> ### Talk about how
|
|||
|
|
> When sitting in a story conversation, I often hear someone anxiously say, “We should be talking about the what, not the how!” By that they mean we should be talking about what users need to do, not how the code should be written. And I feel the same anxiousness when we talk about the “what” without talking about the “why.” But the truth is, we’re trying to optimize for all three in a good story conversation. What goes wrong is when either party assumes that a particular solution or the way it’s implemented is a “requirement.” Without explicitly talking about how (and if you’re a developer, I know you’re thinking about it), it’s difficult to think about the cost of the solution. Because, if a solution is too expensive, then it may not be a good option. Be respectful of the expertise of others in the conversation. Don’t tell a highly trained technical person how to do her work. Don’t tell someone intimately familiar with users and their work that he doesn’t understand. Ask questions, and genuinely try to learn from each other.
|
|||
|
|
>
|
|||
|
|
> ### Talk about how long
|
|||
|
|
> Ultimately, we need to make some decisions to go forward with building something or not. And it’s tough to make this sort of buying decision without a price tag. For software, that usually means how long it’ll take to write the code. In early conversations, that might be expressed as “a really long time” or “a few days.” Even better is comparing it to something already built — “about the same as that feature for commenting we built last month.” As we get closer to building something, and we’ve had more conversations and made more decisions, we’ll be able to be a bit more precise. But we always know we’re talking about estimates here, not commitments.
|
|||
|
|
|
|||
|
|
[^1]: Patton, Jeff; Economy, Peter. User Story Mapping: Discover the Whole Story, Build the Right Product (Kindle Location 1946). O'Reilly Media. Kindle Edition.
|