User Stories and User Story Mapping are must have techniques for a Business Analyst.
You can do business analysis without SCRUM, but you can’t do good SCRUM without Business Analysis. Story Mapping enables clarity of user stories.
Agile Alliance talks about the benefits of User Stories, “One intent of this practice is to avoid a failure mode of incremental delivery, where a product could be released composed of features that in principle are of high business value but are unusable because they are functionally dependent on features which are of lower value and were therefore deferred to future releases.”
That’s a pretty in-depth explanation, but in general User Stories help create a higher quality product for the customer. “Story Mapping is an engaging activity where all participants are involved in the process of building the product backlog on a wall, versus writing a dull 100-page requirement document.”
User stories are seen as more visual. It allows you to see the big picture in your backlog.
User Story Components
According to Mountain Goat Software, “User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.” A typical User Story consists of:
As a < type of user >, I want < some goal > so that < some reason >.
Know Your Stakeholders
Having knowledge of the process enables bringing the identification of stakeholders into the picture. The additional identified stakeholders help validate whether user stories are accurate and will allow the project team to introduce change management activities early. One change management strategy which User Story Mapping encourages is to facilitate stakeholder buy-in. Stakeholder buy-in is vital and benefits the project team as these stakeholders can help develop additional user stories that the project team potentially have missed, elicit business impacts and helps validate design and prioritization discussions.
Requirements Are User Stories
User stories capture requirements and can be used to model a meaningful sequence of user activities, perpendicularly across a prioritized ranking of user stories. The benefit of which encourages richer discussion in planning and prioritizing user stories, further engages stakeholder participation, is a mechanism to help understand business impacts and can allow a team to see how user stories affect the customer journey visually.
Story Mapping is about taking a series of User Stories and putting them together in a meaningful and visual way.
J Patton Associates says, “Story Mapping is the process of arranging user stories into a useful model to help understand the functionality of the system.” This technique allows for the planning and prioritizing of requirements in order of importance and value. The Agile Alliance elaborates story telling a little further, “Story Mapping orders user stories along two independent dimensions. The horizontal axis is depicting the user activities in order of priority or the sequence of process activities and the vertical axis depicting the release or project milestones.”
Once used, story Mapping can enable the project team to dice stories (often at Epic level) horizontally into the main functionality. This horizontal view is important as it visually represents the value stream of the designed solution. This analysis allows the project team to understand the dependencies and highlights gaps for how the created User Story functionality will work. This end to end perspective enhances understanding the customer journey of a person using the solution.
The vertical axis is important as it represents the project teams User Story release plans. Project team centers discussions on which user stories are high value and easy to develop. Leave complex user stories to later releases. This focuses the project team on creating a minimum viable product (MVP) for the customer. Sprint reviews can help fine tune the product and allow the project team to assess User Story release patterns regularly. The vertical positioning of user stories enables the project team to discuss whether user stories are prioritized in terms of need, value, and complexity.
Prioritization of User Stories can help build the User Story Map. User Stories seldom keep their same priority throughout the cycle so be prepared to re-prioritize often. High-Medium-Low prioritization sounds easy, but everything winds up as high priority. Use the hot air balloon technique for prioritization. Is this User Story more or less important than this User Story? Comparison of user stories to each other brings out additional discussion on risk and why a User Story is more important to the overall customer experience.
User Stories are high-level by nature. System Requirement Specifications (SRS) are more detailed and lower level in nature. Depending on the project you might need to use both User Stories and System Requirement Specifications together to create a User Story Map. Thinking about how the User Stories relate to each other in a logical flow for the developer, release to the customer, and other technical, environmental issues will drive putting together a Story Map.
Complex User Stories are typically a good candidate for more technical details. Get details when trying to fit a User Story on the Story Map isn’t making sense. More technical details might help you place the User Story in a better position in the Story Map.
We hope this information has been insightful. In our next series, we will discuss on how to create Personas.