In Part 1 post of this series, I started with an imaginary conversational travel assistant product and demonstrated how to create its Persona and Problem Scenarios . I also introduced the Value Proposition concept as a better alternative/s to the exiting alternative/s.
In this post, we will continue our case study to learn how to create and use them to drive narrative collaboration, which is at the heart of successful agile practice.
According to BJ Fogg’s Behavioral Model, the most important elements to getting the user to act and use our product are Motivation and Usability. We will cover Motivation (Value Proposition) in details in the coming posts, while in this post we will focus on Usability and creating a good user experience through stories.
User stories should flow from problem scenarios to make sure they address an existing problem, need or desire the persona has. Each user story has this format:
As a [persona], I want to [do something] so that I can [realize a reward]
Why these parts are important?
- [Persona]: Helps constantly tying back to whom we are building this software for? What motivates them? What is an example of this persona?
- [Do something]: Do something on our software
- [Realize a reward]: A clear and discrete ending to our user story. What the user wants to achieve at the end of the story? How do we test it and make sure it happened?
Do you notice how consistent is the pattern of humanizing our product development from the persona to problems scenarios to user stories development? Who is our customer after all?! Well, unless you are developing a machine-to-machine product, which will hopefully be triggered by a human action at the end!
I won’t go further on user stories as there are many online resources dedicated to explaining them in details. However, I would like to emphasize the narrative nature of what we are creating in this series and how it fosters high level collaboration within the team and comprehensive understanding to the context of the product and why it is being created. As a result, we will have a motivated and innovative team that owns the problem and looks for creative solutions rather than just following instructions and losing motivation.
So far so good! Let’s now develop user stories for our Travel Assistant product.
TravInfo User Stories
I will start with an Epic story which is nothing but a large user story that can be broken down into a number of smaller stories. Having said that, an Epic should be specific and discrete and should not encapsulate the whole idea of your product or even the whole feature in most cases.
Epic Story
As Roland the junior manager, I would like to learn about new destinations and places so that I can score them.
Child Stories
Will break down the Epic story into child user stories as follows:
| Child Story | Test Cases |
|---|---|
|
As Roland the junior manager, I want to get a list of places based on my criteria so I can select a specific place |
Make sure it is possible to search places by criteria Make sure a place can be selected Note: Criteria should be easily cleared so that he can start over anytime |
|
As Roland the junior manager, I want to select a place from the search list to find out more about that place |
Show place details when he selects it from the list Make sure he can return to the search result Make sure he can browse through all place details |
|
As Roland the junior manager, I want to score a place so that I can compare it with other places |
Make sure a place can be scored Make sure he can delete a place score Note: Score scale is from 1 to 5 |
Finally, it is worth noting the following about user stories:
- They are discrete, atomic and testable: Test cases make sure the development team is aligned to business and usability requirements. For instance: Make sure search allows for keyword search in addition to search by specs. This test case makes sure we are delivering the business value but the system is not rigid and unusable in case the user forgets about the specs and wants to search by whatever keywords he still remembers
- They mainly serve as a basis for narrative collaboration in agile teams vs being product requirements. We might still need to have other requirement documentation such as Use Case Diagrams, Information Flow Diagrams and non-functional requirements… etc
Mat Kasem 