I am on a quest to continuously improve my understanding of software development, particularly as it applies to agile development practices. I started it by reading one of the classics on software development, The Mythical Man Month, which I found very informative. While good, I wanted something that would help me understand the concepts behind agile software development. I read a couple of books on creating user stories a few months ago, but I still felt like I was missing critical pieces to the puzzle. Then I read User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton.

There was something in the way Patton described the process of defining a product and translating it into user stories that hit home with me. I found the book to be very practical with numerous real life examples. In other words, Jeff’s teachings aren’t based on theoretical concepts but are taken from actual projects that he has been involved in. It provides credibility to the frameworks and methodologies he presents. It helped me to see how they worked and how they could be applied to projects that I’m working on (or have worked on in the past). I came away from the book feeling like I had a much better handle on agile software development practices, although I know that it is going to take a lot of practice to get better and truly understand them.

When reading business and technology books, I’ve gotten better at using the notes and highlighting feature of the Kindle to tag key concepts. In User Story Mapping, I found myself constantly stopping and making notes or highlighting items. In fact, I probably highlighted the majority of the book. Yes, it is that good.

Here are just a few of the more important concepts that I took away from it:

• Have conversations to build shared understanding – projects succeed when teams have a shared understanding of what they’re building. Shared understanding isn’t developed through a requirements document, shared understanding is created through conversations.
• Creating stories requires lots of documents, but not traditional requirements documents – building shared understanding means talking things out, sketching pictures, using notecards and sticky notes to convey ideas and user flows. I’ve already found that having discussions where things are being sketched and written out is way more productive that writing and reviewing a requirements document on the big screen.
• Focus on outcomes not features – the best products focus on outcomes not features. Features are just a means to create the outcomes that you want users to experience.
• Minimize output, maximize outcome and impact – when developing software, you can always build more. The developer’s job is to figure out how to achieve the maximum impact and outcome by building less.
• There’s always more to build than you have people, time or money for – corollary to the above. Since this is always true, the goal is to figure out how to maximize the outcome with the resources available, not how to build more.

These were just some of the key lessons I picked out of the early chapters. I could go on and on as Patton continuously adds more throughout the book. Best of all, these lessons are tied to actual project implementations so you can better understand how and why they were implemented. If you are interested in seeing or learning more lessons, I’d suggest you go out and read the book instead of having me list the lessons here.

While I don’t feel like I am there yet, User Story Mapping helped me to take a big step in the right direction toward understanding and implementing agile software development practices. My team and I have already started to use it on one of our projects. While the project is still a work in progress, it has gotten off to a much better start than others we’ve done. It feels like the team has developed a much better shared understanding of what we want to build, the interactions with the client have been more productive, and it’s been much easier to have the discussions and make decisions on what features will find their way into the first release. The key is to stay disciplined to continue using the process on this project and to extend its use to both new and existing projects.

I would categorize Jeff Patton’s book an absolute must read for anyone in the software development field, especially if you are interested in developing projects using agile methodologies. It is by far the best book I’ve read on the subject to date. I’m certain that I will come back to this book and my notes, and come back often at that.