ISBN-10:
0321205685
ISBN-13:
9780321205681
Pub. Date:
03/01/2004
Publisher:
Addison-Wesley
User Stories Applied: For Agile Software Development / Edition 1

User Stories Applied: For Agile Software Development / Edition 1

by Mike Cohn, Kent Beck
Current price is , Original price is $54.99. You

Temporarily Out of Stock Online

Please check back later for updated availability.

Product Details

ISBN-13: 9780321205681
Publisher: Addison-Wesley
Publication date: 03/01/2004
Series: Addison-Wesley Signature Series (Beck) Series
Edition description: New Edition
Pages: 268
Sales rank: 482,225
Product dimensions: 7.00(w) x 9.15(h) x 0.85(d)

About the Author

Mike Cohn is the founder of Mountain Goat Software, a process and project management consultancy and training firm. With more than twenty years of experience, Mike has been a technology executive in companies ranging from start-ups to Fortune 40s, and is a founding member of the Agile Alliance. He frequently contributes to industry-related magazines and presents regularly at conferences. He is the author of User Stories Applied (Addison-Wesley, 2004).

Read an Excerpt

I felt guilty throughout much of the mid-1990s. I was working for a company that was acquiring about one new company each year. Every time we'd buy a new company I would be assigned to run their software development group. And each of the acquired development groups came with glorious, beautiful, lengthy requirements documents. I inevitably felt guilty that my own groups were not producing such beautiful requirements specifications. Yet, my groups were consistently far more successful at producing software than were the groups we were acquiring.

I knew that what we were doing worked. Yet I had this nagging feeling that if we'd write big, lengthy requirements documents we could be even more successful. After all, that was what was being written in the books and articles I was reading at the time. If the successful software development teams were writing glorious requirements documents then it seemed like we should do the same. But, we never had the time. Our projects were always too important and were needed too soon for us to delay them at the start.

Because we never had the time to write a beautiful, lengthy requirements document, we settled on a way of working in which we would talk with our users. Rather than writing things down, passing them back and forth, and negotiating while the clock ran out, we talked. We'd draw screen samples on paper, sometimes we'd prototype, often we'd code a little and then show the intended users what we'd coded. At least once a month we'd grab a representative set of users and show them exactly what had been coded. By staying close to our users and by showing them progress in small pieces, we had found a way to be successful without the beautiful requirements documents.

Still, I felt guilty that we weren't doing things the way I thought we were supposed to.

In 1999 Kent Beck's revolutionary little book, Extreme Programming Explained: Embrace Change, was released. Overnight all of my guilt went away. Here was someone saying it was OK for developers and customers to talk rather than write, negotiate, and then write some more. Kent clarified a lot of things and gave me many new ways of working. But, most importantly, he justified what I'd learned from my own experience. Extensive upfront requirements gathering and documentation can kill a project in many ways. One of the most common is when the requirements document itself becomes a goal. A requirements document should be written only when it helps achieve the real goal of delivering some software.

A second way that extensive upfront requirements gathering and documentation can kill a project is through the inaccuracies of written language. 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."

Words, especially when written, are a very thin medium through which to express requirements for something as complex as software. With their ability to be misinterpreted we need to replace written words with frequent conversations between developers, customers, and users. User stories provide us with a way of having just enough written down that we don't forget and that we can estimate and plan while also encouraging this time of communication.

By the time you've finished the first part of this book you will be ready to begin the shift away from rigorously writing down every last requirement detail. By the time you've finished the book you will know everything necessary to implement a story-driven process in your environment. This book is organized in four parts and two appendices.

Part I: Getting Started—A description of everything you need to know to get started writing stories today. One of the goals of user stories is to get people talking rather than writing. It is the goal of Part I to get you talking as soon as possible. The first chapter provides an overview of what a user story is and how you'll use stories. The next chapters in Part I provide additional detail on writing user stories, gathering stories through user role modeling, writing stories when you don't have access to real end users, and testing user stories. Part I concludes with a chapter providing guidelines that will improve your user stories.

