====== How to write a good user story? ===== ===== Introduction ====== As a developer I would like to always work on well-defined stories with unambiguous goals and all required details to code the feature or do the change. As I didn't find any complete guide to write user stories showing examples, I decided to write my own check list. ===== Definition of Ready for user stories to enter the sprint backlog ====== When I first wrote this, I wanted to list all conditions which must be met to pull a backlog item into a sprint. If any condition isn't fulfilled, the backlog item shouldn't be included in the sprint. [[https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready|There some risks on this approach]], so I currently prefer to establish a process to improve the user stories more than to create a guard mechanism. ==== Mandatory ===== * Title with the goal of the story * Narrative description of the goal of the story * The business value is described (Valuable) * It is usually related to strategic goals and may take into account other stories * Acceptance criteria for the testing team (Testable) * They describe exactly what fields are seen, changed or used * They clearly indicate how to test the feature * Detailed description of what is required * Including where do the data come from * Including what fields are used, read or written * Including how the fields are shown * Separate Section **Scope** including what isn't included in the story * **Open Questions** section for the developers to ask questions before the backlog grooming meeting * No external dependencies blocking the item from being completed (Independent) * It is good to link the story with the predecessors and next stories * The size was estimated can be completed in one sprint (Small) * The estimation was done in the backlog grooming by the product owner and some developers * The story is prioritized compared to other stories in the product backlog * The development team has all required details to evaluate if the story can be finished fulfilling the definition of done in a sprint (Estimable) * Questions may always arouse during the sprint, this is expected. But it must be less frequent as the teams and the product owner learn about the business * The development team knows how to demo the story ==== Optional ===== * If the story involves changes in the frontend, the CSS, Javascript and HTML Code with the design is available * In projects were other team is responsible for the UI, you have to relax this requirement. Sometimes developers have to provide the design. * Performance criteria, if any, are defined and testable * Internationalization: How are the fields, frontend or API works on different languages and countries?   ===== Useful links ====== [[http://www.innolution.com/blog/definition-of-ready|Definition of ready]]\\ [[https://www.agilealliance.org/glossary/invest/|Meaning of INVEST]]