The concept of user stories has its roots as one of the main tenets of Extreme Programming. In simple terms, user stories represent an effective means of gathering requirements from the customer (roughly akin to use cases). This book describes user stories and demonstrates how they can be used to properly plan, manage, and test software development projects. The book highlights both successful and unsuccessful implementations of the concept, and provides sets of questions and exercises that drive home its main points. After absorbing the lessons in this book, readers will be able to introduce user stories in their organizations as an effective means of determining precisely what is required of a software application.

Average Customer Review: ( 56 customer reviews )
Write an online review and share your thoughts with other customers.

User Stories Applied is easy to read and digest. As the title suggests, its techniques are easy to apply and deliver huge value. Each chapter summarizes developer and customer responsibilities, and has questions whose answers are provided in an appendix. The book is full of real-life, concrete examples, allowing you to learn from the successes and failures of others.

This book will give you many tools to help your projects succeed. Just a few of the most valuable topics:
When are user stories too big, too small, too detailed, too general, too open ended, when are they not user stories, and how to correct all these.
Why use user stories.
How to handle requirements for infrastructure, performance, qualitative aspects, UI.
How to ask questions to elicit requirements.
How to cope when you don't have `on-site customers'.
Practical ways to estimate stories.
Monitoring velocity and progress.
When to keep and when to discard artifacts.

Mike explores the differences between stories and other techniques for delivering requirements: IEEE 380, use cases, scenarios. He points out many positive side effects of user stories, such as encouraging participatory design and tacit knowledge accumulation.

I particularly like that the book emphasizes the team's responsibility to successfully complete each iteration. I enjoy Mike's illuminating bits of wisdom, such as the "everything takes 4 hours" example. I love the comprehensive example in Part IV. No matter what your level of experience, you'll put the ideas in this book to immediate and productive use.

10 of 10 found the following review helpful:

For XP enthusiastsNov 04, 2005
By Ugo Cei
Writing user stories is one of the twelve practices of the XP software development methodology. User stories summarily describe features of the software that must be developed, from the point of view of the user. This means that no implementation detail is present on stories.

As with all the XP practices, the emphasis is on traveling light, producing only those artifacts that are absolutely necessary. Thus, user stories contain a brief description of the feature as a reminder, to the developers and to the customer, that sometime in the future they will need to meet and flesh out the details. This is in contrast to techniques like use cases, which might seem similar but are much more formal and rich.

User stories also play a fundamental role in the planning game, one of the other XP practices. During the planning game, the development team and the customer together discuss the stories, the developers estimate the time necessary to implement each story, in terms of story points and the customer prioritizes them. During the next iteration, developers will implement those stories that the customer deemed more urgent, up to a number whose total sum of points does not exceed the estimated team velocity.

All of this is explained in a couple of the XP series books, namely Extreme Programming Explained: Embrace Change and Planning Extreme Programming You'd better have already read at least the former of those before picking up Mike Cohn's book.

User Stories Applied does a good job explaining in detail what user stories are, what goes into them -and what doesn't -, how they should be estimated and what to do with them after the stories have been implemented.

There's a lot of good sense advice in this book, which might induce someone to think that user stories and all other XP practices are just a bunch of generic suggestions that you might apply or not, as you wish. That's certainly not true, as XP is a methodology whose effectiveness lies in the combined action of all the practices when they are taken to the limit. This takes determination and discipline and, in my experience, it's just too easy to fall into the habit of following only some of them, say when you're not under deadline pressure, and still pretend that you're an XP shop.

I would have liked more real-life stories in this book, in order to spice it up a little. As it is, everything that is there sounds highly reasonable (at least to me) but it wouldn't convince anyone who is skeptic of XP's supposed benefits. The example at the end of the book sounds contrived and hollow.

On the other hand, if you have been already convinced by Kent Beck's white book and want to start adopting XP, I can heartily recommend Mike Cohn's book.

10 of 11 found the following review helpful:

The only game in townSep 03, 2004
By Ernest Friedman-Hill "JavaRanch Sheriff"
Many books have been written about requirements gathering as a discipline, and many more about techniques for doing it. To my knowledge, this is the first book dedicated to "user stories", the form of software requirements capture used in Extreme Programming (XP). At first blush, you might think that there isn't enough to the topic to warrant a book, because the beauty of user stories is their simplicity. But Mike Cohn shows that there is indeed plenty of potential material -- and useful material at that. My only complaint about this book is that the proofreading could have been more careful; there are too many "stray words" left over from editing.

In "User Stories Applied", Cohn explains what stories are, what makes a good story, and how stories are written. He uses copious examples throughout, and I enjoyed the self-test questions at the end of each chapter. My favorite part of the book comes near the end, when he works through how the initial set of stories would be developed using a nontrivial example (an eCommerce web site.)

Although user stories are traditionally associated with XP, they can be used without it, and Cohn shows how stories fit in with other agile methodologies (Scrum in particular.) If you need to capture requirements for agile projects, or if you're sick of writing ISO standard requirements documents and think there must be a better way, then this book is for you.

10 of 11 found the following review helpful:

Good, but next is betterJan 11, 2007
By C. G. Mccants "scrumify or die"
This book has some good stuff in it, especially the INVEST criteria for a good Story. But as far as practical application, Mike's other book, Agile Estimating and Planning, is better.

If you are a business or requirements analyst or a Product Owner, get this one. If you are a ScrumMaster, get both.

See all 56 customer reviews on Amazon.com