This book is one of the better collections of how-to's and practical applications I've read on Agile user stories. It mixes in just enough of the theory to understand the importance and distinctions of epics, stories, tasks, and spikes without overly focusing on them. Then, it uses real-world examples in common language to walk you through some of the messier implementations of Agile, and provides specific guidance on how to make things work in less than ideal situations. I found this book particularly helpful for me personally, as well as for one of our less experienced Scrum Master's at work.

I have seen other presentations and publications from this author and he really seems to know his stuff, plus it's really easy to read. I'm a consultant and trainer and find this to be an excellent reference. There are lots of examples and the book is very easy to read. You also don't have to be involved in Agile development to find this useful, as I also use the concepts for developing user roles and focusing on user goals as a primary function even in a Waterfall development world.

I'm pretty much allergic to any form of requirements documentation. Change control makes my skin itch, and big up front planning makes me vomit. But I also am not totally comfortable with winging it all the time. As a project manager, I need to get a sense of how big the project is, what are the pieces and parts, and how will the product be used. And I need it fast, flexible, and without much overhead. Oh yeah, don't forget I have to also be able to use it to plan iterations, drive development and testing, and report status. All without making comprehensive documentation more important than working software or processes and tools more important than individuals and interactions.

That's why I'm glad I discovered User Stories Applied: For Agile Software Development by Mike Cohn. It is a short, practical explanation of how to plan, estimate, and execute an agile project with user stories. These lightweight requirements never get in the way or replace conversations with users and customers. Instead, they help you keep track of what you're going to build and serve as a reminder to talk to SME's about what they mean. You can use them to report status, to plan iterations, and to get an overview of the product's feature set.

I wholeheartedly endorse this book for all project or product managers.

As you'll read in other reviews this book does a great job of laying the foundation on how to implement XP as a development process using user stories, iterations, and other concepts used in XP.

Where the book goes a little overboard is with some drawn out stories and examples that could be cut down. In reality I think this book could almost have 1/3 less long and been a 5 star book.

Mike does a great job explaining user stories and agile principles. Very readable and even enjoyable. This book concerns itself mainly with the 'ideal' situation: brand new product development, and does not focus on other nuances such as improvements to existing products, customer-reported defects, validated environments. That's not a criticism, as this book isn't supposed to be the unabridged encyclopedia of user stories, but I plan to read some of Mike's other books... where, hopefully, he will cover such topics

Writing usable requirements in Agile spaces. Yet another well crafted message suggesting how to modify the method of eliciting requirements into something that makes sense from the perspective of the customer. Use the customer's language! Mike makes it simple, uses simple examples, and offers a clear path of application should one choose to traverse. The use of user stories moves the focus of customer relationships from filling out documentation .. to creating and managing a relationship and expectations through customer accessible language.

I work for a consulting company that trains in both agile methods as well as more antiquated lean UP. I was looking for "the" book on user stories. If I wanted to recommend "the" book for use cases, it was "Writing Effective Use Cases" by Alistair Cockburn.



I received this book on Tuesday and had finished reading it by Thursday. It is very well laid out, the chapters are the right length, it has excellent recommendations and it is simply well written.



I'm teaching a class on Agile Requirements Exploration on the 1/22/07 and it will be this book I recommend for further study. It's all someone needs to understand the essence of user stories.



I learned quite a bit reading this book and if you're looking for "the" book on user stories, look no further.

I work for a consulting company that trains in both agile methods as well as more antiquated lean UP. I was looking for "the" book on user stories. If I wanted to recommend "the" book for use cases, it was "Writing Effective Use Cases" by Alistair Cockburn.

I received this book on Tuesday and had finished reading it by Thursday. It is very well laid out, the chapters are the right length, it has excellent recommendations and it is simply well written.

I'm teaching a class on Agile Requirements Exploration on the 1/22/07 and it will be this book I recommend for further study. It's all someone needs to understand the essence of user stories.

I learned quite a bit reading this book and if you're looking for "the" book on user stories, look no further.

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.

This book is not about testimonials, this book is about using User Stories (Index Cards) on an Agile Project. It's a very good explanation of user stories.

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.

Mike has a gift when it comes to explaining concepts in a format that everyone can understand regardless of their technical level. This book is one of them.