Part II: Estimating and Planning—Equipped with a collection of user stories, one of the first things we often need to answer is "How long will it take to develop?" The chapters of Part II cover how to estimate stories in story points, how to plan a release over a three- to six-month time horizon, how to plan an ensuing iteration in more detail, and, finally, how to measure progress and assess whether the project is progressing as you'd like.

Part III: Frequently Discussed Topics—Part III starts by describing how stories differ from requirements alternatives such as use cases, software requirements specifications, and interaction design scenarios. The next chapters in Part III look at the unique advantages of user stories, how to tell when something is going wrong, and how to adapt the agile process Scrum to use stories. The final chapter of Part III looks at a variety of smaller issues such as whether to writes stories on paper note cards or in a software system and how to handle nonfunctional requirements.

Part IV: An Example—An extended example intended to help bring everything together. If we're to make the claim that developers can best understand user's needs through stories then it is important to conclude this book with an extended story showing all aspects of user stories brought together in one example.

Part V: Appendices—User stories originate in Extreme Programming. You do not need to be familiar with Extreme Programming in order to read this book. However, a brief introduction to Extreme Programming is provided in Appendix A. Appendix B contains answers to the questions that conclude the chapters.

Table of Contents



Foreword.


Acknowledgments.


Introduction.

I: GETTING STARTED.


1: An Overview.

What Is a User Story?

Where Are the Details?

“How Long Does It Have to Be?”

The Customer Team.

What Will the Process Be Like?

Planning Releases and Iterations.

What Are Acceptance Tests?

Why Change?

Summary.

Questions.


2: Writing Stories.

Independent.

Negotiable.

Valuable to Purchasers or Users.

Estimatable.

Small.

Testable.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


3: User Role Modeling.

User Roles.

Role Modeling Steps.

Two Additional Techniques.

What If I Have On-Site Users?

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


4: Gathering Stories.

Elicitation and Capture Should Be Illicit.

A Little Is Enough, or Is It?

Techniques.

User Interviews.

Questionnaires.

Observation.

Story-Writing Workshops.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


5: Working with User Proxies.

The Users' Manager.

A Development Manager.

Salespersons.

Domain Experts.

The Marketing Group.

Former Users.

Customers.

Trainers and Technical Support.

Business or Systems Analysts.

What to Do When Working with a User Proxy.

Can You Do It Yourself?

Constituting the Customer Team.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


6: Acceptance Testing User Stories.

Write Tests Before Coding.

The Customer Specifies the Tests.

Testing Is Part of the Process.

How Many Tests Are Too Many?

The Framework for Integrated Test.

Types of Testing.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


7: Guidelines for Good Stories.

Start with Goal Stories.

Slice the Cake.

Write Closed Stories.

Put Constraints on Cards.

Size the Story to the Horizon.

Keep the UI Out as Long as Possible.

Some Things Aren't Stories.

Include User Roles in the Stories.

Write for One User.

Write in Active Voice.

Customer Writes.

Don't Number Story Cards.

Don't Forget the Purpose.

Summary.

Questions.

II: ESTIMATING AND PLANNING.


8: Estimating User Stories.

Story Points.

Estimate as a Team.

Estimating.

Triangulate.

Using Story Points.

What If We Pair Program?

Some Reminders.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


9: Planning a Release.

When Do We Want the Release?

What Would You Like in It?

Prioritizing the Stories.

Mixed Priorities.

Risky Stories.

Prioritizing Infrastructural Needs.

Selecting an Iteration Length.

From Story Points to Expected Duration.

The Initial Velocity.

Creating the Release Plan.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


10: Planning an Iteration.

Iteration Planning Overview.

Discussing the Stories.

Disaggregating into Tasks.

Accepting Responsibility.

Estimate and Confirm.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


11: Measuring and Monitoring Velocity.

Measuring Velocity.

Planned and Actual Velocity.

Iteration Burndown Charts.

Burndown Charts During an Iteration.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.

III: FREQUENTLY DISCUSSED TOPICS.


12: What Stories Are Not.

User Stories Aren't IEEE 830.

User Stories Are Not Use Cases.

User Stories Aren't Scenarios.

Summary.

Questions.


13: Why User Stories?

Verbal Communication.

User Stories Are Comprehensible.

User Stories Are the Right Size for Planning.

User Stories Work for Iterative Development.

