More on this book
Community
Kindle Notes & Highlights
by
Jeff Patton
Read between
May 9 - July 9, 2020
the more frequently you measure, the better you get at predicting.
By slicing large things into small things, we get more opportunities to measure.
worked together with developers they trust early on to get an initial time estimate. They treat it as a budget.
the biggest driver for missing dates was unplanned work, mostly due to uncertainties and realized risks.
since uncertainty and risk weren’t previously reflected in the story map, the map didn’t depict the actual amount of work (including learning) to be done.
Project size and complexity were better represented, because they were composed of both the original known stories as well as the new “unknown stories”—the risks, or the knowledge the team needed to gain to confidently move ahead with the known stories.
increasing the frequency of story map creation and adding new Risk Stories are powerful ways to make your maps better reflect reality.
Great art is never finished, only abandoned. — Leonardo da Vinci
Use iterative thinking to evaluate and make changes to what you’ve already made.
From a process perspective, it means to repeat the same process over and over.
learning. Use incremental thinking to make additions.
Write Out Your Story a Step at a Time
User tasks are the basic building blocks of a story map.
some people just write a lot more details than others.
Tasks are like rocks. If you take a big rock and hit it with a hammer, it’ll break into a bunch of smaller ones. Those smaller rocks are still rocks. It’s the same thing with tasks.
Use the goal-level concept to help you aggregate small tasks or decompose large tasks.
2. Organize Your Story
organize your tasks in a left-to-right flow with what you did first on the left, and what you did later on the right.
left-to-right order the narrative flow, which is a fancy way of saying “storytelling order.”
Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.
3. Explore Alternative Stories
Details, alternatives, variations, and exceptions fill in the body of a map.
4. Distill Your Map to Make a Backbone
Activities organize a bunch of tasks done by similar people at similar times in order to reach a particular goal.
Activities aggregate tasks directed at a common goal.
Activities and high-level tasks form the backbone of a story map.
Slice Out Tasks That Help You Reach a Specific Outcome
Use slices to identify all the tasks and details relevant to a specific outcome.
Tasks are short verb phrases that describe what people do. Tasks have different goal levels. Tasks in a map are arranged in a left-to-right narrative flow. The depth of a map contains variations and alternative tasks. Tasks are organized by activities across the top of the map. Activities form the backbone of the map. You can slice the map to identify the tasks you’ll need to reach a specific outcome.
It’s a Now Map, Not a Later Map
One of the cool things about “now story maps” is that you can build them to better understand how people work today.
Pains Things that don’t work, parts people hate
Joys or rewards The fun things, the things that make it worth doing
Questions Why do people do this? What’s going ...
This highlight has been truncated due to consecutive passage length restrictions.
Ideas Things people could do, or that we could build that would take away pain, or ...
This highlight has been truncated due to consecutive passage length restrictions.
This will be really hard if you don’t know exactly who your user is, what she’s trying to accomplish, or how she goes about it.
Frame the problem. Who is it for, and why are we building it?
Map the big picture. Focus on breadth, not depth.
Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can (and likely will) go wrong.
Slice out a release strategy. Remember: there’s always too much to build.
Slice out a learning strategy. You may have identified what you think is a minimum viable solution, but remember that it’s a hypothesis until you prove otherwise.
Slice out a development strategy. If you’ve sliced away everything you don’t need to deliver, you’ll be left with what you do need.
Focus on building things early that help you learn to spot technical issues and development risks sooner.
Use storytelling with words and pictures to build 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.
we typically start with a product vision exercise such as the well-known Elevator Pitch or the Cover Story[
This shows whether the team has a common understanding about the general direction, or whether they might need to invest in some additional research
look at the typical users of the product.
user roles or personas should result from the user research phase.
We next use a three-tier approach to defining user stories: (1) starting with high-level usage steps, these are broken down into (2) finer activities per user role, which in turn are broken down into (3) concrete user stories in the format “as <role>, I want <functionality>, so that <value
