What do you think?
Rate this book
A Kent Beck Signature Book
User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series
Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software. The best way to build software that meets users' needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied , Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle. You'll learn what makes a great user story, and what makes a bad one. You'll discover practical ways to gather user stories, even when you can't speak with your users. Then, once you've compiled your user stories, Cohn shows how to organize them, prioritize them, and use them for planning, management, and testing. User Stories Applied will be invaluable to every software developer, tester, analyst, and manager working with any agile method: XP, Scrum... or even your own home-grown approach.
296 pages, Paperback
First published March 1, 2004
302 people are currently reading
3312 people want to read
About the author
Mike Cohn
17 books170 followersMike Cohn is one of the contributors to the Scrum software development method. He is one of the founders of the Scrum Alliance.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 137 reviews
September 26, 2012
User Stories Applied: For Agile Software Development is a decent introduction to user stories. The book could have benefitted from more depth on user stories and a little less breadth on adjoining topics. It is from 2004 and is starting to show its age.
The user story is a frequently used tool in agile software development methods such as eXtreme Programming (XP) and Scrum. It is used both for documenting the existence of a requirement and as a worm package for use in scope planning and scheduling. This is possible due to the incremental nature of agile methods. Work is decomposed into work packaged along user goal and contain all or at least most of the steps in the software development lifecycle. This in contrast with sequential methods where the work is decomposed by type instead.
User stories with the addition of conditions for satisfaction (high-level acceptance test cases) is the most important artefact in the communication between the customer team and development team. This interface is probably the hardest to get right in IT and being to able to write good user stories would be a great boon.
The book is from 2004 and is beginning to show its age. I think Cohn might have changed his mind on some things since then, for instance on the use of ideal days as the measure of a story point. Scrum no longer insists on 30-day sprints. The Wideband Delphi technique for estimating user stories described by Cohn is now usually referred to as planning poker.
The age becomes apparent in another way as well. For some reason Cohn writes a lot about subjects only tangentially related user stories. There are even introductions to both Scrum and eXtreme Programming in there. That might have made sense in a time where these were not as well known as they are today.
Despite this, the book is a decent introduction to user stories, what they are, how to write them and how to use them, complete with a case study. It is pretty short, not a bad thing per se, but it also tries to cover a great range of topics. This means there is not much space left to go into detail on the user stories themselves. I would have liked more both on developing roles and personas and on the "trawling" for user stories. As it is, anyone already familiar with agile methods will find them selves skipping big parts of the book.
As always with Cohn, the book is well written and easy to follow.
The user story is a frequently used tool in agile software development methods such as eXtreme Programming (XP) and Scrum. It is used both for documenting the existence of a requirement and as a worm package for use in scope planning and scheduling. This is possible due to the incremental nature of agile methods. Work is decomposed into work packaged along user goal and contain all or at least most of the steps in the software development lifecycle. This in contrast with sequential methods where the work is decomposed by type instead.
User stories with the addition of conditions for satisfaction (high-level acceptance test cases) is the most important artefact in the communication between the customer team and development team. This interface is probably the hardest to get right in IT and being to able to write good user stories would be a great boon.
The book is from 2004 and is beginning to show its age. I think Cohn might have changed his mind on some things since then, for instance on the use of ideal days as the measure of a story point. Scrum no longer insists on 30-day sprints. The Wideband Delphi technique for estimating user stories described by Cohn is now usually referred to as planning poker.
The age becomes apparent in another way as well. For some reason Cohn writes a lot about subjects only tangentially related user stories. There are even introductions to both Scrum and eXtreme Programming in there. That might have made sense in a time where these were not as well known as they are today.
Despite this, the book is a decent introduction to user stories, what they are, how to write them and how to use them, complete with a case study. It is pretty short, not a bad thing per se, but it also tries to cover a great range of topics. This means there is not much space left to go into detail on the user stories themselves. I would have liked more both on developing roles and personas and on the "trawling" for user stories. As it is, anyone already familiar with agile methods will find them selves skipping big parts of the book.
As always with Cohn, the book is well written and easy to follow.
September 7, 2024
Досить непогана книга і як напрочуд досі актуальна. В свій час допомогла розібратися з написанням User stories та зрозуміти як надалі писати тестову документацію (тест кейси, чек лісти), складати тест плани та планувати роботу в подальшому.
July 13, 2009
Written from an engineer's perspective, it provides a good overview of the Agile Methodology but an uninformed approach to requirements gathering / needs assessment.
April 18, 2024
This seems to be one of the classic texts on user stories. It is generally quite well-written and organized with copious examples and a several-chapter case study at the end. It gives a clear understanding of user stories, what they're for, what they're not, how to write them, how to prioritize them, and how to organize them into iteration planning and final testing.
The book has a couple downsides. First, my copy cost 41 Euros, which is at least twice as much as it should have. It's a print-on-demand book from 2004 with around 250 pages - the cost is extortionate. Second, it's somewhat dated. It assumes the reader will be coming out of a waterfall development mindset and does a lot of explanation of Agile and arguments on its behalf. It also seems to have been written before product management orgs reached their current status as a major component of most software companies, so the function is rarely mentioned and not much considered. And some of the terminology is a bit dated - what we would call jobs-to-be-done these days is called Goal Stories, for example. Third, stylistically, the writing is at times a bit odd. I have several examples, but the one I'll mention is that what most people would call "red flags," Cohn calls "smells," which I found a bit weird.
Modern readers might blanche at the price, need to skim the stuff on why scrums are good, and translate references to customer teams into product manager equivalents, but at the end of the day, you get what you came for - a solid, comprehensive overview of the topic.
The book has a couple downsides. First, my copy cost 41 Euros, which is at least twice as much as it should have. It's a print-on-demand book from 2004 with around 250 pages - the cost is extortionate. Second, it's somewhat dated. It assumes the reader will be coming out of a waterfall development mindset and does a lot of explanation of Agile and arguments on its behalf. It also seems to have been written before product management orgs reached their current status as a major component of most software companies, so the function is rarely mentioned and not much considered. And some of the terminology is a bit dated - what we would call jobs-to-be-done these days is called Goal Stories, for example. Third, stylistically, the writing is at times a bit odd. I have several examples, but the one I'll mention is that what most people would call "red flags," Cohn calls "smells," which I found a bit weird.
Modern readers might blanche at the price, need to skim the stuff on why scrums are good, and translate references to customer teams into product manager equivalents, but at the end of the day, you get what you came for - a solid, comprehensive overview of the topic.
July 26, 2018
I recently learned a fundamental dichotomy in expressing oneself: you use either the 'esoteric' or the 'exoteric' mode. (The exoteric writer says exactly what she means, minimises ambiguity and tries to do everything with explicit reasoning, for the largest audience they can, with imagery and irony only as decoration. The esoteric writer – distinct from, but often coextensive with the woo-woo mystical metaphysics fans also called esoteric – does the converse.
Most ancient writers wrote esoterically, which is one reason that undergrads and other fools, like me, think that ancient writers are vague and low on content. Up to now, I have been confusing the rhetorical stance - see Heidegger, Deleuze, Derrida, Caputo - with the magickal crap. But so much of the Analytic / Continental divide can be explained in this single distinction! [The revival of the distinction is due to that lionized demon Leo Strauss.] Maths is an interesting border case, but its clarity and attempt to destroy ambiguity make it exoteric, I think.)
The exoteric intention strikes me as firstly just good manners and important for intellectual honesty (accountability, critical clarity). But one thing I dislike about studying computer science is that all the materials are utterly exoteric. I crave art and irreverence in formal contexts, and those are always at least somewhat esoteric. The ‘Agile’ software thing strikes me as good, a way of making the hag-ridden and monstrously expensive dev process work. But all the material around Agile, LEAN (and the wider business-marketing-HR-systems theory blah that represents most employed adults’ only engagement with passably academic work) is so exoteric that something in me rebels.
Most ancient writers wrote esoterically, which is one reason that undergrads and other fools, like me, think that ancient writers are vague and low on content. Up to now, I have been confusing the rhetorical stance - see Heidegger, Deleuze, Derrida, Caputo - with the magickal crap. But so much of the Analytic / Continental divide can be explained in this single distinction! [The revival of the distinction is due to that lionized demon Leo Strauss.] Maths is an interesting border case, but its clarity and attempt to destroy ambiguity make it exoteric, I think.)
The exoteric intention strikes me as firstly just good manners and important for intellectual honesty (accountability, critical clarity). But one thing I dislike about studying computer science is that all the materials are utterly exoteric. I crave art and irreverence in formal contexts, and those are always at least somewhat esoteric. The ‘Agile’ software thing strikes me as good, a way of making the hag-ridden and monstrously expensive dev process work. But all the material around Agile, LEAN (and the wider business-marketing-HR-systems theory blah that represents most employed adults’ only engagement with passably academic work) is so exoteric that something in me rebels.
April 6, 2018
Works well both as an introduction to agile practices with a focus on user stories and I can strongly recommend it if you are new to Agile as a whole.
Works very well also in case you have experience with agile practices, but less theoretical background on why certain practices work the way they do, I also recommend if you have previous experience in Agile, software development or project management.
Very well written and easy to follow.
Works very well also in case you have experience with agile practices, but less theoretical background on why certain practices work the way they do, I also recommend if you have previous experience in Agile, software development or project management.
Very well written and easy to follow.
October 22, 2021
As you walk through the prototype, ask questions that will help you identify
missing stories, such as:
• What will the user most likely want to do next?
• What mistakes could the user make here?
• What could confuse the user at this point?
• What additional information could the user need?
Most readers of
this type of story will mistakenly associate the extra detail with extra precision.
missing stories, such as:
• What will the user most likely want to do next?
• What mistakes could the user make here?
• What could confuse the user at this point?
• What additional information could the user need?
Most readers of
this type of story will mistakenly associate the extra detail with extra precision.
January 3, 2015
One of the best books I have read about Agile approach. Focusing on the User Stories as the center of the Agile methodology, it provides very useful and practical information; regarding how to write good stories, and how to use them as a reliable tool for estimation and planning.
Read
December 18, 2019Dig very much down into user stories, but just part one seems enough to know what they are, everything else is the matter of managing product development process which applies user stories, not really about the user stories themselves.
May 18, 2020
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.
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.
Read
November 12, 2025Decided 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.
January 23, 2019
This short book promises to explain what User Stories are, what they aren't, how to create and utilize them within an Agile/XP approach, and finally how to bring everything together in a short, yet relatively realistic case study. It delivers exactly what it promises and the exercises at the end of the chapters, although not always very well crafted, help the reader to capture the essence of each chapter, as well as focus on the pitfalls. It is not repetitive and does not try to be everything for every type of software developer, and that I consider another positive point.
No matter what methodology you use, software development is a challenging task, and even if your favorite method is Agile or a variation of it, you'll need hard earned experience and probably more than just one book, but if I had to recommend only one introductory book to someone who wants to get the essence of creating User Stories to capture most of the aspects of end user software, then this book would be it
No matter what methodology you use, software development is a challenging task, and even if your favorite method is Agile or a variation of it, you'll need hard earned experience and probably more than just one book, but if I had to recommend only one introductory book to someone who wants to get the essence of creating User Stories to capture most of the aspects of end user software, then this book would be it
March 25, 2025
"User Stories Applied: For Agile Software Development" was recommended to me by my Agile mentor, Angry Pete.
Angry Pete was dismissive of almost everything, but he liked this book. Which made me sit up and take notice.
There may be a couple of points in the book Angry Pete wouldn't have liked. He would not have agreed that points are equivalent to "ideal days," for example - Pete would have said that points are an abstract relative story complexity - but, you know, thinking about ideal days is probably a helpful way to start thinking about points for anyone new to the topic.
I particularly love the way the book is written. It's accessible. It's actionable. It covers everything from first principles (e.g. "What is an acceptance test?" "What is a user story") and yet it somehow manages to do this without being laborious.
I've read the book multiple times. It's always on my bookshelf, ready to call upon when I'm working on an Agile project.
Angry Pete was dismissive of almost everything, but he liked this book. Which made me sit up and take notice.
There may be a couple of points in the book Angry Pete wouldn't have liked. He would not have agreed that points are equivalent to "ideal days," for example - Pete would have said that points are an abstract relative story complexity - but, you know, thinking about ideal days is probably a helpful way to start thinking about points for anyone new to the topic.
I particularly love the way the book is written. It's accessible. It's actionable. It covers everything from first principles (e.g. "What is an acceptance test?" "What is a user story") and yet it somehow manages to do this without being laborious.
I've read the book multiple times. It's always on my bookshelf, ready to call upon when I'm working on an Agile project.
June 16, 2017
Overall, it's not too bad - I'm on the 3.5 rating really (4 stars for me is "yes I'll read again). I'll probably refer back to it every now and then, but am more likely to go to Mike's website if I want more specific information.
I came at this as a BA with a fair bit of experience and was looking a quick light and easily digestible overview of stories - which this is. However, as another reviewer has noted, this book is definitely coming at the topic from the perspective of a software engineer, not a BA or requirements person. So if you're a BA and reading this book, check your chip on your shoulder at the door, then just plow through it.
The book is pretty well written and very easy to read - there feels to be a little bit of padding but that's fine. Feels a little out of date in some ways, but would recommend as a primer.
- B.
I came at this as a BA with a fair bit of experience and was looking a quick light and easily digestible overview of stories - which this is. However, as another reviewer has noted, this book is definitely coming at the topic from the perspective of a software engineer, not a BA or requirements person. So if you're a BA and reading this book, check your chip on your shoulder at the door, then just plow through it.
The book is pretty well written and very easy to read - there feels to be a little bit of padding but that's fine. Feels a little out of date in some ways, but would recommend as a primer.
- B.
April 16, 2021
Although somewhat out of date in many respects, this book still provides a good overview of why and how to write user stories. Given that the book was first written almost 20 years ago, we can forgive most of the outdatedness. For example, I don’t think most Scrum teams use 30-day sprints anymore, and many many teams are now remote - even before COVID-19.
The core material, however, remains valuable, particularly for readers more accustomed to something heavier than user stories, or for those of us who need a refresher on user modelling or vertical slices of functionality.
I wished the book had more advice on non-functional stories and, perhaps, an update that had less focus on Extreme Programming.
The core material, however, remains valuable, particularly for readers more accustomed to something heavier than user stories, or for those of us who need a refresher on user modelling or vertical slices of functionality.
I wished the book had more advice on non-functional stories and, perhaps, an update that had less focus on Extreme Programming.
December 15, 2024
User Stories Applied: For Agile Software Development by Mike Cohn is a must-read for anyone working in Agile environments. The book dives deep into writing, refining, and leveraging user stories with practical examples and actionable advice. Cohn’s approach is clear and systematic, making it easy to apply to real-world projects. Whether you're a beginner or an experienced practitioner, this book will enhance your understanding of how user stories can drive collaboration and deliver value.
August 27, 2017
Two stars might not seem much... but I honnestly don't think it should be much more. It's worth reading for having a baseline of the concept of user stories, but a whole book about a (simple) concept is quite a lot, especially as the example used throughout the book is pretty shallow. In practice, half of what is gone over quickly (e.g. non-functional requirements, refactoring): that simply doesn't work out with user stories. Good for somebody just starting with some agile concepts, but too simplistic to even consider using stand-alone. Fortunately (albeit too slowly) methodologies used have started taking the shortcomings into account and use a fuller framework.
April 17, 2019
This book is from 2004 and I found it has aged a lot. Reading for the first time in 2019, I find it barely scratches the surface of User Stories.
Don't get me wrong, it is a good introduction to the topic. But I would combine it with User Story Mapping, as mapping the stories provides an excellent way of having that first story workshop that will generate stories.
Another aspect I didn't like was the fact the book is full of typos!!
All in all, a good introductory book to one requirements gathering tool. Just make sure it is not your only tool. I cannot recommend it though, I know Mike Cohn now has an online course on this. So maybe that is something to check.
Don't get me wrong, it is a good introduction to the topic. But I would combine it with User Story Mapping, as mapping the stories provides an excellent way of having that first story workshop that will generate stories.
Another aspect I didn't like was the fact the book is full of typos!!
All in all, a good introductory book to one requirements gathering tool. Just make sure it is not your only tool. I cannot recommend it though, I know Mike Cohn now has an online course on this. So maybe that is something to check.
May 26, 2019
It answered on many questions I collected over the years by writing stories in a very simple manner.
Here are my top findings:
- Stories should be as a slice of a cake. Story should fit in the sprint and should include all layers of the application;
- Story should be closed with an achievement;
- Keep the UI Out as Long as Possible;
- Keep user stories short, and don't forget their purpose as reminders to hold conversations;
- INVEST story principals: independent, negotiable, valuable to the user, small, testable.
- Accepting Responsibility. At the end of an iteration no one can say "I finished my work, but Tom still had a few tasks left.
Here are my top findings:
- Stories should be as a slice of a cake. Story should fit in the sprint and should include all layers of the application;
- Story should be closed with an achievement;
- Keep the UI Out as Long as Possible;
- Keep user stories short, and don't forget their purpose as reminders to hold conversations;
- INVEST story principals: independent, negotiable, valuable to the user, small, testable.
- Accepting Responsibility. At the end of an iteration no one can say "I finished my work, but Tom still had a few tasks left.
November 23, 2019
Nagyon hasznos, bár kissé idejétmúlt összefoglaló a "user story"-k használatáról az agilis szoftverfejlesztés területén. (Kéne egy jó magyar fordítás a "user story" kifejezésre, én eddig a "felhasználói követelmény"-t hallottam, de az nem az igazi, sőt, kicsit szembe is megy a kívánt szellemiséggel.) Meglátszik a könyvön, hogy 2004-ben íródott, a Scrummal kapcsolatban például vannak pontatlan állítások benne (példa: 30 napos sprint).
A hangvétel telitalálat, valahol a kézikönyvön innen, a motivációs íráson túl. Kicsit azért száraz. Korábban olvastam tőle az "Agile Estimating and Planning"-et, az sokkal élvezetesebb.
A hangvétel telitalálat, valahol a kézikönyvön innen, a motivációs íráson túl. Kicsit azért száraz. Korábban olvastam tőle az "Agile Estimating and Planning"-et, az sokkal élvezetesebb.
July 22, 2018
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!
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!
November 28, 2020
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.
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.
February 20, 2018
Lucidly written. Great way to wrap your head around the topic. Has a good amount of examples to help one understand the concepts and process well.
Book feels a bit dated with (now laughable) lines like "Most software projects will do best with a new release every two to six months. Certain website projects may release even more frequently" but nonetheless most of the content felt useful even in 2018.
Book feels a bit dated with (now laughable) lines like "Most software projects will do best with a new release every two to six months. Certain website projects may release even more frequently" but nonetheless most of the content felt useful even in 2018.
February 16, 2021
Arranged like a textbook with questions answered in an appendix, this includes a historical arc of Agile from the innovations of Extreme Programming (XP). The User Story focus is weighted toward the physical collateral (index cards, etc.) and face-to-face collaboration on development, including thought-provoking, imaginative peronae writing. This is a very good, gentle introduction to the technique.
April 15, 2021
Unfortunately the material in the book is showing its age, and is in strong need of a refresh in 2021. The concepts are solid and as a very basic introduction to product owner activities it stands up and is reasonably practical. Where it misses is in covering the actual practice of writing user stories in greater depth with more complex examples such as writing stories in regulated environments, managing technical activities that are too large to be sub tasks and so on.
December 27, 2020
This isn’t too bad. The first three sections are the most beneficial. My biggest complaint would be that a lot of the situations and scenarios are pretty contrived best-case/worst-case which is on par for this genre. 🤷🏻♂️ That said, I found a few good nuggets in here though you can totally skip The Example covered in Part 4.
May 27, 2021
I enjoyed this book about user stories. It is a thorough look at why we break down development projects into stories and how they can be used. I particularly appreciated the concept of personas 'as a sales manager I want to track sales in realtime'. Towards the end there is a small introduction on XP as a coding style that I found fun. All in all a good if unremarkable read
August 10, 2017
Great book for those who are new for User Stories. It explains clearly and with many examples the User Stories lifecycle: from the user roles identification, creating personas, brainstorming the stories, making decomposition to esrtimation and progress tracking.
November 23, 2017
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.
I expected some budgeting and financial planing for projects and releases but didn't see them in this book.
April 1, 2019
This book gives some practical info about user stories and the examples included can help you understand how to write good user stories. Despite my concern that it might be a bit outdated, I feel like I will refer back to the book from time to time.
Displaying 1 - 30 of 137 reviews