What do you think?
Rate this book
User Story Mapping: Discover the Whole Story, Build the Right Product
How do you build a product that delights users? You must first know who your users are and how they plan to use what you're building. With this practical book, you'll explore the often-misunderstood practice of user story mapping, and learn how it can help keep your team stay focused on users and their experience throughout the development process.
You and your team will learn that user stories aren't a way to write better specifications, but a way to organize and have better conversations. This book will help you understand what kinds of conversations you should be having, when to have them, and what to keep track of when you do. Learn the key concepts used to create a great story map. Understand how user stories really work, and how to make good use of them in agile and lean projects. Examine the nuts and bolts of managing stories through the development cycle. Use strategies that help you continue to learn before and after the product's release to customers and users
User Story Mapping is ideal for agile and lean software development team members, product managers and UX practitioners in commercial product companies, and business analysts and project managers in IT organizations—whether you're new to this approach or want to understand more about it.
You and your team will learn that user stories aren't a way to write better specifications, but a way to organize and have better conversations. This book will help you understand what kinds of conversations you should be having, when to have them, and what to keep track of when you do. Learn the key concepts used to create a great story map. Understand how user stories really work, and how to make good use of them in agile and lean projects. Examine the nuts and bolts of managing stories through the development cycle. Use strategies that help you continue to learn before and after the product's release to customers and users
User Story Mapping is ideal for agile and lean software development team members, product managers and UX practitioners in commercial product companies, and business analysts and project managers in IT organizations—whether you're new to this approach or want to understand more about it.
324 pages, Paperback
First published February 22, 2012
About the author
Jeff Patton
12 books84 followersJeff Patton has designed and developed software for the past 12 years on a wide variety of projects from on-line aircraft parts ordering to electronic medical records. Jeff has focused on Agile approaches since working on an early Extreme Programming team in 2000. In particular Jeff has specialized in the application of user centered design techniques to improve Agile requirements, planning, and products. Some of his recent writing on the subject can be found at www.AgileProductDesign.com and Alistair Cockburn’s Crystal Clear. His forthcoming book to be released in Addison-Wesley’s Agile Development Series gives tactical advice to those seeking to deliver useful, usable, and valuable software.
Jeff works currently as an independent consultant, is founder and list moderator of the agile-usability Yahoo discussion group, a columnist with StickyMinds.com and IEEE Software, and a winner of the Agile Alliance’s 2007 Gordon Pask Award for contributions to Agile Development.
Jeff works currently as an independent consultant, is founder and list moderator of the agile-usability Yahoo discussion group, a columnist with StickyMinds.com and IEEE Software, and a winner of the Agile Alliance’s 2007 Gordon Pask Award for contributions to Agile Development.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 326 reviews
February 26, 2015
User story mapping is great, but this book used three times as many pages as necessary to explain it. I was also dying to see one large legible illustrated example, not tons of tiny grainy photos.
December 12, 2014
Great book, with issues.
In general, the content is great. The knowledge that's getting passed to the readers is well served & valuable. The content is well illustrated & clear. But all of that gets really annoying, because the book is just too wordy. Quite quickly I got the impression (and I couldn't get rid of it until the end) that I'm reading the same stuff again - even if it's smart & applicable, it gets annoying.
What are my favourite parts / chapters?
* about how requirements are supposed to be formed ("They are the requirements")
* about "accurate estimates" :)
* about the value of working software ("Validated learning over working software" Kent Beck)
* about client-vendor as an anti-pattern
And the thing that entertained me near the end of the book: "Stories are actually like asteroids" - actually I think it's a great comparison ;D
In general, it's a good read and I'm happy that I went through, but it's a shame that it was a bit boring.
In general, the content is great. The knowledge that's getting passed to the readers is well served & valuable. The content is well illustrated & clear. But all of that gets really annoying, because the book is just too wordy. Quite quickly I got the impression (and I couldn't get rid of it until the end) that I'm reading the same stuff again - even if it's smart & applicable, it gets annoying.
What are my favourite parts / chapters?
* about how requirements are supposed to be formed ("They are the requirements")
* about "accurate estimates" :)
* about the value of working software ("Validated learning over working software" Kent Beck)
* about client-vendor as an anti-pattern
And the thing that entertained me near the end of the book: "Stories are actually like asteroids" - actually I think it's a great comparison ;D
In general, it's a good read and I'm happy that I went through, but it's a shame that it was a bit boring.
October 26, 2017
I was hesitant to give this book 4 stars, because I found the title somewhat misleading. While it does introduce USM, I found those parts lacked dept. The bulk of the book is more about doing User Stories well, and not directly about USM itself. It's rather repetitive in some parts, and the Kindle version had some parts where the font choices were awkward.
However, it's still a really good book on User Stories, Agile development, and Lean Startup mentality. If I had started reading this book with those expectations, I'd probably been less disappointed by it.
However, it's still a really good book on User Stories, Agile development, and Lean Startup mentality. If I had started reading this book with those expectations, I'd probably been less disappointed by it.
November 19, 2022
Дуже детальна книжка, ловила себе часто на думці що можливо людям з меншою кількістю досвіду в галузі або з аджайл процесами вона буде більш цінною, мені в багатьох місцях було аж надто "розжованою" - та може цього враження не було б, якби в мене не було свого досвіду роботи з цим інструментом.
Сподобалось дуже оформлення, друк і хороший переклад українською.
Також трошки конфюзило те що в книжці під новим соусом (не називаючи це існуючими іменами) пояснюються багато типових концептів як то типи вимог, пріорітизація, демо і ретроспективи тощо. Я думаю що це може спантеличувати людей, або їм буде здаватись що вони читають про щось невідоме і нове.
Сподобалось дуже оформлення, друк і хороший переклад українською.
Також трошки конфюзило те що в книжці під новим соусом (не називаючи це існуючими іменами) пояснюються багато типових концептів як то типи вимог, пріорітизація, демо і ретроспективи тощо. Я думаю що це може спантеличувати людей, або їм буде здаватись що вони читають про щось невідоме і нове.
June 9, 2020
Simply the book that got me a product manager job at a top tech company.
You should get this book if you're an entrepreneur or business person with no tech background and wonder:
- How much should I know about software to work with technology?
- How the heck do I translate my product vision, business model or strategy into working software?
- What does a tech/product team look like?
- What other books might I read to go deeper?
A brilliant journey awaits you at the other side.
You should get this book if you're an entrepreneur or business person with no tech background and wonder:
- How much should I know about software to work with technology?
- How the heck do I translate my product vision, business model or strategy into working software?
- What does a tech/product team look like?
- What other books might I read to go deeper?
A brilliant journey awaits you at the other side.
April 8, 2021
Funny thing for me to see is that I've gave 4 start to work-related work. I usually don't read much, as I want to keep reading fun and relaxing for me, rather than thinking about work outside work.
But this book was fun too - it gave a good view on a quite big concept of building product, and it touched not only user stories, but overall Agile approach to shipping things. I liked coming back to some topics in different chapters, showing a different perspective, as it made the whole learning experience whole.
But this book was fun too - it gave a good view on a quite big concept of building product, and it touched not only user stories, but overall Agile approach to shipping things. I liked coming back to some topics in different chapters, showing a different perspective, as it made the whole learning experience whole.
July 20, 2016
This book provides an overview of a process (story mapping) that can help to increase understanding of a feature before building it. Doing so helps to prevent scope creep and gets multiple members of a team on the same page about what will be built.
Story mapping:
• is a way of talking about who does something, what it is, and why they do it. It also helps us prioritize and agree on the most important paths users need to take, which helps us make decisions down the line
• is used to build shared understanding. Stories are a lightweight form of documentation that is primarily spoken, not written.
• is a collaborative process used to flesh out what needs to be created. Unlike traditional requirements where one person explains and another tries to understand, story mapping aims to get people talking about the best way to solve a problem.
• establishes order and hierarchy. It helps to group things in sequence and by priority. It reveals gaps in understanding and shows how things fit together.
• shows what parts of our understanding are unclear so that we can identify key unknowns to study going forward.
Although the process is clearly described and immediately applicable, I found Patton's context of when to use story mapping to be a bit disturbing. He writes about using story mapping to fully explore a feature based on what we think people need, and then creating a quick prototype in order to test whether that's what people actually need. He includes diagrams showing this cycle of guessing what people need, then checking whether that's what they actually want, then guessing what they need again.
To me that's problematic because he only tacks on a chapter about formative research toward the end of the book, and when he does, he doesn't describe its integration with the rest of the process. Without that formative research before the story mapping, we could very well become invested in the details of a feature that serves no real user need. After starting down the wrong trajectory, we could be iteratively testing and trying to improve something that doesn't serve any real need.
Story mapping:
• is a way of talking about who does something, what it is, and why they do it. It also helps us prioritize and agree on the most important paths users need to take, which helps us make decisions down the line
• is used to build shared understanding. Stories are a lightweight form of documentation that is primarily spoken, not written.
• is a collaborative process used to flesh out what needs to be created. Unlike traditional requirements where one person explains and another tries to understand, story mapping aims to get people talking about the best way to solve a problem.
• establishes order and hierarchy. It helps to group things in sequence and by priority. It reveals gaps in understanding and shows how things fit together.
• shows what parts of our understanding are unclear so that we can identify key unknowns to study going forward.
Although the process is clearly described and immediately applicable, I found Patton's context of when to use story mapping to be a bit disturbing. He writes about using story mapping to fully explore a feature based on what we think people need, and then creating a quick prototype in order to test whether that's what people actually need. He includes diagrams showing this cycle of guessing what people need, then checking whether that's what they actually want, then guessing what they need again.
To me that's problematic because he only tacks on a chapter about formative research toward the end of the book, and when he does, he doesn't describe its integration with the rest of the process. Without that formative research before the story mapping, we could very well become invested in the details of a feature that serves no real user need. After starting down the wrong trajectory, we could be iteratively testing and trying to improve something that doesn't serve any real need.
August 9, 2018
This book isn't simply about a Mapping technique for Stories. It goes a lot beyond that, and it goes beyond because what matters most is not the Map itself but the work you do while you build such thing, the Map is just a supporting tool that helps you and the team visualize the big picture. In this book you'll have a better and more clear understanding on how Stories can help us drive software development. You'll learn and see (literally, through nice illustrations by the author and pics) how Agile development feels like and tips for better planning and collaboration.
Sometimes you might feel that you're reading things over but that's because the author didn't want to simply give you the requirements, he wanted to tell you the stories, thus building a good understanding and sense of it.
Sometimes you might feel that you're reading things over but that's because the author didn't want to simply give you the requirements, he wanted to tell you the stories, thus building a good understanding and sense of it.
March 29, 2022
Another professional development book on my reading list for a good few months finally finished, and I mean 'finally'.
With the average rating being 4.5 stars, I was expecting big things. However, instead, I felt it was more of a mixed bag - hence my middle of the road star award.
The good points are several new innovative ideas that can be implemented, and the book's layout is intuitive.
However, the jokey nature in which it is written started to get on my nerves quickly as it was neither funny nor conducive to understanding the point being made.
For this reason, picking it back up wasn't always something I wanted to do, and I felt like finishing it was a bit of a slog.
With the average rating being 4.5 stars, I was expecting big things. However, instead, I felt it was more of a mixed bag - hence my middle of the road star award.
The good points are several new innovative ideas that can be implemented, and the book's layout is intuitive.
However, the jokey nature in which it is written started to get on my nerves quickly as it was neither funny nor conducive to understanding the point being made.
For this reason, picking it back up wasn't always something I wanted to do, and I felt like finishing it was a bit of a slog.
May 1, 2015
It's great stuff, Jeff is talking about but the style of writing is much more important to me. Jeff is also extraordinary here because he "eats is own dog food", he speaks about story telling while using stories. :-) Thats great. In the second part of the book, the story telling went in the background a little bit but it comes back closer to the end of the book. I also like his humor, on how he is interacting with the reader. It could be a bit more from time to time.
It's highly recommended if you need to visualize a part of a product or a whole product.
It's highly recommended if you need to visualize a part of a product or a whole product.
June 13, 2018
Product development is hard, this book teach us one of the best product development planning, to create better user story mapping in particular. Applicable to team who use scrum or agile process. This book is little bit wordy, but personally I got a lot of lesson learned that we can apply to our team.
September 12, 2021
Read review on my blog
Value for money
9/10
Year, Price, Pages, Cover design
2014 by O’Reilly Media; Euro 26,49; 259 pages (278 pages with Acknowledgments, References, Index, About the Author), Paperback
Cover design by Ellie Volckhausen, Illustration by Rebecca Demarest, Interior design by David Futato. Good paper quality and reading experience
5 sentences about the book
Rethink your expectations of this book: it is not a manual on “how to write user story”, but a broad compendium of knowledge about software product management
It is not one-time reading, but a hand-book you reach for again and again to remind yourself of the basic principles
If you have prejudices against O’Reilly publisher, then this book is an opportunity to get rid of them
The narrator guides you with special care. He is whispering secrets to your ear and he is telling funny stories from everyday life. By the very end, you have a feeling that you’ve known Jeff Patton for a very long time. You may want to invite him for drinks and discuss some parts of the book. (The narrator’s voice reminds me of a character in Ridley Scott’s movie — A Good Year (2006). His name is Henry Skinner and he’s an uncle of our protagonist)
A unique book, an extraordinary book in the best sense of the word
What did I learn?
- I understand better what user story mapping is
I know how to organize the workshop based on the conversation to get the big picture and common understanding of what to build
-You will get several hints, useful tips and checklists like 1. Steps how to build a big picture; 2. Six simple steps for story mapping; 3. A checklist of what to talk about during the conversation; 4. Plan to build less; 5. Plan to build on time; 6. Plan to learn faster; etc.
- I consider User Story Mapping as my top 3 books about product management on my list
What was missing?
- The second half of the book talks about the user story mapping in the context of the discovery process, product backlog, backlog refinement, design thinking, product review, product release and retrospective. I had a strong impression that the narration lost tempo. Everything was fine until the author was focused on explaining what user story mapping is and how to use it. I don’t say that’s bad, but I didn’t read the second half with such focus, involvement and speed.
Favourite quotes:
“You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations.” xxv
“If you get nothing else from this book, remember these things:
Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
Stories aren’t the requirements; they���re discussions about solving problems for our organisation, our customers, and our users that lead to agreements on what to build.
Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build ” xliv
“Stories get their name from how they should be used, not what should be written.” 3
“The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding” 4
“At the top of the maps is the backbone, which sometimes has a couple of different levels. You might start with the basic flow of the story, which is one level. But, when it gets really long, it’s useful to go up one more level to summarize things further.” 23
“Every time we do this we find holes. We find things that we thought another team should be taking care of, but it didn’t know.” 25
“Eric is part of a team that took those ideas and ran with them. That’s what product owners do. If you thought they were always acting on their own great ideas, well, you’re wrong. One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.” 38
“But Eric knows his job is to minimize the amount he builds and still keep people happy” 41
“You’ve already learned the two most important things that make stories work:
Use storytelling with words and pictures to build a shared understanding
Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome” 84
“Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used” 91
“If you’re not getting together to have rich discussions about your stories, then you’re not really using stories” 92
“Story conversations are about working together to arrive at the best solution to a problem we both understand” 94
“It doesn’t need to be written in a template to be considered a story” 102
“For me, the story template works a bit like learning the snowplow. Use it to write the descriptions of your first stories” 103
“There are many different kinds of conversation with different people for every story” 110
“The most important thing here is that all these people are armed with the same picture in their heads: the picture they build while talking together” 123
“It’ll help everyone’s sanity to separate out two concerns. First: did we build what we agreed to build? And then: if it’s what we agreed to build, now that we see it, should we make some changes?” 125
“The difference between what you think people need and what they really need is the realm of product arrogance” 195
“Remember, our goal is to minimize the amount we build (our output) and maximize the benefit we get from doing it (the outcomes and impact).” 196
“Viable means successful for a specific business strategy, target customer, and users.” 197
“This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful” 201
“They didn’t build a full prototype. They did have concerns that their solution would be really usable, and they couldn’t learn that from a comic book. They also had a few technical concerns that would require writing some prototype code to test. But none of that mattered if students didn’t have the problem, and didn’t respond well to their idea.
That smallest possible solution to test is what Lean Startup refers to as a minimum viable product. 214
“The only thing that trumps an executive opinion is cold, hard fact.” 251
Value for money
9/10
Year, Price, Pages, Cover design
2014 by O’Reilly Media; Euro 26,49; 259 pages (278 pages with Acknowledgments, References, Index, About the Author), Paperback
Cover design by Ellie Volckhausen, Illustration by Rebecca Demarest, Interior design by David Futato. Good paper quality and reading experience
5 sentences about the book
Rethink your expectations of this book: it is not a manual on “how to write user story”, but a broad compendium of knowledge about software product management
It is not one-time reading, but a hand-book you reach for again and again to remind yourself of the basic principles
If you have prejudices against O’Reilly publisher, then this book is an opportunity to get rid of them
The narrator guides you with special care. He is whispering secrets to your ear and he is telling funny stories from everyday life. By the very end, you have a feeling that you’ve known Jeff Patton for a very long time. You may want to invite him for drinks and discuss some parts of the book. (The narrator’s voice reminds me of a character in Ridley Scott’s movie — A Good Year (2006). His name is Henry Skinner and he’s an uncle of our protagonist)
A unique book, an extraordinary book in the best sense of the word
What did I learn?
- I understand better what user story mapping is
I know how to organize the workshop based on the conversation to get the big picture and common understanding of what to build
-You will get several hints, useful tips and checklists like 1. Steps how to build a big picture; 2. Six simple steps for story mapping; 3. A checklist of what to talk about during the conversation; 4. Plan to build less; 5. Plan to build on time; 6. Plan to learn faster; etc.
- I consider User Story Mapping as my top 3 books about product management on my list
What was missing?
- The second half of the book talks about the user story mapping in the context of the discovery process, product backlog, backlog refinement, design thinking, product review, product release and retrospective. I had a strong impression that the narration lost tempo. Everything was fine until the author was focused on explaining what user story mapping is and how to use it. I don’t say that’s bad, but I didn’t read the second half with such focus, involvement and speed.
Favourite quotes:
“You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations.” xxv
“If you get nothing else from this book, remember these things:
Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
Stories aren’t the requirements; they���re discussions about solving problems for our organisation, our customers, and our users that lead to agreements on what to build.
Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build ” xliv
“Stories get their name from how they should be used, not what should be written.” 3
“The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding” 4
“At the top of the maps is the backbone, which sometimes has a couple of different levels. You might start with the basic flow of the story, which is one level. But, when it gets really long, it’s useful to go up one more level to summarize things further.” 23
“Every time we do this we find holes. We find things that we thought another team should be taking care of, but it didn’t know.” 25
“Eric is part of a team that took those ideas and ran with them. That’s what product owners do. If you thought they were always acting on their own great ideas, well, you’re wrong. One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.” 38
“But Eric knows his job is to minimize the amount he builds and still keep people happy” 41
“You’ve already learned the two most important things that make stories work:
Use storytelling with words and pictures to build a shared understanding
Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome” 84
“Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used” 91
“If you’re not getting together to have rich discussions about your stories, then you’re not really using stories” 92
“Story conversations are about working together to arrive at the best solution to a problem we both understand” 94
“It doesn’t need to be written in a template to be considered a story” 102
“For me, the story template works a bit like learning the snowplow. Use it to write the descriptions of your first stories” 103
“There are many different kinds of conversation with different people for every story” 110
“The most important thing here is that all these people are armed with the same picture in their heads: the picture they build while talking together” 123
“It’ll help everyone’s sanity to separate out two concerns. First: did we build what we agreed to build? And then: if it’s what we agreed to build, now that we see it, should we make some changes?” 125
“The difference between what you think people need and what they really need is the realm of product arrogance” 195
“Remember, our goal is to minimize the amount we build (our output) and maximize the benefit we get from doing it (the outcomes and impact).” 196
“Viable means successful for a specific business strategy, target customer, and users.” 197
“This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful” 201
“They didn’t build a full prototype. They did have concerns that their solution would be really usable, and they couldn’t learn that from a comic book. They also had a few technical concerns that would require writing some prototype code to test. But none of that mattered if students didn’t have the problem, and didn’t respond well to their idea.
That smallest possible solution to test is what Lean Startup refers to as a minimum viable product. 214
“The only thing that trumps an executive opinion is cold, hard fact.” 251
May 1, 2019
Apesar de a estrutura do livro ser muito confusa (o que quase me fez desistir de lê-lo), o conteúdo é um excelente guia sobre gestão de produtos em um ambiente de desenvolvimento ágil de software. Vai muito além do story mapping em si e explora toda a cadeia de valor de um produto, abordando conceitos como processos e ferramentas de discovery, escrita de histórias, priorização, refinamento, lean e design thinking, aplicados ao fluxo de desenvolvimento (ágil) de software. Os principais pontos negativos são a estrutura confusa dos capítulos e que o autor se repete muito (o livro poderia ter 200 páginas e seria bom da mesma forma).
March 13, 2019
Great book with lots of useful information. I will surely give all the ideas a try in a future project.
However, as going through the book, I felt that some of the notes I was taking started to repeat themselves.
However, as going through the book, I felt that some of the notes I was taking started to repeat themselves.
January 20, 2024
This book requires Agile/Scrum understanding or even practice. Other than that it is a perfect guide for User Story Mapping with practical tasks and explaining every part in a simple way.
October 16, 2017
Book describes how use user story mapping technique in the process of making software from idea to test.
User story mapping is a valuable tool for software development. This often misunderstand technique can help your team stay focus on users and their needs without getting lost in the enthusiasm for individual product features. The main goal of using stories is shared understanding. Story mapping is very simple, but it is not easy!
Who should read this book?
Book could be useful for product managers, project managers, user experiment designers, product owners, business analyst, and agile and lean process coach.
Book weaknesses
The contents of the book do not have a coherent structure.
There are lots of reference to previous chapters and other books and so reading of book is a little hard.
User story mapping is a valuable tool for software development. This often misunderstand technique can help your team stay focus on users and their needs without getting lost in the enthusiasm for individual product features. The main goal of using stories is shared understanding. Story mapping is very simple, but it is not easy!
Who should read this book?
Book could be useful for product managers, project managers, user experiment designers, product owners, business analyst, and agile and lean process coach.
Book weaknesses
The contents of the book do not have a coherent structure.
There are lots of reference to previous chapters and other books and so reading of book is a little hard.
March 5, 2021
I can understand the criticism with the high number of pages, certainly fewer trees could have been felled for this book. Nevertheless, I think it's good that the content goes beyond the pure method and that it doesn’t remain unmentioned where the individual ideas originate from. User Story Mapping itself is a very interesting method and for me it forms the pivot between interviews and personae on the one side and usability tests on the other. A lot of thoughts can also be found in Lean Startup which is not surprising when they write about "our friend Jeff Patton" there.
I find that the relaxed style of writing is very refreshing and see no reason why you can't smile when reading about business.
I find that the relaxed style of writing is very refreshing and see no reason why you can't smile when reading about business.
October 11, 2018
A brilliant book which I cannot recommend enough to people building products.
Yes, it's wordy and repeating the same stuff over and over, but it's utterly useful. It's more of a collection of stories from the trenches about user stories. It'll help you understand that you don't have to reinvent the wheel when it comes to communication & collaboration practices. People have been practicing methods which encourage agility (but not necessarily Agile™) effectively and systematically for quite a few year now.
Yes, it's wordy and repeating the same stuff over and over, but it's utterly useful. It's more of a collection of stories from the trenches about user stories. It'll help you understand that you don't have to reinvent the wheel when it comes to communication & collaboration practices. People have been practicing methods which encourage agility (but not necessarily Agile™) effectively and systematically for quite a few year now.
September 27, 2021
I had this book during a long time on my "to read" list, until finally I started to read it.
All this time I thought it was about creating good user stories and it's not, still the topic looked very good.
But when I continued reading the book I saw a really good concept stretched for 280 pages. It mixes concepts of agile, lean and software iterations with the concept of map the roadmap of your application.
If you find a good blog post about this topic, probably it will have the same content as the whole book.
All this time I thought it was about creating good user stories and it's not, still the topic looked very good.
But when I continued reading the book I saw a really good concept stretched for 280 pages. It mixes concepts of agile, lean and software iterations with the concept of map the roadmap of your application.
If you find a good blog post about this topic, probably it will have the same content as the whole book.
May 23, 2019
Great book with a lot of great quotes/tid bits. Perhaps a little more focused on Product Discovery and Lean Start-up type concepts than the title might suggest, the first few chapters did provide valuable insights on how to do story-mapping itself. It's the kind of book that will deliver different nuggets every time you read it, depending on where you are in your Agile learning journey.
March 22, 2018
I have rarely read a book that explains a concept this well. The theories are all brought to life with relevant case studies, brilliant analogies, and a writing style that reveals the author's passion for delivering software that solves a real problem.
July 17, 2016
Wish I had read this 5 years ago.
May 18, 2017
Good advice but delivery is poor. Lots of repetition that inflates page count
August 19, 2021
Nicely put ideas, but way too verbose.
January 8, 2022
A very necessary reference for the design and development of digital products in these times, I personally use it as a map and guide in relation to the big picture.
It is worth paying attention to the details that the author talks about in each chapter.
Finally, I have loved the approach focused on the end user, which the author clarifies and that should be there every time you want to iterate and/or prioritize the outcomes we want to obtain with the launch of functionalities to the market in a product.
It is worth paying attention to the details that the author talks about in each chapter.
Finally, I have loved the approach focused on the end user, which the author clarifies and that should be there every time you want to iterate and/or prioritize the outcomes we want to obtain with the launch of functionalities to the market in a product.
September 24, 2021
I knew this book is going to be really good when I read "Read this first", which is positioned before Chapter 1. Here, Jeff Patton discusses the nature of documents and does so simply by telling a story about vacation photos to make a point. Brilliant.
The author tells stories, and he does it so well, that I have a feeling that I now mostly need practice to effectively recognise opportunities whilst developing a product. This book would have been really useful when I was learning to develop software by working on hobby projects. But perhaps that time made it possible for me to really appreciate the message of the book.
Thanks to this book, I now see how great the old computer game "Asteroids" is. Yes, that probably sounds nonsensical to you now, but I suspect you'll adopt the same opinion after reading this book.
The author tells stories, and he does it so well, that I have a feeling that I now mostly need practice to effectively recognise opportunities whilst developing a product. This book would have been really useful when I was learning to develop software by working on hobby projects. But perhaps that time made it possible for me to really appreciate the message of the book.
Thanks to this book, I now see how great the old computer game "Asteroids" is. Yes, that probably sounds nonsensical to you now, but I suspect you'll adopt the same opinion after reading this book.
March 26, 2017
Inspiring and up to the point
Lots of examples, practical insights, it is clear the author spent a lot of time working on a software at different roles. It is written in a very friendly tone, just like you're having a conversation with a more experienced colleague. I've already tried several ideas from the book at work and plan to grab more of them.
Lots of examples, practical insights, it is clear the author spent a lot of time working on a software at different roles. It is written in a very friendly tone, just like you're having a conversation with a more experienced colleague. I've already tried several ideas from the book at work and plan to grab more of them.
May 4, 2021
Can highly recommend to anyone having had bad experience with user stories (I sure have). This book should clear up what probably went wrong, and how to use stories better. Spoiler: it's all about people talking about stories, not just writing, and passing them along.
January 11, 2021
A must-read for any Product Manager or facilitator or anyone involved in delivering a product.
June 8, 2022
I would recommend this book to product managers, Senior Developers, engineering managers, and their coaches.
This book narrows in on user stories and connects to the process around them.
It is not about how stories shall be written. But how to use them, what's the purpose and how to make the most of them.
A couple of key points
* It's not about what's written on them it's about the context they provide.
* "Stories are Actually Like Asteroids" - Ie breaks them down into smaller stories but not all at once.
* It is all about the user and discovering what is needed.
This book narrows in on user stories and connects to the process around them.
It is not about how stories shall be written. But how to use them, what's the purpose and how to make the most of them.
A couple of key points
* It's not about what's written on them it's about the context they provide.
* "Stories are Actually Like Asteroids" - Ie breaks them down into smaller stories but not all at once.
* It is all about the user and discovering what is needed.
Displaying 1 - 30 of 326 reviews