User Stories seem like a simple concept, but they can be elusive at first to people used to writing 200-page requirements documents. Writing good stories that stand-up and hold through a project iteration is sometimes more an art than a science.

Mike's book provides insight on ways to help add a little "science" into the mix with practical examples and bullet points of key concepts divided into business and technical groupings. After all stories are supposed to bridge the gap between business and technology and do away with "throw it over the wall" approach to requirements and foster conversation and collaboration.

This is a great book for any Product Owner or development team member who's looking to better understand User Story development. A must have for Scrummasters!

User stories are a method of capturing requirements which was originally introduced in the extreme programming method. User stories are commonly described as "a promiss for a conversation" and are often recorded on index cards (at least, originally). Mike Cohn's book takes the user story practice out of Extreme Programming and shows how it can be used in general in different methods.

The key-idea of user stories is that conversations and understanding via documentation is often wasteful and inefficient. User Stories describes a requirement in such a way that we can remember it in the future. At the time the requirement is ready to be implemented, we'll discuss the requirement in more detail. That way we can delay some of the requirement analysis and move it closer to when we implement it. This reduces "requirement inventory" and can lead to less waste in the development process. Whether and how to use user stories in your project depends on many different variables and user stories explained will explain the details of user stories, the different types of user stories and give plenty of examples. All this is needed for a better understanding and for deciding how user stories can help you on your project.

The book is well written, though personally I found that it contained too much text. There was quite much repetition and that made the book slightly boring after a 100 pages. It could have been written with less text, in my opinion. Another drawback of the book was that the examples given didn't feel real enough. It would have been nice to cover some larger projects and also discuss how user stories would work on these.

In conclusion, User Stories Applied is the definitive and only reference on user stories and when interested in user stories or when working with user stories, this is an absolute must!

I have seen difficulty in keeping Business Requirements at a high level, enough to determine big picture strategies. Typically, the analysts jump in with an existing system in mind, over analyze, and end up with a mountain of information that is inter-twined with complexities and dependencies.

This book helps tremendously.

There is an easier way to begin the faciliation of requirements, that will eventually lead to the detail that analysts love so dearly. But the initial use of User Stories helps to clarify features and capabilities quickly. I was quickly able to get to a high level release and iteration schedule and was then able to set the resources loose to go out a build it.

User stories are general statements of what the final software product is supposed to do. They are also supposed to be short, in general if they cannot be written on a 3 x 5 card, they are considered too complex. For example, the major project done at the end of the book deals with an online company that sells books about sailing. Some of the user stories for this project are as follows:

*) An administrator can delete a book from the site.
*) An administrator can add new books to the site.
*) The system can support up to 50 simultaneous users.
*) A user can establish an account that remembers shipping and billing information.

These stories are simple in nature, easy to understand and represent how the user would think. Of course, there is a great deal of underlying detail needed to support the implementation of each of the statements.
I am a proponent of the idea of relying on user stories in the development of software, as long as they are truly coming from end users. As is mentioned in the book, there are times when marketing will assume the role of an end user. As long as they truly represent end users, this is not a problem. However, once marketing begins to masquerade as end users, then problems arise. Marketing people will by nature overstate and hype products, which is a disaster in the complex, convoluted world of software development.
There are questions at the end of each of the first sixteen chapters and solutions are included at the end. This really gives the reader an opportunity to reinforce the material and I commend the author for doing this. I believe this book to be an important contribution to the advancement of software development and recommend it to all people engaged in the development of software. I will be teaching software engineering again in the spring, 2007 semester and plan on including user stories in the course.

User stories are general statements of what the final software product is supposed to do. They are also supposed to be short, in general if they cannot be written on a 3 x 5 card, they are considered too complex. For example, the major project done at the end of the book deals with an online company that sells books about sailing. Some of the user stories for this project are as follows:

*) An administrator can delete a book from the site.
*) An administrator can add new books to the site.
*) The system can support up to 50 simultaneous users.
*) A user can establish an account that remembers shipping and billing information.

