I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Jeff Patton (@jeffpatton) was billed to present a “fast paced workshop [where] you’ll learn the concepts of story mapping by building a map collaboratively with others”. He shared lots of great insights about stories but (I felt) really only touched on Story Mapping briefly near the end of the time. Still, I collected some good notes about stories that made me re-think a few things…

He started by showing this great list of wrong things he used to think about stories. 

1. Stories are [a] way to document requirements in Agile processes.
2. Good stories are small.
3. Good product backlogs are prioritized lists of stories
4. Each story we build is valuable to customers and users

He explained how Kent Beck started the whole story thing to rail against the modus operandi at the time: “Stop exchanging documents. Tell me your story.”

What is really needed, in order to develop the right software, is a shared understanding. The story card doesn’t do that. The whole team needs to be involved in hearing the story and having the conversation. We need to externalise the conversation into paper prototypes and diagrams to ensure we’re all thinking the same thing. The story card is just a memento that assists people in recalling the conversations. Our job in software development is NOT to build software, or to “solve people’s problems”, but to change the world. We need to be focussing on the outcomes, the impact, of what we do. We aren’t trying to maximise output, but minimise output while maximising outcomes and impact.

The word “requirement” should not be used in agile practice – it focuses on the outputs and shuts down conversations. Stories tell a story that focus on the outcome and gets people excited. Stories are a different way to work, not a different way to write requirements.

Story mapping is about telling the whole story of the big picture. Story maps usually get huge – way too huge to schedule and execute. You’ll need to slice the work into releases that are valuable, and centred around defined outcomes.

I had a quick chat with Jeff after his talk because it wasn’t clear to me who was responsible for developing story maps. He said that, in an organisation that has dedicated Product Owners or Product Managers, it is definitely their role to lead the development of the story map and guide its evolution, though the process is collaborative.

Want to learn more?

Image credits:

Slide content is © Jeff Patton & Associates. Licensed under Creative Commons BY-NC-SA.