Stories Encourage Deferring Detail.

Stories Support Opportunistic Development.

User Stories Encourage Participatory Design.

Stories Build Up Tacit Knowledge.

Why Not Stories?

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


14: A Catalog of Story Smells.

Stories Are Too Small.

Interdependent Stories.

Goldplating.

Too Many Details.

Including User Interface Detail Too Soon.

Thinking Too Far Ahead.

Splitting Too Many Stories.

Customer Has Trouble Prioritizing.

Customer Won't Write and Prioritize the Stories.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.


15: Using Stories with Scrum.

Scrum Is Iterative and Incremental.

The Basics of Scrum.

The Scrum Team.

The Product Backlog.

The Sprint Planning Meeting.

The Sprint Review Meeting.

The Daily Scrum Meeting.

Adding Stories to Scrum.

A Case Study.

Summary.

Questions.


16: Additional Topics.

Handling NonFunctional Requirements.

Paper or Software?

User Stories and the User Interface.

Retaining the Stories.

Stories for Bugs.

Summary.

Developer Responsibilities.

Customer Responsibilities.

Questions.

IV: AN EXAMPLE.


17: The User Roles.

The Project.

Identifying the Customer.

Identifying Some Initial Roles.

Consolidating and Narrowing.

Role Modeling.

Adding Personas.


18: The Stories.

Stories for Teresa.

Stories for Captain Ron.

Stories for a Novice Sailor.

Stories for a Non-Sailing Gift Buyer.

Stories for a Report Viewer.

Some Administration Stories.

Wrapping Up.


19: Estimating the Stories.

The First Story.

Advanced Search.

Rating and Reviewing.

Accounts.

Finishing the Estimates.

All the Estimates.


20: The Release Plan.

Estimating Velocity.

Prioritizing the Stories.

The Finished Release Plan.


21: The Acceptance Tests.

The Search Tests.

Shopping Cart Tests.

Buying Books.

User Accounts.

Administration.

Testing the Constraints.

A Final Story.

V: APPENDICES.


Appendix A: An Overview of Extreme Programming.

Roles.

The Twelve Practices.

XP's Values.

The Principles of XP.

Summary.


Appendix B: Answers to Questions.

Chapter 1, An Overview.

Chapter 2, Writing Stories.

Chapter 3, User Role Modeling.

Chapter 4, Gathering Stories.

Chapter 5, Working with User Proxies.

Chapter 6, Acceptance Testing User Stories.

Chapter 7, Guidelines for Good Stories.

Chapter 8, Estimating User Stories.

Chapter 9, Planning a Release.

Chapter 10, Planning an Iteration.

Chapter 11, Measuring and Monitoring Velocity.

Chapter 12, What Stories Are Not.

Chapter 13, Why User Stories?

Chapter 14, A Catalog of Story Smells.

Chapter 15, Using Stories with Scrum.

Chapter 16, Additional Topics.


References.

Index.

Preface

I felt guilty throughout much of the mid-1990s. I was working for a company that was acquiring about one new company each year. Every time we’d buy a new company I would be assigned to run their software development group. And each of the acquired development groups came with glorious, beautiful, lengthy requirements documents. I inevitably felt guilty that my own groups were not producing such beautiful requirements specifications. Yet, my groups were consistently far more successful at producing software than were the groups we were acquiring.

I knew that what we were doing worked. Yet I had this nagging feeling that if we’d write big, lengthy requirements documents we could be even more successful. After all, that was what was being written in the books and articles I was reading at the time. If the successful software development teams were writing glorious requirements documents then it seemed like we should do the same. But, we never had the time. Our projects were always too important and were needed too soon for us to delay them at the start.

Because we never had the time to write a beautiful, lengthy requirements document, we settled on a way of working in which we would talk with our users. Rather than writing things down, passing them back and forth, and negotiating while the clock ran out, we talked. We’d draw screen samples on paper, sometimes we’d prototype, often we’d code a little and then show the intended users what we’d coded. At least once a month we’d grab a representative set of users and show them exactly what had been coded. By staying close to our users and by showing them progress in small pieces, we had found a way to be successful without the beautiful requirements documents.

Still, I felt guilty that we weren’t doing things the way I thought we were supposed to.