These stories are simple in nature, easy to understand and represent how the user would think. Of course, there is a great deal of underlying detail needed to support the implementation of each of the statements.
I am a proponent of the idea of relying on user stories in the development of software, as long as they are truly coming from end users. As is mentioned in the book, there are times when marketing will assume the role of an end user. As long as they truly represent end users, this is not a problem. However, once marketing begins to masquerade as end users, then problems arise. Marketing people will by nature overstate and hype products, which is a disaster in the complex, convoluted world of software development.
There are questions at the end of each of the first sixteen chapters and solutions are included at the end. This really gives the reader an opportunity to reinforce the material and I commend the author for doing this. I believe this book to be an important contribution to the advancement of software development and recommend it to all people engaged in the development of software. I will be teaching software engineering again in the spring, 2007 semester and plan on including user stories in the course.

This book is a great source of down-to-earth practice on the slippery terrain of "user specs becoming software". By using user stories appropriately, Mike Cohn explains how to have real customer involvement without needing to annoy them. Just get enough time from them to be sure (and let THEM be sure) about what you're building, but not as much as distracting them from their real work.

Even when you don't have real users handy, Cohn introduce the use of personas and role modeling to keep focused on users instead on coolness factor or industry hype.

A really lightweight methodology with highly accurate results, geared to provide real value.

Writing user stories was one area I have always ignored. For the past year, I was the sole developer for my company, so I was able to get by with my limited skill in writing stories. We recently hired another developer and I quickly realized that I was leaving a lot of stories out of the backlog because I "knew" they were supposed to be there. I was also lumping several features into one story, when they should have been distinct. After reading Mike's book, I have a much firmer grasp of what should and should not be in a user story.

The book is written in a very readable style and is quite enjoyable.

Writing user stories was one area I have always ignored. For the past year, I was the sole developer for my company, so I was able to get by with my limited skill in writing stories. We recently hired another developer and I quickly realized that I was leaving a lot of stories out of the backlog because I "knew" they were supposed to be there. I was also lumping several features into one story, when they should have been distinct. After reading Mike's book, I have a much firmer grasp of what should and should not be in a user story.

The book is written in a very readable style and is quite enjoyable.

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.

If you are using user stories to find and talk with your customers then you can't live without this book!!!!!

If you are using user stories to find and talk with your customers then you can't live without this book!!!!!

If you feel that Agile user stories may be a bit loose for projects with strict delivery deadlines, there is an answer in the upcoming sequel to this book, Agile Estimating and Planning. The chapter titled Buffering Plans for Uncertainty addresses this issue. Go to mountaingoatsoftware/agileplanning to read the draft of this chapter.

If you feel that Agile user stories may be a bit loose for projects with strict delivery deadlines, there is an answer in the upcoming sequel to this book, Agile Estimating and Planning. The chapter titled Buffering Plans for Uncertainty addresses this issue. Go to mountaingoatsoftware/agileplanning to read the draft of this chapter.

I've been a product manager for longer than I care to mention. Although I've always had good relationships with engineering, I have always looked for ways to have better, ongoing dialogue with the team. I am very much looking forward to applying the ideas from Mike Cohn's book. I think it will provide faster, cleaner, and less bureaucratic requirements -- but most importantly, better communication between the product management and engineering organizations and better products.

I've been a product manager for longer than I care to mention. Although I've always had good relationships with engineering, I have always looked for ways to have better, ongoing dialogue with the team. I am very much looking forward to applying the ideas from Mike Cohn's book. I think it will provide faster, cleaner, and less bureaucratic requirements -- but most importantly, better communication between the product management and engineering organizations and better products.

Communication, simplicity, feedback and courage! Yes, I can confirm that Mike Cohn succeeds in presenting User Stories that build on these XP values. User Stories could even be considered the 13th XP practice, because without stories, it's difficult to "get away with" the other 12 XP practices.

The book is well structured and easy to read. The golden nuggets of the book are definitely the six attributes for creating good stories. Experienced with Agile development, I immediately used the attributes (with the appropriate acronym INVEST) with great satisfaction in conversations with my customers to identify and analyse stories. It was refreshing to find out how easy it is to explain User Stories within 20 minutes. You only need a whiteboard, and INVEST as your checklist. But above all, because INVEST is lightweight and flexible it challenges you and your customer to create great stories. And bottom line, people make great stories; procedures and tools are only enablers, as they should be!

This book is a must read for business analysts and developers on an Agile development team. I highly recommend this book also to all stakeholders who need, or want, to be aware of what the Agile software development approach means on a day-to-day basis for delivering non-trivial software solutions.

