Skimmed it quickly to refresh my mind. Here are some quotes:

--

I remember many years ago being told a story about a child at bath time. The child's father has filled the bath tub and is helping his child into the water. The young child, probably two or three years old, dips a toe in the water, quickly removes it, and tells her father "make it warmer." The father puts his hand into the water and is surprised to find that, rather than too cold, the water is already warmer than what his daughter is used to.

After thinking about his child's request for a moment, the father realizes they are miscommunicating and are using the same words to mean different things. The child's request to "make it warmer" is interpreted by any adult to be the same as "increase the temperature." To the child, however, "make it warmer" meant "make it closer to the temperature I call warm."

--

Ron Jeffries has named these three aspects (of a story card) with the wonderful alliteration of Card, Conversation, and Confirmation

--

The test descriptions are meant to be short and incomplete.

--

Most readers of this type of (detailed) story will mistakenly associate the extra detail with extra precision. ...(they will forget that their discussion is supposed to be somewhat abstract)

--

It is very possible that considering extreme characters will lead you to stories you would be likely to miss otherwise. For example, it is easy to imagine that the drug dealer and a woman with several boyfriends may each want to maintain multiple separate schedules in case the PDA is seen by the police or a boyfriend. The Pope probably has less need for secrecy but may want a larger font size.

--

Estimate on ideal days rather than elapsed time.t

One team may decide to define a story point as an ideal day of work. Yet another team may define a story point as a measure of the complexity of the story.

--

Handle risk by doing the "juicy bits" first

--

IEEE 830-style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the user's goals.

--

Stories, on the other hand, are not intended to outlive the iteration in which they are added to the software. While it is possible to archive story cards, many teams simply rip them up.

--

In fact, an interaction design scenario is typically larger, or more encompassing, than even a use case... scenarios include the following characteristic elements: a setting, actors, goals or objectives, actions and events

--

Until an Athenian ruler started writing down Homer's The Iliad so that it would not be forgotten, stories like Homer's were told, not read. ... We shifted focus to a shared document and away from a shared understanding.

--

Writing perfect requirements seems like such a lofty and unattainable goal.

--

100 perfect left shoes does not yield a single perfect pair of shoes.

I love that it gives a very useful and practical advice on how to write good stories, it comes pretty handy with the Sprint goals.

I returned to this book recently when there was some questioning about what made a user story, a "good" user story. The "INVEST" acronym originated here.

Returning to the book these days almost feels quaint because of the references to Extreme Programming (XP) which has declined in practice. While the user stories concept still holds sway in hearts and minds of software professionals everywhere, there isn't much academic rigor in here.

The humble user story is very much at the heart of the Agile movement, so it's good to return to these roots and remember where this all came from -- a desire to be nimble and lightweight. (Ironically the lack of rigor to this idea and the overuse of jargon has created something of a cargo cult that has been a disservice to the adoption of DevOps because Agile has not traditionally concerned itself with implementation specifics.)

The term, "epic," which is literally just a big user story, also originated here.

It's quite a long book for how simple the concept is. Reads more like a textbook.

The book is good as an archaeological dig but the Patton book on Story Mapping is way better for practical understanding what stories are truly good for - placeholders for shared understanding of a need.

Decided to read to this one after listening to a series of super engaging podcasts with the author (Mike Cohn). While this one was originally published in ‘04 and some of the info is outdated, much of the underlying principles are totally relevant. I found this book to be very easy to get through, helping me understand the necessity of customer-centricity from a devs POV. Much of this read overlapped with concepts in Jobs to Be Done by Ulwick, which I also just read, and I found this one to be a way less pretentious in tone. Solid read and highly recommend to anyone in digital products.

Most parts are good, coming from the author's own experience and opinion. However, this book refers to oudated, sometimes contradicted concept of the latest 2017 ScrumGuide.

I expected some budgeting and financial planing for projects and releases but didn't see them in this book.

This is probably one of the best books I've read for a long time for software design. The method of using user stories as laid out in this book is a great way of obtaining a high level view of the requirements of a system, and the constant communication and feedback with customers that the described development strategy suggests is a good method of moving from the high level stories down towards the nitty gritty details of an implementation.

Possibly the most useful part of the book though is the section on estimation and planning. This appears to be more fully explored in the book 'Agile Estimating and Planning' (http://www.goodreads.com/book/show/92...) but the few chapters on the subject here give a very good alternative to attempting to give estimates on unknown things in too 'physical' a unit, for want of a better description.

Overall, I'd say this is a should-read for software developers, especially those who have had bad experiences with lengthy requirements and specifications and are looking for an alternative method, or a method that fits very well into any iterative development approach.

More geared toward "in-person" agile teams, so lots of references to post-it notes and quick face-to-face discussions, but it's a helpful overview for those trying to understand the different interpretation of stories/epics/etc.

Must read for BA doing agile

For me this book is a great introduction to the general idea of user stories and how that can be approached in projects. The examples are easy to follow there are quite a few ideas I have to keep in mind.

This is a good book covering general aspects of user stories. But it doesn’t provide a more detailed view on for eg. complex user stories and their slicing vs layers of an applications architecture. It only emphasizes that creating user stories that provide at least some level of end to end functionality is best.

A classic about User Stories and iteration planning that is a bit outdated. For someone new to the field this book might be a good introduction into User Stories and iteration planning. For someone familiar with the topics it is a good refresher but there is nothing tremendously new and innovative.

The content is geared toward agile development teams performing an IT project without to much dependencies. Questions that arise when one has to deal with bigger organizations (two or more teams. programs, end-to-end processes, etc.) are not handled her.

I believe as I am reading this in 2018, there are some inherent biases I have about how to write a user story.
While it made me revisit the basics of a user story, it is worthwhile to mention that readers WILL need a grasp of their own organization/team members in order to implement these practices.

All in all, a good read indeed, for those who are just starting with user stories, this book will definitely help. I liked the part where Mike has explained the core of story-pointing. When estimating the stories, I am going to use those tips for sure!