Project:Sandbox

\r\n\r\n= \u200b\u200b\u200b\u200bUser Stories\u200b\u200b\u200b =\r\n\r\n \r\n\r\n\r\n\u200b Purpose: \r\nUser stories describe customer software requirements from a particular user\'s perspective that will deliver some value to the business.\r\n\r\n== Description: ==\r\n\r\nUser stories are a critical component in the software development lifecycle at R+L Carriers. For the requirements gathering phase, the user story is the final decomposition of the epics and features that make up the project. User stories are used to capture functional and non-functional requirements in the form of acceptance criteria, which add certainty to a story and express expected outcome without ambiguity.\r\n\r\nAcceptance Criteria are conditions of satisfaction, each with a clear pass/fail result, that specify both functional and non-functional requirements, inputs/outputs, conditions, and expected outcomes. Acceptance criteria must be expressed clear, concise, and simple manner. Our user stories utilize three types of criteria, functional, non-functional, and performance.\xa0\r\n\r\nIn communication with the business team, user stories can be used for prioritization efforts and to measure the value being delivered. In communication with the technical team, user stories form the basis for product development, estimation and design, and the basis for QA test plan and test case creation. The development team will break user stories down into 1-n tasks that need completed to deliver the story.\r\n\r\n== Required Location/Tools: ==\r\n\r\nCreated in iRise or TFS. Task top integration will ensure that the user story makes its way into each platform.\r\n\r\n== Format: ==\r\n\r\n=== Template ===\r\n\r\n \r\n\r\n\r\n==== General User Story ====\r\n\r\nTitle: [Human-readable description of value being delivered. Often pre-fixed with verbiage indicating functional area]\r\n\r\nBusiness Value: [As a [Role], I want to be able to [perform action X] so that I can [realize benefit Y]]\r\n\r\nFunctional Criteria: [Identifies specific tasks, functions, processes, or logic that must be in place. Your Gherkin scenarios will go here.]\r\n\r\nNon-functional Criteria: [Identifies specific conditions the implementation must meet, such as design elements,\xa0system constraints, or appropriate data mapping. Each section should tie back to a specific Gherkin scenario]\r\n\r\nPerformance Criteria: [If specific performance is critical to the acceptance of a user story, then it should be included.\xa0This is often measured as a response time or system up-time]\r\n\r\n\'\'\'\xa0\'\'\'\r\n\r\n==== Technical User Story ====\r\n\r\nThe only difference between a technical and general user story is that the business value does not adhere to the RGB format and the acceptance criteria does not adhere to a Gherkin format. The RGB format should be a brief description of why the change is needed and for what feature and the acceptance criteria should be a bulleted list detailing the necessary changes.\xa0\r\n\r\nBusiness Value: [Brief description of value being delivered to the business or project]\u200b\r\n\r\n \r\n\r\n\r\n== Minimum Required components ==\r\n\r\nUser stories are required on every project and each element, if applicable, must be included.\r\n\r\n \r\n\r\n\r\n== Example:\u200b ==\r\n\r\n \r\n\r\n\r\n \'\'\'Business Value:\'\'\' \r\n\r\nAs a LH mgr, I want the ability to create new full turn links into the system so that I have the ability to dispatch between terminals as dictated by operational necessity.\r\n\r\n\xa0\r\n\r\n \'\'\'Functional Criteria:\'\'\'  \r\n\r\n\xa0\r\n\r\n\'\'\'Scenario 1\'\'\': System validates all required fields have been entered on the create new full turn link screen\r\n\r\n\'\'\'Given\'\'\': LH Dispatcher has not filled out a\xa0\'\'\'[required field]\'\'\'\xa0for a full-turn link\r\n\r\n\'\'\'When\'\'\': LH Dispatcher clicks button: Create New Link\r\n\r\n\'\'\'Then\'\'\': LH system displays\xa0\'\'\'[message]\'\'\'\xa0to the user\r\n\r\n* LH system highlights the missing\xa0\'\'\'[required field]\'\'\'\r\n\r\n\'\'\'Example:\'\'\'\r\n\r\n{|\r\n| \'\'\'Required Field\'\'\'\r\n| \'\'\'Message\'\'\'\r\n|-\r\n| Origin Terminal\r\n| & quot;Origin terminal needs selected & quot;\r\n|-\r\n| Destination Terminal\r\n| & quot;Destination terminal needs selected & quot;\r\n|-\r\n| Mileage Entry\r\n| & quot;Mileage must be entered in the appropriate format & quot;\r\n|}\r\n\r\n \r\n\r\n\r\n \xa0 \r\n\r\n== Anti-pattern(s): ==\r\n\r\n* Thinking that \'\'everything\'\' must be a user story or in the Gherkin\r\n* Making user stories that are too big\r\n* Not reviewing user stories in detail with the development and QA team\r\n* Not providing traceability back to higher-level analysis\r\n\r\n== Useful Links: ==\r\n\r\nhttps://techbeacon.com/essential-guide-user-story-creation-agile-leaders\r\n\r\nhttp://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/\r\n\r\nhttp://martinfowler.com/bliki/UserStory.html\r\n\r\nhttp://agileforall.com/new-to-agile-invest-in-good-user-stories/\r\n\r\nhttp://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how\u200b\r\n\r\nhttps://www.agileconnection.com/article/identifying-and-improving-bad-user-stories\r\n\r\nhttps://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-make-writing-user-stories\u200b\r\n\r\n \r\n\r\n\r\n\r\n  \r\n