Overall, Agile development is always focused on maximizing your Return On Investment with software development. Therefore I consider this book as a minimum investment to ensure maximum return from each person involved in creating successful stories!

This book is one of the most readable, compact, interesting, and well-written technical books that I've read in a long time. You can easily take it with you, which is a nice change compared to many books out there. The author's writing style is very clear. The layout is professional. The content is high quality.

Being a developer who hasn't had the chance to work on a "true" agile project, I can recommend this to others who are just trying to find out what user stories are all about.

The chapter comparing user stories to other requirements gathering techniques and the one on reasons to use user stories are particularly valuable. There is also great information about estimation and acceptance testing.

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.

How hard can it be to write Stories? The answer seems to be both "pretty simple" and "kind of tricky". Writing short sentences is a skill many of us have mastered by now, but working with people is the challenging part of any job. How many projects have delivered exactly what the Customer *specified*, but not quite what they need? Mike teaches us to keep our Stories simple enough that the team can really communicate with the Customer, responding to the complexities they express as a project progresses.

The book is practical and addresses not just the practice of User Stories, but also how to plan for their use and manage them within different kinds of projects. It includes an introduction to Agile approaches like Extreme Programming (XP) and Scrum, but does not presume that all teams must work in this manner.

Cohn's writing style is crystal clear. The layout of the book is superb, and the material is well developed to make the most of this structure, with short sections clearly titled. While readable as a training manual, the detailed table of contents also makes it valuable as a reference book.

For Agile teams, this book provides a condensation of valuable experience, and practical advice. And if your team is stuck in analysis paralysis, spinning to refine and refine requirements, this book may provide the "aha" you are looking for.

How hard can it be to write Stories? The answer seems to be both "pretty simple" and "kind of tricky". Writing short sentences is a skill many of us have mastered by now, but working with people is the challenging part of any job. How many projects have delivered exactly what the Customer *specified*, but not quite what they need? Mike teaches us to keep our Stories simple enough that the team can really communicate with the Customer, responding to the complexities they express as a project progresses.

The book is practical and addresses not just the practice of User Stories, but also how to plan for their use and manage them within different kinds of projects. It includes an introduction to Agile approaches like Extreme Programming (XP) and Scrum, but does not presume that all teams must work in this manner.

Cohn's writing style is crystal clear. The layout of the book is superb, and the material is well developed to make the most of this structure, with short sections clearly titled. While readable as a training manual, the detailed table of contents also makes it valuable as a reference book.

For Agile teams, this book provides a condensation of valuable experience, and practical advice. And if your team is stuck in analysis paralysis, spinning to refine and refine requirements, this book may provide the "aha" you are looking for.

'User Stories Applied' was a book that long stood on my Amazon wish list with a 'must have' rating. I'm not disappointed. I loved the book. Now let me explain why.

First of all, running the planning aspect of an XP project, for example, well is essential for reaping the benefits of agile software development. Yet, relatively little has been written to guide practitioners in doing that. I, for example, have made all the mistakes Cohn enumerates in the chapters for guiding the user towards writing *good* user stories (usually more than once). These sorts of things make you realize you shouldn't put the book on the shelf to gather dust! The author doesn't cover just writing good user stories, but the whole spectrum from putting together the customer team to estimating stories to discussing the stories to writing acceptance tests for the stories.

Second, it's a pleasure to read. The structure makes sense, each chapter is followed by a useful summary, and there's a set of questions -- along with answers -- to make sure you understood what the chapter talked about. Usually these kinds of Q&A sections simply force me to skip them over. The questions in this book did not. I read each and every one of them and I think there was only one set of questions that I did 'pass' with the first try, usually having forgotten some rather important aspects to consider (concrete evidence of their usefulness to me). To finish, the last part of the book, an example project, nicely ties together all the threads.

As usual, there were some things I experienced not so well. I believe the chapter on applying user stories with Scrum could've been left out without breaking the plot. Also, I think a typical user wouldn't have been bothered about dropping the appendix introducing Extreme Programming.

In summary, this is the book to get if you're involved with user stories. I had to pause reading every few pages to scribble down some specific tips. I'm confident that you will too.

Agile software development uses light-weight requirements, often called User Stories. Mike's book shows you different ways of writing those stories, and of estimating them and scheduling them for implementation. He starts at the basics, and continues to build up information until he has almost certainly covered more than you'll likely need. You'll have a good understanding of what to do now, and what to do when and if further needs arise. Recommended.

