I’ve been reading User Story Mapping by Jeff Patton. There were some bits that I wanted to jot down because they felt important to remember, and I thought I’d capture them in the form of a post in case it tickles the curiosity of anyone else.
This is not an exhaustive list of interesting stuff from the book. Just the bits that I’ve initially gravitated toward.
“Shared documents aren’t shared understanding.”
Page xxii, Read this first
As someone who generally adopts an approach of writing things down and sharing them more widely in the hopes of improving understanding, this one was a bit of a shot to the gut. But I know it to be true in my bones! Yes, you can write summarised notes from a conversation, or even share visual maps. But something is always lost from not being part of the process of putting it together.
“The real goal of using stories is shared understanding.”
Page xxxiv, Read this first
And in a variation on the above theme, having the user story is of course useful, but it’s the process of working together to define it that is an important part of the work in generating shared understanding. They are the bridge to a useful conversation. They begin to lose their usefulness when separated from the people who created them.
“Scope doesn’t creep. Understanding grows.”
Page 26, Chapter 2 – Plan to build less
I like this reframing of scope creep. Often portrayed as a thing that happens when people keep shoving non-essential things into a peice of work that will ultimately cause additional cost and delay. But actually, it could be that your understanding has improved in the doing of the work.
“Focus on what you hope will happen outside the system to make decisions about what’s inside the system.”
Page 27, Chapter 2 – Plan to build less
As a firm believer that modern organisations start looking at their products or services outside in, this is another way of articulating that you don’t start with the system and how it works, before you understand who’s involved and what they are trying to achieve.
“There’s always more to build than you have people, time and money for. Always.”
Page 21, Chapter 2 – Plan to build less
This is another one that I feel in my bones! Traditionally, the technology bit of the org is often a shared central service. The work is never done if you rightly presume that all service delivery should be subject to continuous improvement. Rather than being a depressing statement, I interpret this as actually quite freeing. It’s acceptable that you can’t be everywhere, doing everything for everyone. There will always be a hard limit in terms of where you can direct your time and energy to deliver value to the organisation and it’s customers. Which means chosing what to do, and by association what not to do, and figuring out how you can maximise outcomes with minimum input. That is, of course, easier said than done.
“Map only what you need to support your conversation.”
Page 52, Chapter 4 – Plan to finish on time
As a recovering perfectionist, this is a good reminder for me, where I feel like anything less than mapping EVERYTHING somehow compromises the approach and the outcome where the change could actually be quite small Assuming that everything has to be mapped perfectly before you can tackle something quite small and achievable can end up generating inertia.
The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.
Page 90, Chapter 6: The real story about stories
Minimal explanation needed on this one. Just seems like common sense. But when you think about the ways we often put boundaries or limitations in the way of these two groups meeting, it does warrant deeper introspection about how to make this happen.
Try using stories to drive the making of anything, whether it’s software or not.
Page 128, Chapter 9: The card is just the beginning
This is a good reminder that you don’t need to build the software before you can start learning. Cheap prototypes are equally useful in learning if you’re on the right track. This also made me think about how user stories could be applied to other non-software endeavours. There will always be non-digital bits of services. I feel this is often more commonly referred to as user needs in service design parlance. A similar concept, but coming from the design rather then tech community.