User Story Mapping – Reduce the Duplicate Stories, Improve Visibility
Just finished reading User Story Mapping. Although the concept isn’t new, the book offers a good read, which will hopefully improving the uptake of the practice by team in the construction and management of backlogs. Few take aways:
- Page 3 – “Stories get their names from how they should be used, not what should be written”
- Page 23 – “Map for a product release across multiple teams to visualise dependencies”. For me, “dependencies” is the keyword. Numerous times teams have failed to visualise dependencies of stories ending with discovery in game planning sessions and failed iterations😦
- Page 25 – Mapping helps you spot holes in your story – another classic failure of backlogs😦
- Page 26 – “Scope doesn’t creep, understanding grows” – a classic and true saying.
- Page 27 and 28 – Minimum Viable Product (MVP) and releases. Stakeholders need to get real on what is achievable in a MVP, especially given the comment on xli, “There’s always more to build than we have time or resources to build – always”
- Page 33 – MVP release that successfully achieves its desired outcomes
- Page 53 – “The best estimates come from developers who really understand what they’re estimating” – obvious, but often overlooked in my view
- Page 83 – Six Simple steps to Story Mapping.
- Page 99 – The story template – hopefully everyone is already using this.
- Page 162 – The Client-Vendor Anti-Pattern – classic