Book Review: User Stories Applied

TLDR Version: User Stories Applied is an excellent resource for anyone who wants to gain a better understanding of the ideas behind user stories. The book has very good examples and guidelines on writing better user stories and integrating them into your development process.

User Stories Applied is a book that has often been mentioned to me in the six months I’ve been at ThoughtWorks and over the last two weeks I finally managed to get my hands on a copy. It’s not a very long book (230 pages) and it took me about 3 plane trips to finish it.

The Good

This book provides a very good outline of how user stories work and the intent behind them. Even though I work with user stories every day I found some of the details quite refreshing – especially how user stories are not meant to contain the details behind features, but rather to be a medium for us to start discussions around features.

I particularly liked the discussion on how to write good user stories and the guidance on when stories are too small or too large. This is an area where I think experience really helps, but the pointers in this book are a great starting point.

The Bad

Every chapter in the book ends with a summary and an outline on how the chapter influences the different roles on a development team. I’m not a big fan of this kind of writing – it reminds me of the textbooks I had at school and it doesn’t seem to really add any value.

The second half of the book seems to focus on comparing user stories to other approaches. I felt like the author was trying to defend user stories, but the arguments presented were more focused on the shortcomings of the other approaches rather than the advantages of user stories. Having said that, this can be very helpful if you’re trying to convince a client to use this practice on a project.

Interesting

I was rather intrigued by the difference between how the author describes user stories and what I’m used to. The author advocates that user stories should contain very little detail and the details should be discussed when the story is developed. I’m used to user stories containing most of the detail around a story – in fact stories will usually be pushed back if the details are left out.

I think using user stories as a placeholder for conversations around the details can work really well, but on projects with a large amount of developers (I’m guessing more than 8 developers) the interaction with the user will quickly become a bottleneck. User stories can therefore also work very well when they contain all the necessary details which are analysed and discussed in full before development is started – it’s not a massive difference, but on large teams it can certainly have a massive effect.

User Stories Applied as an excellent resource for anyone who wants to gain a better understanding of the ideas behind user stories. The book has very good examples and guidelines on writing better user stories and integrating them into your development process.