Customer Reviews

User Stories Applied: For Agile Software Development

5 star:		(41)
4 star:		(10)
3 star:		(3)
2 star:		(0)
1 star:		(0)

 

 

'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.

This excellent book is a must-have for anyone on an agile team - developers, testers, business experts, analysts - and for anyone who struggles with requirements, planning, or estimating on any software project.

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.

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.

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.

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.

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.

Every agile methodology advocates iterative, story-driven (although they may call them features or backlog items) development and so one might assume that an entire book on user stories and iterative planning would be redundant-not so. Mike has added both a breadth and depth to the body of information on this subject as his obvious practical experience shines through. Both little tidbits, like constraining estimates to specific pre-defined values, and responses to frequently asked questions (for example the best contrasting of use cases versus stories that I've seen) give Mike's book significant value for anyone practicing agile development of any flavor.

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.

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 is a very good book. It describes how to write requirements as xp stories, what makes a good story, how to gather requirements, and a little bits about acceptance testing, estimating, and planning. Also nice to see a chapter on using XP-style stories with Scrum.

If you are playing the role of a product designer -- even if you're not using Extreme Programming -- you should buy this book, and also buy Gerald M. Weinberg's book on requirements "Exploring Requirements: Quality Before Design" (with Donald C. Gause.)

him