TL;DR
The traditional Product Backlog is a stack-ranked 1-n list of things to do. Hopefully the items in the backlog represent user stories and valuable outcomes rather than a list of tasks. From this list, the team pulls off work items and then goes to work developing product. But it’s hard to understand the Big Picture from this list. What are we really trying to create? Where are the logical release groups that would deliver the greatest impact?
Author Jeff Patton describes what User Stories are meant to be and how they are meant to be used. When looked at as a whole, the Product Backlog should tell a story. But how?
By using User Story Mapping, where you map out the highest value User Activities in a 2-D map, develop that, and only then add details later (if at all) you reduce the time to feedback. You reduce the time to value. You build a “walking skeleton” of the entire system to understand how the entire system will work. You can identify gaps in the customer’s journey to complete their activities and receive value. You can map and develop only parts of the system by exploring specific types of users (using personas).
This book teaches you to focus on what’s most important to your customers by developing the 2-D backlog from their perspective, in their language. It’s customer-centric rather than yet another WBS system implementation plan disguised as user stories.
Coach Dave says this should be considered a must read for all Scrum Masters, Agile Coaches and Product Owners/Managers.
KEY LEARNINGS:
- Written requirements are a terrible way to convey meaning and intent. They are easily misunderstood. See cakewrecks.com for specific examples.
- Story Maps enable you to see the Big Picture. It’s easy to tell a story from a map, not so easy from a 1-n list traditional backlog.
- User Stories are meant to be told rather than written. Think of user stories as vacation photos which will later allow the team to recall the conversations describing what’s in the photo and the backstory of the photo. Written words alone can never convey that level of shared understanding.
- Use Personas to understand different parts of the system and how those users will receive value.
- Focus on building only the most important user activities across the entire system first. Get feedback on that to understand details and nuance.
ADDITIONAL THOUGHTS:
A breakthrough technique in developing a shared understanding of the product goals and most important aspects of the system to create first. Telling the story of the product, and the impact to be delivered, has never been easier. Focus on developing release, learning and development plans. Learn techniques to reduce the amount of work done to receive value.
