Merge pull request #905 from GSA/rj-user-story-to-html

Initial clean up of user stories

content/guides/effective_user_stories.md

@@ -33,19 +33,4 @@ When writing a user story, it requires key content:
 
 User story independence is ensured when the delivery increment has been fully decomposed; this allows for the appropriate tasking, estimation, sizing, and testability of the effort. The Product Owner negotiates the prioritization of the functionality with the Scrum Team against user needs, while the value of the user story drives its priority.
 
-Further, testability of the user story is captured in the acceptance criteria; it should denote the “The Who” _(user)_, “The What” _(capability)_, and “The Why” _(outcome)_ of the increment. For additional detail on writing user stories, check out our [User Story Examples](/assets/cms/files/UserStoryExamples.pdf), or review [Defining When a Requirement is Complete](/guides/requirements_complete/) on defining acceptance criteria.
-
-
-## Good Reads
-
-These are good references for writing user stories:
-
-* [5 Classic Mistakes Made While Writing User Stories](https://www.blueprintsys.com/blog/five-mistakes-writing-user-stories)
-* [10 Tips for Writing Good User Stories](http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/)
-* [How to Write Great Agile User Stories](https://sprint.ly/blog/agile-user-stories/)
-* [The Easy Way to Writing Good User Stories](http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/)
-* [Non-functional Requirements as User Stories](https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories)
-* [User Stories: An Agile Introduction](http://www.agilemodeling.com/artifacts/userStory.htm)
-* [User Stories: What is a User Story?](https://www.mountaingoatsoftware.com/agile/user-stories)
-* [Write a Great User Story](https://help.rallydev.com/writing-great-user-story)
-* [Your Best Agile User Story](http://www.alexandercowan.com/best-agile-user-story/)
+Further, testability of the user story is captured in the acceptance criteria; it should denote the “The Who” _(user)_, “The What” _(capability)_, and “The Why” _(outcome)_ of the increment. For additional detail on writing user stories, check out our [User Story Examples](/guides/effective_user_stories/), or review [Defining When a Requirement is Complete](/guides/requirements_complete/) on defining acceptance criteria.

content/guides/requirements_complete.md

@@ -23,7 +23,6 @@ Suggested user story criteria for meeting the [Definition of Ready (DoR)](/guide
 * Tasks identified
 * Card is estimated
 
-
 ## Definition of Done (DoD)
 
 Once a requirement is ready, the Team must agree to the steps necessary to accomplish it. Throughout each [status](/guides/visibility_and_status/) phase of development (typically represented by a column on a whiteboard or in a tool), the “rules” for passing it along to the next phase should also be clearly defined (e.g. the need for work to be reviewed by a peer prior to being sent to the next phase).
@@ -53,13 +52,3 @@ During UAT or review, user story criteria might include:
 * Successfully user acceptance tested
 
 Once the requirement, or user story meets the outlined criteria, it is finally considered done when approved by the product owner and accepted by stakeholders.
-
-
-## Good Reads
-
-These are good references when defining your Definition of Ready (DoR) or Definition of Done (DoD):
-
-* [Definition of Ready](https://www.agilealliance.org/glossary/definition-of-ready/)
-* [Definition of DONE! 10 Point Checklist](http://www.allaboutagile.com/definition-of-done-10-point-checklist/)
-* [Definition of Done](https://www.agilealliance.org/glossary/definition-of-done/)
-* [Multiple Levels of Done](https://www.mountaingoatsoftware.com/blog/multiple-levels-of-done)

content/guides/use_case_examples.md

@@ -6,12 +6,4 @@ category: Agile
 
 In acceptance testing, use cases provide a user (i.e. tester) direction without leading. Use Cases provide a sequence of steps in business terms, that describe the “happy path” for a specific interaction. Unlike system test cases, the use case interaction is defined in terms of the user, describing the user actions and experience versus the system inputs and outputs. The user compares their experience to the defined Success Criteria, documenting success or failure, along with any results. Results may expose bugs, defects, misspellings, updates to the user interface or process flow, or even new user stories identified.
 
-[Download this Sample Use Case Document](/assets/cms/media/draftusecasetemplate.xlsx)
-
-## Good Reads
-
-These are good references for incorporating Use Cases into user acceptance testing:
-
-* [Use Cases Are User Stories With Acceptance Tests](http://wiki.c2.com/?UseCasesAreUserStoriesWithAcceptanceTests)
-* [What is Use case testing in software testing?](http://istqbexamcertification.com/what-is-use-case-testing-in-software-testing/)
-* [Writing Test Cases from User Stories & Acceptance Criteria](https://blog.testlodge.com/writing-test-cases-from-user-stories-acceptance-criteria/)
+[Download this Sample Use Case Document](/assets/cms/media/draftusecasetemplate.xlsx)

content/guides/user_story_example.html

@@ -3,7 +3,7 @@
 category: Agile
 ---
 
-When <a href="/guides/effective_user_stories/">Writing Effective User Stories</a>, it is important to have descriptive summaries and detailed acceptance criteria to help the Team know when a user story is considered complete or “<a href="/guides/requirements_complete/">done</a>.” See the examples below:
+When <a href="/guides/effective_user_stories/">Writing Effective User Stories</a>, it is important to have descriptive summaries and detailed acceptance criteria to help the team know <a href="/guides/requirements_complete/">when a user story is considered complete or “done.”</a> See the examples below:
 
 <table>
   <thead>