Jeff Patton User Story Mapping Pdf Free
Marién Hadges
In traditional product-development processes, teams often rely on wasteful and lengthy business requirements documents and functional design specifications to move from a vision for a digital product to outlining what it should include and how it should work. Instead of having an ongoing conversation about users, problems, ideas, and solutions, teams expect distributed documentation to suffice.
However, these documents usually fail; no one has the time or attention to read them, and even those who do read them end to end will likely come away with vastly different interpretations of what to build. Rather than propelling productivity, these heavy documents stifle creativity, communication, collaboration, and innovation from the start. As an alternative, user-story maps work much better as lightweight representations of the digital product that an Agile team intends to build.
User-story mapping: (Also known as user-story maps, story maps, and story mapping) A lean UX-mapping method, often practiced by Agile teams, that uses sticky notes and sketches to outline the interactions that the team expects users to go through to complete their goals in a digital product.
Jeff Patton popularized the method, which replaces the lengthy, technical requirement gathering and siloed updating processes found in waterfall development. Story maps are intended to spark collaboration and conversation among Agile team members, while providing them with the bigger picture of how the digital product flows and fits together. This latter quality of story maps is important in the Agile environment, because losing sight of the product as a whole is a common challenge, likely to arise when teams work from a discrete list of user stories in a backlog.
Agile teams commonly rely on small, high-value user stories to plan and estimate what to work on each sprint. In the user-story map, activities, steps, and details are captured as short, succinct verb phrases representing user actions. These serve as the basis for the first half of the user-story format, describing what the user needs or wants to do. The story can then be elaborated upon to include the key benefit to complete the second half of the narrative. Thus, the mapping method is called user-story mapping because it can be used to evolve the verb phrases captured on the map into fully fleshed-out user stories that can be discussed further, eventually paired with acceptance criteria, and added to the product backlog for prioritization and estimation.
Story maps can be used at any point in the product-development process to drive discussion and align the team. You can create a story map to plot the experience for a new product, after initial discovery work, or for an existing product, after usability testing. In either case, the story map begins to illustrate solutions to the problems uncovered in the research. Once created, teams will maintain and refer back to their story map over time; they add to it, modify it to reflect the actual state of the product, and use it to guide what to work on and release in subsequent sprints.
To create a story map, in-person teams use sticky notes, white boards, and open wall space; remote teams can take advantage of video conferencing and collaborative spreadsheets, presentation slides, or web-based programs. Everyone should work together on the map; no one person or role should dominate the others.
LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.
Three years ago I wrote about Jeff Patton's "Story Mapping". I described this technique as a great tool to help design and develop products (see Fig. 1 below for a good example of a Story Map). Jeff Patton has now written a book about this technique, titled "User Story Mapping".
Main learning point: User story mapping is a great tool for anyone who wants to create a structure and conversation around a user problem or a product idea. Jeff Patton's technique makes you take a step back and think through the problem(s) you're looking to solve. "User Story Mapping" thus provides a very valuable framework to anyone involved in product development.
A User Story Map is a useful tool for the team to understand the big picture, giving them the ability to see the entire breadth of the system and the various users and uses. It arranges user stories into a holistic model to help understand the system functionality while allowing you to identify gaps and slice functionality into releases.
This was a great broadcast. I liked the straight forwardness when Jeff said that its a pattern, because, recently, unknowingly, I did end up doing something similar like story mapping. It was not at detailed though. But after listing this, I feel charged up to re-visit that mapping and look at it from a new perspective all together.
EDITI would also be interested in understanding if I should have one or multiple or story maps in a project? Does it makes sense to split them into different story maps? Like registration, search, and so on.
User story mapping is not directly about building a Product Backlog. It is about building a narrative for your product to encourage discussions about what to build, and what the minimum viable product really looks like. Specifically, you should approach user story mapping as an exercise in describing the flow of user experience rather than getting bogged down in implementation details.
Don't try to build your map up from user stories. Instead, define your narrative and build your feature list down from the narrative. This is admittedly somewhat of an art, as the story map is really an emergent property of the exercise rather than a formulaic construct.
You may find yourself shuffling stories, epics, and themes a great deal in the beginning. You might also find yourself redefining your narrative several times as a result of the conversations that story mapping is intended to trigger. That's all to be expected.
There is no real need to start with User Roles although once you start adding your high level features, you will find that more features with different needs will develop by using Roles. This can be taken further by describing the Role further with a Persona description e.g.
1) Identify all the users that enter the system.1a) Identify which users are the most important.2) Do a happy path process map for how each user will flow through the system.3) Based on the process map identify the features the system needs to support.4) Look across all your process maps and see if there is a critical feature or features that will need to be implemented to support other features.5) Take features identified in step 4 and do a simple story map that decomposes the feature (epic) into stories.6) Stop when you have enough features decomposed that will keep you busy implementing for the next 2-6 weeks.
If you get to step 3 and start thinking that, holy crap that is a lot of process maps, thats OK, just do the first 2-3 process maps to represent your most valuable customers/flows. Then derive your highest priority features/epics off of those maps. Then decompose from there.
The idea is to only generate partial story maps that describe the highest priority stories you want to implement short-term. You will go nuts trying to create an all encompassing story map if the system is feature rich. I'd encourage you to avoid trying to story map out the entire project since you will find that many of the features and stories will change over time as your requirements become clearer.
I see that youre using storiesonboard.com (I use it too!) to create your user story map. In this tool, you must create the high levels first, and goes down to the low levels, where you have the details (or, best saying, the stories) of each functionality. Usually, a user story map starts with the user stories itself, and then you organize in high levels to get a better picture of your application. From this, youll be able to prioritize the funcionalities for the first release. In the storiesonboard.com, I believe you cannot work in that way, since the system requires you to begin with the high level cards, but its fine if you dont get lost. Storiesonboard.com can be a great tool if your work with remote teams.
You can have cards with the business goals intended to achieve with the app to let you remember what is really important and configure the releases accordingly. You can have cards for type of users of the app too, to know the public you will dealing with and define what stories will be handled first. And, most important of all, is not writing the user stories, but understand how it should be use, and reach a state of shared understanding between you and your customer (and others people in the project). So, unless youre creating a map for yourself, envolve and engage others stakeholders in the process.
What I found to work for us is to identify/discuss personas first, take a note of them outside the map and start the map with the processes like in your first example.
Identifying personas helps thinking about tasks these people do, so you can easier map the process.
As Bruno mentioned, you can't start with the second level in StoriesOnBoard. To overcome this I just create one card on the first level and put all the second level cards under that. Later when I can group the second level cards, I create the groups on the first level and move the second level cards under them.
If it's important to see which persona does a given task (and it's not obvious), we write it in it's title: "Admin: Manage user accounts"
In case you start with processes there might be certain scenarios where one process could work differently for different types of users.For e.g. a basic Registration process could be different for an Admin user and an external customer. In this case it makes difficult to prepare a clear story map for all the scenarios.
7fc3f7cf58