More on this book
Community
Kindle Notes & Highlights
Story mapping is a technique that provides the big picture that a pile of stories so often misses.
A big picture helps communicate effectively with users, it helps everyone involved avoid building unnecessary features, and it provides an orientation for a coherent user experience.
A programmer who understands story mapping can better see the broader user context and can participate in framing the software—leading to a better job.
But when the two strains of practice—design and development—collaborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it.
Practitioners in each of the two fields are strong, capable, and internally well disciplined, yet they share a single, common weakness. It is really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms. The two sister disciplines lack a common tongue. And that junction between the two disciplines is precisely where Jeff Patton lives.
we have seen good designs, well documented, given to developers—Agile or not—who manage to kill the essence of the design in the process of implementation.
By mapping out the user’s stories, the design retains its narrative structure yet can still be deconstructed for effective implementation. The designer’s story, which is a formalized version of
the user’s story, remains intact throughout the development.
The only way we are going to build big software that is not a Frankenstein monster is by learning how to integrate the disciplines of software design and development. Nobody knows how to do that better than Jeff Patton.
Good teams have a compelling product vision that they pursue with a missionary-like passion.
Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems.
Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customer...
This highlight has been truncated due to consecutive passage length restrictions.
Good teams are skilled in the many techniques to rapidly try out product ideas to determine which o...
This highlight has been truncated due to consecutive passage length restrictions.
story mapping.
Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.
“sandwich into a banquet.”
I like making things. What motivates me is the joy I get from creating a piece of software and seeing people use it and benefit from it.
Stories and story maps are such a good idea. They’ve benefited so many people. They’ve made their lives better, and the products they build better. But while some people’s lives are getting better, there are more people struggling with stories than ever before. I want to help stop that.
You’ll learn how to think of the big picture, how to plan and estimate in the large (and in the small), and how to have productive conversations about what users are trying to accomplish, as well as what a good piece of software needs to do to help them.
If you’ve been struggling to get from the vision you’re imagining to the details your teams can build, story maps will help. If you’ve been struggling to help others imagine the experience of—and empathize with—the users of your product, story mapping will help. If you’ve been struggling to figure out how to incorporate good UX and product design practice, this book will help. If you’ve been working to incorporate Lean Startup–style experimentation in the way you work, this book will help.
Product owners, business analysts, and project managers in information technology (IT) organizations should read this book to help them bridge the gap between
their internal users, stakeholders, and developers. If you’ve been struggling to convince lots of stakeholders in your company to get on the same page, then story maps will help. If you’ve been struggling to h...
This highlight has been truncated due to consecutive passage length restrictions.
When using Agile processes, we often look to roles like product owners or business analysts to steer a lot of the work with stories, but effective use of stories requires that everyone get the basics. When people don’t understand the basics, you hear complaints that “stories aren’t well written” or that they’re “too big,” or that they “don’t have enough detail.” This book will help, but not in the way you think. 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.
The goal of using stories isn’t to write better stories. The goal of product development isn’t to make products.
Shared documents aren’t shared understanding.
Shared understanding is when we both understand what the other person is imagining and why.
If we give each other time to explain our thoughts with words and pictures, we build shared understanding.
externalizing our ideas is so important.
We can redraw sketches or move sticky notes around, and the cool thing is that we’re really moving ideas around. What we’re really doing is evolving our shared understanding. That’s super-hard with just words alone.
And, sadly, it’s intangible. You can’t see or touch “shared understanding,” but you can feel it.
Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding. The real goal of using stories is shared understanding.
Stories in Agile development get their name from how they should be used, not what you write down. If you’re using stories in development and you’re not talking together using words and pictures, you’re doing it wrong.
will. Even if she says she gets it, don’t believe her. Get together and use the document to tell a story the same way I used my vacation photo to tell you my story.
It takes talking and sketching and writing and working with sticky notes or index cards. It’s pointing to documents we brought into the conversation and marking them up with highlighter and scribbled notes. It’s interactive and high energy. If you’re sitting at a conference table while a single person types what you say into a story management system, you’re probably doing it wrong.
To help remember, photograph and shoot short videos of the results of your conversations.
The truth is, your job is to change the world.
Every great idea you turn into a product solution changes
the world in some small, or not-so-small, way for the people who use it. In fact, if it doesn’t, you’ve failed.
When you take a look at what they’re doing—and the tools they use and how they’re doing things—you’re going to come up with ideas, and the ideas might be for:
Entirely new products you can build Features to add to an existing product Enhancements to products that you’ve built
requirements are just another name for the ideas we have that would help people.
They’re happy because when they use the software, or the website, or the mobile app, or whatever you’ve built, they do things differently—and that’s what makes them happy.
Now, the truth is that you can’t please everyone all of the time. Your mother should have told you that. Some people will be happier than others with whatever it is that you produce, and some might still be unhappy no matter how hard you’ve worked and how amazing your product might be.
Everything between the idea and the delivery is called output.
But, while it’s necessary, the output isn’t the real point; it’s not the output that we really wanted. It’s what comes after as a result of that. It’s called outcome. Outcome is what happens when things come out—that’s why it’s called that—and it’s difficult because we don’t get to measure outcome until things do come out. And we don’t measure outcome by the number of features delivered, or what people have the capability to now do. We measure what people actually do differently to reach their goals as a consequence of what you’ve built, and most important, whether you’ve made their lives
...more
You’ve put something in it that changes the way people can reach their goals, and when they use it, the world is different for them.
If you remember, your goal isn’t to just build a new product or feature. When you have conversations about that feature, you’ll talk about
who it’s for, what they do now, and how things will change for them later. That positive change later is really why they’d want it. Good story conversat...
This highlight has been truncated due to consecutive passage length restrictions.
To fix this, they may have ideas to focus on specific customers or users and to make or improve the software products they’re using. You see, it ultimately is about people, because:
Your company can’t get what it wants unless your customers and users get something they want.
