Re-add definition of done and definition of ready (#8)

_articles/definition-of-done.md

@@ -0,0 +1,68 @@
+---
+title: Definition of Done
+layout: article
+redirect_from:
+- /articles/definition_of_done.html
+- /articles/definition_of_done
+category: Product
+---
+
+All stories must comply with the current Definition of Done in order to be considered Complete and Accepted. Some items might not apply to all stories, and conscious exceptions are OK.
+
+Expect this DoD to change over time.
+
+### Engineering
+
+- 0 errors 0 warnings in CodeClimate
+- Tests have been written. New or modified features have feature coverage. Code coverage of the entire test suite is not reduced
+- Ensure that our accessibility posture has been maintained or improved, preferably via automated `aXe` tests
+- All code and tests have been merged to master in GitHub repo
+- The `application.yml` configurations have been updated as needed in deployed environments
+Database indexes exist for any new queries
+- The dashboard and sample SPs have been updated if necessary
+- If multiple database migrations are necessary, the database migrations have been performed
+- The story is deployed to Dev and/or INT environments
+- Appropriate refactoring has been done as part of developing the story
+  - Modified slim files are converted to HTML-ERB
+  - Dead code has been pruned
+  - The login.gov design system is used in views
+- New code must be free of medium and highlevel static and dynamic security vulnerabilities as reported by Snyk
+- If the story will not be ready to be released to users or there is a serious possibility of failure then the changes are behind a feature flag
+- Analytics logging has been updated and new events have been added if needed
+
+### Design
+
+- Interface / user journey changes are approved by design folks in order to release the story to production, or the story is controlled by a Feature Flag
+- If a usability test is necessary, a usability test plan has been developed or there is a Jira issue for it
+- Conforms to Section 508 standards by both manual and automated scanning methods
+- The new design uses components from the design system
+- Notify the design team when a new design component is not yet in the design system, so it can be added and the team can be notified. 
+- New components that aren’t a part of the design system are added if they’re used frequently
+- Graphics and mockups are saved in [design repository](https://github.com/18f/identity-design-assets). If private mockup/design, save in login drive / design folder
+- User journey/interface are connected to user personas and listed in the login handbook. 
+
+### Content
+
+- Content changes are written, reviewed and approved.
+- Content changes are complete for the contact center email templates and knowledge articles.
+
+### Documentation
+
+- If there is a potential security impact someone has told `@Mo` about it
+- If we are affecting storage or transmission of PII somebody has told the privacy officer `@richard.speidel`
+- The release management guide has been updated for changes to the deploy process
+- The [Entity Relationship Diagrams](https://github.com/18F/identity-idp/blob/master/docs/ARCHITECTURE.md#entity-relationship-diagram) have been updated if the db schema has changed.
+- The help content on the static site has been updated and new FAQ content has been created if necessary
+- User journey/interface are connected to user personas and listed in the login handbook. 
+
+### Comms
+
+- A description of the change has been written for the release notes to be communicated to partners
+- A description of the change has been communicated to the contact center
+- In extreme cases, a description of the change has been written and communicated directly to users
+
+### Acceptance
+
+- PO accepts that user story and acceptance criteria have been fulfilled
+- Design accepts feature for release to users if applicable
+- Team asserts that all other applicable aspects of the DoD have been met

_articles/definition-of-ready.md

@@ -0,0 +1,51 @@
+---
+title: Definition of Ready
+description: Best practices for tracking issues in JIRA
+layout: article
+category: Product
+---
+
+A good JIRA ticket has all of the information and context for any team member
+to pick it up and understand what's going on. We have a few different types of
+JIRA tickets, and slightly different expectations for each.
+
+## Stories
+
+Stories are told from user perspectives (where users can't be the login.gov
+team). They're written in the form *"as **X**, I want to **Y** so that **Z**."*
+For example:
+
+> As a user, I want to provide consent when an SP asks for how current my verified
+> information is, so that I have full control of what login.gov is sharing about me.
+
+Often stories list out **AC**s, or **Acceptance Criteria**, for example
+
+- User is asked for consent when an SP asks for it for the first time only
+  (either IAL1 or IAL2)
+- Existing users who are already associated with an SP will be asked for consent
+  for the freshness value
+
+
+## Bugs
+
+Bugs should clearly explain what is happening, and what should be happening
+instead.
+
+For example:
+
+> The "Sign in" button is currently green, but per our style guide, it should be
+> blue.
+
+Additional context is always useful, such as:
+
+- Clear steps to reproduce
+- Browser and operating system version
+- Links to more information (such as Salesforce ticket or Slack conversation links)
+
+## Tasks
+
+Tasks are JIRA tickets that track important work on our team. Specific examples include:
+> * Enginering: Backfills, code refactors, etc.
+> * UX: Writing research plans, designing a new layout, etc.
+
+Differentiating between tasks and stories allows us to gauge whether the output of our efforts (all the work we do) has induced outcomes (tangible user impact). It provides indicators to the team to gauge whether we need to revisit our stories and tasks Examples: were there too many unknowns taking on a story, can some tasks be structured to be stories etc.