In 1999 Kent Beck’s revolutionary little book, Extreme Programming Explained: Embrace Change, was released. Overnight all of my guilt went away. Here was someone saying it was OK for developers and customers to talk rather than write, negotiate, and then write some more. Kent clarified a lot of things and gave me many new ways of working. But, most importantly, he justified what I’d learned from my own experience. Extensive upfront requirements gathering and documentation can kill a project in many ways. One of the most common is when the requirements document itself becomes a goal. A requirements document should be written only when it helps achieve the real goal of delivering some software.

A second way that extensive upfront requirements gathering and documentation can kill a project is through the inaccuracies of written language. 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."

Words, especially when written, are a very thin medium through which to express requirements for something as complex as software. With their ability to be misinterpreted we need to replace written words with frequent conversations between developers, customers, and users. User stories provide us with a way of having just enough written down that we don’t forget and that we can estimate and plan while also encouraging this time of communication.

By the time you’ve finished the first part of this book you will be ready to begin the shift away from rigorously writing down every last requirement detail. By the time you’ve finished the book you will know everything necessary to implement a story-driven process in your environment. This book is organized in four parts and two appendices.

Part I: Getting Started-A description of everything you need to know to get started writing stories today. One of the goals of user stories is to get people talking rather than writing. It is the goal of Part I to get you talking as soon as possible. The first chapter provides an overview of what a user story is and how you’ll use stories. The next chapters in Part I provide additional detail on writing user stories, gathering stories through user role modeling, writing stories when you don’t have access to real end users, and testing user stories. Part I concludes with a chapter providing guidelines that will improve your user stories.

Part II: Estimating and Planning-Equipped with a collection of user stories, one of the first things we often need to answer is "How long will it take to develop?" The chapters of Part II cover how to estimate stories in story points, how to plan a release over a three- to six-month time horizon, how to plan an ensuing iteration in more detail, and, finally, how to measure progress and assess whether the project is progressing as you’d like.

Part III: Frequently Discussed Topics-Part III starts by describing how stories differ from requirements alternatives such as use cases, software requirements specifications, and interaction design scenarios. The next chapters in Part III look at the unique advantages of user stories, how to tell when something is going wrong, and how to adapt the agile process Scrum to use stories. The final chapter of Part III looks at a variety of smaller issues such as whether to writes stories on paper note cards or in a software system and how to handle nonfunctional requirements.

Part IV: An Example-An extended example intended to help bring everything together. If we’re to make the claim that developers can best understand user’s needs through stories then it is important to conclude this book with an extended story showing all aspects of user stories brought together in one example.

Part V: Appendices-User stories originate in Extreme Programming. You do not need to be familiar with Extreme Programming in order to read this book. However, a brief introduction to Extreme Programming is provided in Appendix A. Appendix B contains answers to the questions that conclude the chapters.


Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews

User Stories Applied 4.3 out of 5 based on 0 ratings. 11 reviews.
Guest More than 1 year ago
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.
Anonymous 28 days ago
jrep on LibraryThing 10 months ago
Clear, readable, quick-moving yet substantive, this book combines a thorough introduction into the concept and uses of user stories, with insights into their strengths relative to similar or confusing tools like "use cases."
Dangraham on LibraryThing 10 months ago
Good book about new processes we can use to create software for end users.
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Guest More than 1 year ago
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. 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.
Guest More than 1 year ago
Devising the specifications for a software project can be a squishy affair. A programmer may not be skilled at eliciting requirements from users. This can be very much a qualitative, fuzzy interaction. Far removed from writing of code, where one can usually objectively measure the functionality. But Cohn points out that the users' needs cannot be ignored for the project to be successful. He says that in the drawing up of these needs, the effort should be equally influenced by both the users and the programmers. An imbalance here can adversely affect the usefulness of the project. He devotes the book towards what he says the group should draw up. User stories. These are functionalities needed by the eventual users. He considers user stories to be of lesser scope than use cases, where the latter may be better known to most. The main merit of a user story seems to be that it involves a 'bite-sized' programming effort. He suggests less than 10 days of development. So that a team could quickly iterate through several development cycles, with the cost of a bad choice of user story being small.