{"id":1316,"date":"2011-02-07T19:39:57","date_gmt":"2011-02-08T03:39:57","guid":{"rendered":"http:\/\/lookforwardconsulting.com\/?p=1316"},"modified":"2024-03-05T12:36:17","modified_gmt":"2024-03-05T12:36:17","slug":"writing-good-user-stories","status":"publish","type":"post","link":"https:\/\/thescrumacademy.com\/es\/2011\/02\/07\/writing-good-user-stories\/","title":{"rendered":"Writing Good User Stories"},"content":{"rendered":"

User stories<\/a> are tool that originated from Extreme Programming and have become the de facto<\/em> way Agile teams document and collect their requirements. \u00a0There is a lot written on user stories (link<\/a>,\u00a0link<\/a>,\u00a0link), so I am just going to talk about what I consider important in writing good stories since I see a LOT<\/strong> of really bad ones out there today.<\/p>\n

For those who do not know, stories are a lightweight artifact that allows us to both capture the business’s needs AND<\/strong> plan the work. \u00a0They are typically written on index cards (yes…little 3×5 or 4×6 cards) in the language of the business or customer. \u00a0With user stories, we only write enough to capture the user’s needs and no more. \u00a0We tend to view stories not as complete specification of the requirements, but as placeholders for later conversations between the developers and the business.<\/p>\n

When used properly, a user story’s lack of detail provides us a great deal of utility – we can use the same document to talk about a requirement from a high-level, zoom in on implementation details and jump back out, all in the course of a few sentences. \u00a0Then once we are done talking about requirements, we can consider risk, identify dependencies and create a project plan without ever having to put down the index card. \u00a0Wow !! \u00a0I know of no other requirements artifacts out there allows us such utility.<\/p>\n

Over the years people who are really successful with stories have settled on some commonalities found in all stories:<\/p>\n