More on this book
Community
Kindle Notes & Highlights
The development team includes testers, UI designers, technical writers, or whatever people and skills are necessary to create the software, so the tasks aren’t all about coding.
When you tell stories about software, and collect a list of story names as you do, you tell the story imagining the software you’ll have in the end. And you don’t just imagine the software — you think and talk about who uses it and why.
In Chapter 7, I pointed out that when the solution we’re thinking of is too expensive, we need to step back and really look at the problems we’re trying to solve, and the outcomes we’re trying to achieve.
If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
So, if teams use the simple breakdown structure that seems logical, they get tempted to break software down into weeks of frontend development, weeks of business logic development, and so on. When we use that strategy, it takes a long time before we can “taste any cake,” so to speak. So don’t do that.
You’ll know that as you combine these pieces of software, you’ll have to do a bit of rewriting and adjusting of each piece to combine them.
One of the biggest is to avoid the risks involved with not seeing, using, or “tasting” the software too late. You’re breaking big things down to small, evaluable parts so you can learn sooner.
you can deliver “half a baked cake, not a half-baked cake.”
A right-sized story from a user’s perspective is one that fulfills a need.
A right-sized story from a development team’s perspective is one that takes just a few days to build and test.
A right-sized story from a business perspective is one that helps a business achieve a business outcome.
Those big stories contain lots of smaller stories, which in turn contain lots more smaller stories. Depending on who you’re talking to, you might have to “roll up” your conversation to a higher level.
Conversations are one of the best tools for breaking down big stories.
The wiggliness about what’s in a story and how big it should be is intentional. It gives us the flexibility we need to use this simple idea throughout the development cycle.
Now I’ll be honest with you that it took me years to get comfortable referring to the important stuff we were building as stories, but I understand now why they’re called that.
epics are big stories that may be the right size from a business, customer, or user perspective — just not from a development perspective.
keep the epic around because you’ll need to speak to people about it, and all the detailed stories it broke down into.
You might simply refer to the theme by what it really is: your next release, the feature, or the stories relevant to a particular type of user.
opportunity backlog.
there’s always too much to build, and killing a mediocre opportunity before it wastes too much of everyone’s time should be celebrated.
Story mapping can help you understand how people work today, and then map your ideas about how things will change for them after your solution is created.
No matter how hard you try, even your last best story conversations won’t have predicted everything you’ll learn once you start to build. Plan to have lots of frequent, ad hoc story conversations every day. Bring up the need for them in your daily standup meetings.
Use conversations as you build to fill in details and give feedback on what’s being built.
Frequently reflect on product quality, your plans, and the way you work.
Usually enough means a whole screen, or a flow of screens, that allows users to complete a task or reach a meaningful goal.
Use metrics and face time with users to really learn if your target outcomes were met.
Requiring a single product owner to write all of the stories and be present for all story conversations doesn’t work.
the product owner is a critical leader. He keeps the product and whole team focused on moving the same direction.
You’ve used software products like this: the product with more features than anyone can count, and where your biggest problem is finding the feature or remembering how to use it.
the responsibility of a product manager to identify a product that’s valuable, usable, and feasible.
to really identify the solution in the center of that sweet spot will take collaboration between people who understand our business, our customers, our users, and the technology we use
the most effective organizations use small, cross-functional discovery teams that work together to find that right solution.
A small, cross-functional team led by a product owner orchestrates product discovery work.
Support product owners with a core team that includes user experience, design expertise, and technical expertise.
requires top-notch communication and facilitation skills,
The best of these leaders focus on helping everyone take ownership.
in the client-vendor anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins.
a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships much more like a good doctor-patient relationship, and much less like a waiter-diner’s.
When acting as product owner for other stakeholders’ ideas, take on the role of a producer who helps them succeed.
Story mapping is just one of the ways to help us break big things down while keeping the focus of the conversation on the people using your product and what makes them successful.
shift toward working with people more effectively, and together focusing on solving real problems with the products you create.
It’s just that it’s a bad idea to consider every idea as something we need to include in our product, because you know that there isn’t enough time and people to build all that stuff.
We’ll need to talk about how they solve their problems today by using manual tools, our competitors’ products, or worse, our product that’s causing them pain today.
It’s a good time to discuss why it benefits our organization to build software for these users. Solving users’ problems usually isn’t enough. We also need to consider the ultimate return on this software investment and whether this investment is aligned with our current business strategy.
discuss in general terms how we imagine it’ll benefit our organization if we build it.
opportunity backlog. We aren’t sure yet if we should build them, or at least we shouldn’t be.
If you still can’t make a go or no-go decision, you can always put it back into the opportunity backlog to discuss later. That’s called procrastination, and I do it a lot.
we’re not looking at starting a new business or launching a new product. We’re often looking at adding a next important feature to the product we have.
User Metrics What user behaviors can you measure that will indicate that they adopt, use, and place value in your solution?
What business performance metrics will be affected by the success of this solution? These metrics are often a consequence of users changing their behavior.
