Member-only story
What I Learned from User Story Mapping (and how most people do Agile wrong)
Some time ago, I came across User Story Mapping by Jeff Patton while looking for books about customer discovery. So I ordered a copy, and while it wasn’t exactly a light read, I finally made it all the way through and figured I would share some of what I learned. The topic of user stories is particularly relevant because Agile just turned 20 this year, and has been declared a failed experiment by at least one person. I personally think it’s a little early to declare that, as I can see a lot of good things about Agile as Patton describes it.
In a nutshell, User Story Mapping discusses how user stories will help you to build the right products for the right customers. I guarantee that everyone who has worked on a product development team has seen a “story” — it basically tells you what you are supposed to build, phrased from the user perspective. An example would be, “the user can view customer retention over a 30-day period.” If you are assigned that story, your goal is to build something that enables the user to do just that.
The problem with stories
The big problem with stories is that most teams use them in completely the wrong way, seeing the stories as requirements that are dictated to the development team. Often the stories are backed up by pages of supporting documentation in Confluence or Google Docs, which no one actually reads all the way through. The designer probably skims the document five minutes before the sprint planning meeting, and the engineer figures out what to build by looking at the design mocks.
As we all know, having a lot of documentation doesn’t necessarily guarantee that you have shared understanding. A lot of projects have what Patton calls “non-functional requirements.” He gives as an example the site cakewrecks.com, which illustrates that shared documents don’t necessarily lead to shared understanding. Patton’s primary hypothesis is that stories themselves are only useful as the starting point for a discussion that leads to shared understanding. The following picture is an example of what happens when you don’t have shared understanding.
When you have a “functional” set of stories, they should be able to tell the story of how users will interact with…
