| | 1 | = User Story Mapping |
| | 2 | **Author**: Jeff Patton[[br]] |
| | 3 | Feb 07 2017 |
| | 4 | |
| | 5 | [[Image(htdocs:images/books/user-story-mapping.jpg, align=center, nolink)]] |
| | 6 | |
| | 7 | [[PageOutline(2-5, Contents, inline, unnumbered)]] |
| | 8 | |
| | 9 | == Review |
| | 10 | === Verdict: [[Image(htdocs:icons/green-up-arrow.png, inline, nolink)]] **Recommended** |
| | 11 | Took me about 9 hours to read. It's a bit wordy and has some repetition, but I was able to look past that due to the quality of information. I possibly have a slight bias towards the techniques outlined because I've used them with some variations both at Expedia and at my own company, but I see that more as validation that the user story mapping works better than the traditional software requirements. This is particularly true for products whose form and function fluctuate because end-users themselves aren't aware of what they need (which is very different from what they think they want) and don't know how software can make their lives better (simpler, enable them to get more done, etc). |
| | 12 | |
| | 13 | === The Good |
| | 14 | * In-depth coverage of user story mapping. |
| | 15 | * Good use cases with sufficient detail which keep the reader engaged. |
| | 16 | * Covers how things can go wrong / off-track if the basics aren't at the forefront of your mind. |
| | 17 | * Good tips on how to get people out of the traditional requirements gathering and spec writing mindset. |
| | 18 | * Clear six-step process to story mapping, viz. frame the problem, map the big picture, explore, slice out strategies for release, learning and development. |
| | 19 | * Possibly a book to keep on your shelf if this is your primary job function. |
| | 20 | * References to books and publications for related topics. |
| | 21 | * I liked the analogy of using the classic Asteroids game (by Atari) to break down large user stories into smaller ones, but not all of them at once - too many small user stories becomes like the huge number of tiny asteroid chunks on-screen if you shoot at all the large asteroid. |
| | 22 | * Sage advice that you're not done once you release - there's work to determine if what you built is right, to figure out improvements and to create plans to work on the significant ones. |
| | 23 | * Stand-out message: Deliver half a baked cake, not a half-baked cake. |
| | 24 | |
| | 25 | === The Bad |
| | 26 | * Harping about building shared understanding. Yes, it central to user story mapping and it's good to hear cautionary tales and gotchas, but it gets old after the first couple of times. |
| | 27 | * Some analogies / exercises are a bit worn out, though I probably feel that way reading about them and they actually work well in practice. |
| | 28 | * The goldfish bowl technique to limit active participants in discussions doesn't work in my experience. It's better to exclude people that aren't necessary and fill them in later, regardless of how they may feel about it. And yes, making the determination about who is necessary is a judgement call. |
| | 29 | |
| | 30 | === The Ugly |
| | 31 | * Low resolution images in the Kindle version which you must zoom into (feature not available on the Kindle desktop app, btw), squint your eyes to be able to make anything out. |
