User Stories Applied: For Agile Software Development

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.

ForewordxvAcknowledgmentsxviiIntroductionxixPart IGetting Started1Chapter 1An Overview3What Is a User Story?4Where Are the Details?5"How Long Does It Have to Be?"7The Customer Team8What Will the Process Be Like?8Planning Releases and Iterations10What Are Acceptance Tests?12Why Change?13Summary15Questions15Chapter 2Writing Stories17Independent17Negotiable18Valuable to Purchasers or Users20Estimatable22Small23Testable27Summary28Developer Responsibilities28Customer Responsibilities28Questions29Chapter 3User Role Modeling31User Roles31Role Modeling Steps33Two Additional Techniques37What If I Have On-Site Users?39Summary40Developer Responsibilities40Customer Responsibilities41Questions41Chapter 4Gathering Stories43Elicitation and Capture Should Be Illicit43A Little Is Enough, or Is It?44Techniques45User Interviews45Questionnaires47Observation48Story-Writing Workshops49Summary52Developer Responsibilities53Customer Responsibilities53Questions53Chapter 5Working with User Proxies55The Users' Manager55A Development Manager57Salespersons57Domain Experts58The Marketing Group59Former Users59Customers59Trainers and Technical Support61Business or Systems Analysts61What to Do When Working with a User Proxy61Can You Do It Yourself?63Constituting the Customer Team63Summary64Developer Responsibilities65Customer Responsibilities65Questions66Chapter 6Acceptance Testing User Stories67Write Tests Before Coding68The Customer Specifies the Tests69Testing Is Part of the Process69How Many Tests Are Too Many?70The Framework for Integrated Test70Types of Testing72Summary73Developer Responsibilities73Customer Responsibilities73Questions74Chapter 7Guidelines for Good Stories75Start with Goal Stories75Slice the Cake75Write Closed Stories76Put Constraints on Cards77Size the Story to the Horizon78Keep the UI Out as Long as Possible79Some Things Aren't Stories80Include User Roles in the Stories80Write for One User81Write in Active Voice81Customer Writes81Don't Number Story Cards82Don't Forget the Purpose82Summary82Questions83Part IIEstimating and Planning85Chapter 8Estimating User Stories87Story Points87Estimate as a Team88Estimating88Triangulate90Using Story Points91What If We Pair Program?92Some Reminders93Summary94Developer Responsibilities94Customer Responsibilities95Questions95Chapter 9Planning a Release97When Do We Want the Release?98What Would You Like in It?98Prioritizing the Stories99Mixed Priorities100Risky Stories101Prioritizing Infrastructural Needs101Selecting an Iteration Length103From Story Points to Expected Duration103The Initial Velocity104Creating the Release Plan105Summary106Developer Responsibilities106Customer Responsibilities107Questions107Chapter 10Planning an Iteration109Iteration Planning Overview109Discussing the Stories110Disaggregating into Tasks111Accepting Responsibility113Estimate and Confirm113Summary115Developer Responsibilities115Customer Responsibilities116Questions116Chapter 11Measuring and Monitoring Velocity117Measuring Velocity117Planned and Actual Velocity119Iteration Burndown Charts121Burndown Charts During an Iteration123Summary126Developer Responsibilities127Customer Responsibilities127Questions127Part IIIFrequently Discussed Topics131Chapter 12What Stories Are Not133User Stories Aren't IEEE 830133User Stories Are Not Use Cases137User Stories Aren't Scenarios141Summary143Questions143Chapter 13Why User Stories?145Verbal Communication145User Stories Are Comprehensible148User Stories Are the Right Size for Planning148User Stories Work for Iterative Development149Stories Encourage Deferring Detail150Stories Support Opportunistic Development151User Stories Encourage Participatory Design152Stories Build Up Tacit Knowledge153Why Not Stories?153Summary154Developer Responsibilities155Customer Responsibilities155Questions155Chapter 14A Catalog of Story Smells157Stories Are Too Small157Interdependent Stories157Goldplating158Too Many Details159Including User Interface Detail Too Soon159Thinking Too Far Ahead160Splitting Too Many Stories160Customer Has Trouble Prioritizing161Customer Won't Write and Prioritize the Stories162Summary162Developer Responsibilities163Customer Responsibilities163Questions163Chapter 15Using Stories with Scrum165Scrum Is Iterative and Incremental165The Basics of Scrum166The Scrum Team166The Product Backlog167The Sprint Planning Meeting168The Sprint Review Meeting170The Daily Scrum Meeting171Adding Stories to Scrum173A Case Study174Summary175Questions176Chapter 16Additional Topics177Handling NonFunctional Requirements177Paper or Software?179User Stories and the User Interface181Retaining the Stories184Stories for Bugs185Summary186Developer Responsibilities186Customer Responsibilities187Questions187Part IVAn Example189Chapter 17The User Roles191The Project191Identifying the Customer191Identifying Some Initial Roles192Consolidating and Narrowing193Role Modeling195Adding Personas197Chapter 18The Stories199Stories for Teresa199Stories for Captain Ron202Stories for a Novice Sailor203Stories for a Non-Sailing Gift Buyer204Stories for a Report Viewer204Some Administration Stories205Wrapping Up206Chapter 19Estimating the Stories209The First Story210Advanced Search212Rating and Reviewing213Accounts214Finishing the Estimates215All the Estimates216Chapter 20The Release Plan219Estimating Velocity219Prioritizing the Stories220The Finished Release Plan221Chapter 21The Acceptance Tests223The Search Tests223Shopping Cart Tests224Buying Books225User Accounts226Administration227Testing the Constraints228A Final Story229Part VAppendices231Appendix AAn Overview of Extreme Programming233Roles233The Twelve Practices234XP's Values240The Principles of XP241Summary242Appendix BAnswers to Questions245Chapter 1, An Overview245Chapter 2, Writing Stories246Chapter 3, User Role Modeling247Chapter 4, Gathering Stories248Chapter 5, Working with User Proxies249Chapter 6, Acceptance Testing User Stories249Chapter 7, Guidelines for Good Stories249Chapter 8, Estimating User Stories251Chapter 9, Planning a Release251Chapter 10, Planning an Iteration252Chapter 11, Measuring and Monitoring Velocity252Chapter 12, What Stories Are Not253Chapter 13, Why User Stories?254Chapter 14, A Catalog of Story Smells255Chapter 15, Using Stories with Scrum255Chapter 16, Additional Topics256References259Index263