I am a professional IT consultant, particularly providing agile methodology consulting. I have a lot of books on requirement management(analysis/gathering/etc). This book comes as one of the best three books of the kind.

I was once part of a new XP project where the users were very confused as to how to write a user story, having written nothing but detailed requirements their entire lives. The developers, also new to XP, didn't completely comprehend that they were to actually work with and talk to the users to elicit further details. Oh, if only I had had this book then! I would have purchased a copy for every user and every developer! There is a huge mental shift that has to take place when embracing agile methodologies, and Mike Cohn's book is an excellent catalyst for that change, making it a less painful transformation for those players involved. Cohn even spells out each group's responsibilities at the end of every chapter -- there's no ambiguity around who's supposed to do what. There are lots of examples that are easily understood, and the layout provides you with the information you and your team need in a logical sequence. Chapter 4 has a fabulous section called "Story Writing Workshop" that again provides that step-by-step hand-holding that first-timers need. I highly recommend this book. It's an excellent primer on the process of defining requirements in an agile environment.

Finally a book that demystifies Agile Requirements Management. In particular demystifying myths about User Stories themselves.

The book puts together ideas from other books on the subject : Writing Effective Use Cases and Requirements by Collaboration :
Workshop for defining needs.

This book not only explains properly the concepts but gives you practical advice on how you could use user stories on your projects.

I particularly liked the chapter : Using Stories with Scrum.

Reading this book was truly an enjoyable and learning experience.

Mike Cohn not only has a wealth of experience but also the ability to tell his story in an understandable and compelling way. The result is that the reader walks away saying, "OK! I get it. I don't know why I thought this would be so hard!" These stories are more than the details of the mechanisms of writing user stories. Sure, that's good all by itself. The big, important thing about this book is that the details are cast in an expansive foundation that really shows you how effective teams work with each other and with customers. That's why I give this two thumbs up!

Having worked with SW development for more than 20 years, I have finally realised, that face to face, collaborative communication between users and developers in an open atmosphere is the first important step on your way to successfull projects.
Many books covers this briefly in a chapter or two, but with this book, you get a complete manual with techniques, that will be usefull to you in your collaboration with the users.

I give this book eight out of ten.

What I like about it:
It is well written and easy to read. The book is presented in a nice flowing style that I found mostly friendly and enjoyable.
Each chapter concludes with a summary of the information from that chapter and questions to help reinforce learning process.
At the end of each chapter are listed the responsibilities for the developer and those for the customer roles.
The book covers user stories. It does what it sets out to do. The title describes it well.
The contents are well thought through and seem to cover most questions that I get asked on a regular basis relating to user stories.

In order to get a ten:
It would be shorter. It feels like a lot of reading to get what is in fact a simple idea. It takes too long to get all the information from the book. I can see the struggle involved in getting all the information into the book and at the same time keeping it concise.
The book would contain some hands on exercises (or walk through examples) for the reader to follow the entire process. Part IV presents an example but is taken from an external examination point of view. I would like to be drawn in and become part of the process so I can get a better understanding of user stories.

For more of Dr. Neil's reviews go to http://www.Roodyn.com/BookReviews.aspx

User Stories Demystified - As you leaf through Mike Cohn's new book "User Stories Applied", the first thing you will experience is a dramatic sense of relief. A certain calm will come over you because at last you have in your hands a very clear, succinct, step-by-step view into the what, when, where, how, and why of user stories. Mike's delivery of this material is richly simple in that he manages to sift through the many worries and controversies that surround the role of user stories in an agile project environment and takes us to the nuggets. At the same time, he sparks the fundamentals with a variety of suggestions for implementation based on his extensive experience. In various XP teams in which I have worked, an early challenge of the team had always been around the ability of the team to shift from requirements and design documents and detailed test plans to user stories. Writing them was tortuous; later interpretation of them felt fuzzy. With Mike's guidance, we would have known not only how to write, estimate, prioritize, and test our stories, we would have also had ample guidance on who should be paying attention to what in each step of the stories' lifecycle. If you are beginning a new project, release, sprint, or iteration, don't move another step without distributing Mike's book across the team as pre-requisite reading. They'll all thank you for it.