I own this book and took these notes to further my own learning. Taking notes, publishing them and re-reading them allow me to flatten my forgetting curve. If you enjoy these notes, I highly encourage you to do the same, buy this book here and take your own notes.
Introduction
- Shared documents are not shared understanding, the goal of user stories is to overcome this “telephone game” issue
- There is a difference bwn output and outcome in software development. Output is what is delivered and an agile team usually tracks the velocity to speed-up the rate of output. Outcome is what happens after this Output. We measure the difference of actions of our users and if we made their life easier
- In PM the Goal is to minimize output and maximize outcome
- Stories are not requirements, they are discussions about solving problems for our customers and business
Summary
- The Big Picture
- Story mapping is all about breaking down big stories into small ones
- Its all about Talk and Doc + Think, Write, Explain and Place
- Writes stories in card, describe customers, then place them in a board, tell the stories, map them, create diagram
- The goal of mapping is to find missing points in the story
- Plan to build less
- There will be always more to build than there are people, money or time
- Slice out the map with on top the outcome desired and then 3 slicing releases (80-20 rules)
- Doing incremental releases will allow you to create MVP release, validate learning and prioritize things that will have the bigger impact on outcome
- Don't prioritize feature but prioritize outcome
- “The minimum viable product (or solution) is the smallest product (or solution) release that successfully achieves its desired outcomes.”
- Plan to learn faster
- Find first the problem and validate if it's a real problem
- Prototype your solution and test it to real users to see if its viable. Iterate until it's viable. Don't rush into customers’ demand but find the minimum build that will answer to the problem
- Broken release strategy is all about breaking the value delivered, each release should deliver value and a usable product
- A broken release strategy is not breaking the product into several parts
- Never forget that it's really difficult to get the same outcome from all users. Stay focus on your target users and the outcome you want to deliver to them specifically
- Product Discovery: learning if we are building the right thing
- Plan to finish on time
- Best estimation comes from developers, story points. The more you will practice this exercise the better you will be in estimation
- Chunk tickets, to reduce uncertainty (unknow-unknown) and improve estimation
- “Great art is never finished, only abandoned” — Leonardo da Vinci
- Play with iteration and incremental change once you release something
- You already know how
- Story maps is built with user tasks from left to right like a narrative story
- Explore alternative stories, use “what about”
- Tasks are short verb phrases that describe what people do. Tasks have different goal levels.
- You can slice the map to identify the tasks you’ll need to reach a specific outcome.
- 6 steps of story mapping: 1) frame the problem, 2)map the big picture (80-20), 3) Explore, refine and challenge your map, 4) slice out a release strategy, 5)slice out a learning strategy, 6) slice out a development strategy
- The real story about stories
- The best solutions come from the collaboration between the persons with the problem to solve and the people who can solve the problem
- The goal with story is to generate energy, interest and vision
- 3 C: 1)Cards: write a lot of cards describing the product, 2) conversation: discuss and gather the card, 3) confirmation: agreement on acceptance criteria
- Telling better stories
- As a [type of user] I want to [do something] So that I can [get some benefit]
- who, what, why
- Use this simple story to introduce the conversation
- Do pre-grooming session with small groups for more efficient backlog grooming session
- Summarize with chart/keyword/table, etc. on a board the conversation, take a picture of it and document it in the ticket
- Its not All on the card
- The card is just a way to remember and identify the conversation that happened
- The card should just provide enough information to remember the conversation
- Take a picture + document
- The card is just the beginning
- The 5 Cs? 1.construction,2conversation,3.confirmation,4.construction,5.consequences(evaluate results)
- Always construct with a clear picture in your head
- Focus on arming people with the same picture in their head
- After building, evaluate the user experience, the functional quality (AC ?), code quality
- Bake stories like cake
- If a solution seems too expensive, always go back to the goal and problem to consider alternative solutions
- Break solutions into smaller parts allowing you to evaluate and progress sooner
- Instead of looking for a big cake that you can sell, look for small cupcakes. Remember that if the big cake is not good, it's over. On the contrary with cupcakes you diversify the risk.
- “Don't taste your software too late” + “you can deliver half a baked cake, not half baked cake”
- Rock Breaking
- The size of s story is the one that fulfill a user need, that takes a few days to build and test and that helps a business to achieve a business outcome
- Discussions are the best tools for breaking down big stories
- Epic/Feature = Big story » conversations » use case / user task = smaller stories » more conversations » right sized stories = even smaller stories
- Epic is a story that expect to be large and that we know needs to be broken down. Epic is mostly right sized for business and customers need but not from a development perspective
- Look for the minimum viable solution once you agree the problem is worth solving
- Learn by testing chunks of working software with customers and users
- Keep the progress and quality visible to stakeholders inside your organization
- Always, always evaluate after release: 1) data, 2) observations, 3) insights, 4) opportunities
- Evaluate with metrics + interviews to really learn if your target outcomes were met
- Rock Breakers
- Avoid bottlenecks in your agile process by making everybody responsible of writing user stories
- Product discovery team: PO, Senior Eng., UX designer
- Solutions often come from the Eng. supplied with insights about the business problem and users’ problems
- Start with opportunities
- “Opportunity” <-> ideas we think may solve a problem
- Move the opportunity to deeper discovery discussion before building it
- Trash any opportunities that don't offer much hope of creating outcomes you hope for
- Map the journey of a user to find new ideas first, having a clear vision will ease the ideation process
- Using discovery to build shared understanding
- Discovery is not about building but about learning what we could build
- 1)what problems are we really solving, 2) what solutions could be valuable to both our customers and business 3) what does a usable solution looks like 4)what's feasible to build
- Understand you users, create lightweight personas to share understanding and empathy to the team
- Design studio recipe: 1. invite people 2. describe the problem 3.share examples and inspiration 4.everyone sketch 5. in small groups share ideas 6.ask each group to consolidate their best ideas 7.ask each group to share their best ideas, discuss 8.gather up the sketches and ideas
- Play “what about” after imagining a solution, what's going on underneath the user interface
- Last step of discovery is to minimize and plan. In doubt think that there's always too much
- Viable = successful for a specific business strategy and target users
- Prioritize specific business goals, customers before prioritizing features
- Use business strategy to chose target users, use their goals & activities to choose features
- Using discovery for validated learning
- Don't expect your minimal viable solution to be successful, we are wrong most of the time
- 20% big success, 60% little or no impact and 20% failure
- In order to maximize success, embrace design thinking (empathize, focus, ideate, prototype, test)
- Talk directly to users and experience the challenge you're helping them with firsthand
- Focus on one or a few problems, state them specifically
- Search multiple possible solutions to the users problems
- Build simple but viable prototypes to explore the best solutions
- Get the solution in front of the users, don't expect to be a success directly. Iterate and improve them
- What you should not do: start without clearly defining the target user and the business needs (hard to prioritize and hard to tell if the solution is good or not), spend to much time researching and making sense of what you learned. Never talk to people. Try to solve a lot of problem instead of focusing on ONE specific problem. Only ask designers to contribute on solutions ideas. Not considering other solutions. Not thinking about the cost.
- Start by guessing, with assumption, then test, learn and iterate
- Refine, define, and build
- Segment your release backlog into stories
- Do a story workshop to break down stories (send the story ahead, let persons opt-in if they want to participate, keep it small to stay productive, include the right persons)
- Board - write the original story, then create 3 layers with smaller stories: 1) what's good enough to get things working, 2) what would make it better, 3) what's the best version we can imagine
- Display this board and show the user stories status (done, in progress, planned)
- Stories are like asteroids
- Break down stories progressively so you can release value and avoid backlog filled with lots of tiny stories
- Bundle small stories to clean up you backlog, cluster ideas that seem similar into a bigger story: easier to manager and more clear
- Learn from everything you build
- Before doing a product review with all business stakeholders, do a workshop to discuss with the team only: product quality (stories to improve, discuss quality of UX, discuss code quality, testing quality), plan (what is done, what was the velocity), process (what changes were tried from last cycle, did they work ? what to change?, what worked, what did not)
- Secret = bring food
- After this, do a review with all stakeholders and share discussion of the team. Recipes: review discovery work (opportunities, users problems, prototypes, experiments), review delivery work (before showing the solution explain the targets users and the problem, share the progress)
- Important to remember: 1) improvements made after release are the most valuable 2) we are rarely happy after a product release because we know all the things we couldn't include…. GREAT ART IS NEVER FINISHED, ONLY ABANDONED