{"id":5003366,"date":"2015-12-17T00:19:07","date_gmt":"2015-12-17T08:19:07","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003366"},"modified":"2024-05-10T11:35:10","modified_gmt":"2024-05-10T18:35:10","slug":"user-stories","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/user-stories\/","title":{"rendered":"User Stories"},"content":{"rendered":"<p>In consultation with the customer or\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/product-owner\/\">product owner<\/a>, the team divides up the work to be done into functional increments called \u201cuser stories.\u201d<\/p>\n<p>Each user story is expected to yield, once implemented, a contribution to the value of the overall product, irrespective of the order of implementation; these and other assumptions as to the nature of user stories are captured by the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/invest\/\">INVEST<\/a>\u00a0formula.<\/p>\n<p>To make these assumptions tangible, user stories are reified into a physical form: an index card or sticky note, on which a brief descriptive sentence is written to serve as a reminder of its value. This emphasizes the \u201catomic\u201d nature of user stories and encourages\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Direct_manipulation_interface\">direct physical manipulation<\/a>: for instance, decisions about scheduling are made by physically moving around these \u201cstory cards.\u201d<\/p>\n<h2>Common Pitfalls<\/h2>\n<ul>\n<li>a classic mistake consists, in teams where the Agile approach is confined to the development team or adopted after a non-Agile requirements phase, to start from a requirements document in narrative format and derive user stories directly based on its structure: for instance one story for each section of the document<\/li>\n<li>as the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/three-cs\/\">3 C\u2019s<\/a> model emphasizes, a user story is not a document; the term encompasses all of the knowledge required to transform version V of the product into version V\u2019 which is more valuable with respect to a particular goal<\/li>\n<li>the level of detail corresponding to a user story is not constant, it evolves over time as a function of the \u201cplanning horizon\u201d; for instance, a user story that is scheduled for the next iteration should be better understood than one which will not be implemented until the next release<\/li>\n<li>a user story is not a Use Case; although it is often useful to compare and contrast the two notions, they are not equivalent and do not admit a one-to-one mapping<\/li>\n<li>a user story does not in general correspond to a technical or user interface component: even though it may sometimes be a useful shortcut to talk about e.g. \u201cthe search dialog story\u201d, screens, dialog boxes, and buttons are not user stories<\/li>\n<\/ul>\n<h2>Expected Benefits<\/h2>\n<p>For most Agile teams user stories are the main vehicle of\u00a0<a href=\"http:\/\/guide.agilealliance.org\/guide\/incremental.html\">incremental<\/a>\u00a0software delivery, and offer the following benefits:<\/p>\n<ul>\n<li>mitigating the risks of delayed feedback, all the more so<\/li>\n<li>if the increments are small<\/li>\n<li>if the software is\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/frequent-release\/\">released<\/a>\u00a0to production frequently<\/li>\n<li>for the customer or product owner, the option to change their mind on the details or the scheduling priority of any user story not yet implemented<\/li>\n<li>for developers, being given clear and precise acceptance criteria, and ongoing feedback as they complete work<\/li>\n<li>promoting a clear separation of responsibilities between defining the \u201cwhat\u201d (province of the customer or product owner) and the \u201chow\u201d (province of the technical team), leveraging the skills and creativity of each<\/li>\n<\/ul>\n<h2>Potential Costs<\/h2>\n<p><a href=\"https:\/\/agilealliance.org\/glossary\/incremental-development\/\">Incremental development<\/a> in general, and the \u201cnano-incremental\u201d strategy embodied in user stories in particular, have significant impacts on projects\u2019 testing strategies, and in particular all but mandate significant test automation.<\/p>\n<p>This follows from the so-called \u201c<a href=\"http:\/\/www.hans-eric.com\/wp-content\/uploads\/2011\/05\/Incremental-development-and-regression-testing.pdf\">quadratic growth<\/a>\u201d problem: after the implementation of feature F1 it is normal to test that feature. After the implementation of feature F2, the risk of regression dictates re-testing F1 as well as testing F2. A test sequence assuming incremental development therefore goes: F1,F1+F2,F1+F2+F3, etc. \u2013 this grows as the square of the number of features, and can therefore quickly become unmanageable as projects grow in size. Test automation (in a particular <a href=\"http:\/\/guide.agilealliance.org\/guide\/unittest.html\">unit<\/a>\u00a0and\u00a0<a href=\"http:\/\/guide.agilealliance.org\/guide\/acceptance.html\">acceptance<\/a>\u00a0testing) mitigates this effect, although it does come at a cost.<\/p>\n<h2>Origins<\/h2>\n<p>User Stories originate with\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/xp\/\">Extreme Programming<\/a>, their first written description in 1998 only claims that customers define project scope \u201cwith user stories, which are like use cases\u201d. Rather than offered as a distinct practice, they are described as one of the \u201cgame pieces\u201d used in the \u201cplanning game\u201d.<\/p>\n<p>However, most of the thrust of further writing centers around all the ways user stories are \u201cunlike\u201d use cases, in trying to answer in a more practical manner \u201chow requirements are handled\u201d in Extreme Programming (and more generally Agile) projects. This drives the emergence, over the years, of a more sophisticated account of user stories.<\/p>\n<ul>\n<li>cf. the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/role-feature\/\">Role-feature-benefit template<\/a>, 2001<\/li>\n<li>cf. the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/three-cs\/\">3 C\u2019s model<\/a>, 2001<\/li>\n<li>cf. the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/invest\/\">INVEST checklist<\/a>, 2003<\/li>\n<li>cf. the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/gwt\/\">Given-When-Then template<\/a>, 2006<\/li>\n<\/ul>\n<h2>Signs Of Use<\/h2>\n<ul>\n<li>the team uses visual planning tools (release plan,\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/story-mapping\/\">story map<\/a>,\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/taskboard\/\">task board<\/a>) and index cards or stickies on these displays to reflect product features<\/li>\n<li>the labels on cards that stand for user stories contain few or no references to technical elements (\u201cdatabase\u201d, \u201cscreen\u201d or \u201cdialog\u201d) but generally refer to end users\u2019 goals<\/li>\n<\/ul>\n<h2>Skill Levels<\/h2>\n<p>An Agile team will benefit if the skills that underpin the effective use of user stories are widely distributed among the team; however, it is likely that people with a background in \u201crequirements analysis\u201d or with a history in \u201canalyst\u201d roles will have a leg up in acquiring these skills.<\/p>\n<p>As an individual contributor:<\/p>\n<p>Beginner<\/p>\n<ul>\n<li>able to start from another formalism for requirements (narrative document, use cases) and transpose that to user stores<\/li>\n<li>knows at least one standard format for expressing user stories<\/li>\n<li>able to illustrate a user story with an example (including the user\u2019s goal, existing context, user\u2019s actions, and expected outcomes)<\/li>\n<\/ul>\n<p>Intermediate<\/p>\n<ul>\n<li>able to divide up the functional goals of a development effort into user stories (possibly\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/epic\/\">epics<\/a>), ensuring no gaps are left<\/li>\n<li>knows several formats for expressing user stories and can choose the most appropriate one<\/li>\n<li>able to express the acceptance criteria for a user story in terms that will be directly usable as an automated\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/acceptance\/\">acceptance test<\/a><\/li>\n<li>knows or can identify the relevant user roles and populations and refers to them appropriately in user stories<\/li>\n<li>can assess a user story using the INVEST checklist or an equivalent, and rephrase or\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/split\/\">split<\/a>\u00a0the user story as necessary<\/li>\n<\/ul>\n<p>Advanced<\/p>\n<ul>\n<li>able to interpret so-called \u201cnon-functional requirements\u201d in terms of user stories<\/li>\n<li>able to link user stories to higher-level descriptions of project goals (e.g. <a href=\"https:\/\/agilealliance.org\/glossary\/project-chartering\/\">project charter<\/a>) and to provide grounds for the relevance and business value of each user story<\/li>\n<\/ul>\n<p>Collectively, as a team:<\/p>\n<p>Beginner<\/p>\n<ul>\n<li>the team organizes project activities around user stories<\/li>\n<li>the team is able to obtain, \u201cjust in time\u201d, the information necessary to implement user stories, for instance by having access to the product owner or domain expert<\/li>\n<\/ul>\n<p>Intermediate<\/p>\n<ul>\n<li>the team formalizes all activity as work on user stories, each team member can answer at any moment the question \u201cwhat user story are you working on at the moment\u201d<\/li>\n<\/ul>\n<p>Advanced<\/p>\n<ul>\n<li>at any moment, any member of the team can answer the question \u201cwhat is the most important user story in the backlog, and why\u201d<\/li>\n<\/ul>\n<h2>Further Reading<\/h2>\n<ul>\n<li><a href=\"http:\/\/www.amazon.com\/User-Stories-Applied-Software-Development\/dp\/0321205685\">User Stories Applied<\/a>, by Mike Cohn<\/li>\n<li><a href=\"http:\/\/www.amazon.com\/Software-Numbers-Low-Risk-High-Return-Development\/dp\/0131407287\">Software By Numbers<\/a>\u00a0examines the economics of iterative software development<\/li>\n<\/ul>\n<h2>Academic Publications<\/h2>\n<ul>\n<li><a href=\"http:\/\/faculty.ksu.edu.sa\/zohair\/Documents\/CSC541\/Chap2-SWE%20processes\/Agile%20Requirements%20Eng.pdf\">\u201cAgile requirements engineering practices: An empirical study\u201d<\/a>\u00a0discusses an investigation of 16 software development organizations\u2019 Agile requirements practices, and provides an overview of some previous literature on Agile requirements and user stories. (The study takes a mildly adversarial attitude to Agile and comes to somewhat strange conclusions, such as ranking\u00a0<a href=\"http:\/\/guide.agilealliance.org\/guide\/tdd.html\">test-driven development<\/a>\u00a0among requirements engineering practices.)<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>In consultation with the customer or product owner, the team divides up the work to be done into functional increments called &#8220;user stories.&#8221;<\/p>\n","protected":false},"author":8027401,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[908],"tags":[802,805],"class_list":["post-5003366","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-process","tag-incremental-development","tag-invest"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003366","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8027401"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003366"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003366\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003366"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003366"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003366"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}