diff --git a/assets/images/structuring_tickets/structure-bug1.png b/assets/images/structuring_tickets/structure-bug1.png
new file mode 100644
index 0000000..90df6fc
Binary files /dev/null and b/assets/images/structuring_tickets/structure-bug1.png differ
diff --git a/assets/images/structuring_tickets/structure-bug2.png b/assets/images/structuring_tickets/structure-bug2.png
new file mode 100644
index 0000000..187fc2d
Binary files /dev/null and b/assets/images/structuring_tickets/structure-bug2.png differ
diff --git a/assets/images/structuring_tickets/structure-figma-attachment.png b/assets/images/structuring_tickets/structure-figma-attachment.png
new file mode 100644
index 0000000..4836b1f
Binary files /dev/null and b/assets/images/structuring_tickets/structure-figma-attachment.png differ
diff --git a/assets/images/structuring_tickets/structure-overview.png b/assets/images/structuring_tickets/structure-overview.png
new file mode 100644
index 0000000..7ea70e9
Binary files /dev/null and b/assets/images/structuring_tickets/structure-overview.png differ
diff --git a/assets/images/structuring_tickets/structure-speclet1.png b/assets/images/structuring_tickets/structure-speclet1.png
new file mode 100644
index 0000000..54353f7
Binary files /dev/null and b/assets/images/structuring_tickets/structure-speclet1.png differ
diff --git a/assets/images/structuring_tickets/structure-speclet2.png b/assets/images/structuring_tickets/structure-speclet2.png
new file mode 100644
index 0000000..91e39b7
Binary files /dev/null and b/assets/images/structuring_tickets/structure-speclet2.png differ
diff --git a/assets/images/structuring_tickets/structure-story.png b/assets/images/structuring_tickets/structure-story.png
new file mode 100644
index 0000000..d2108b7
Binary files /dev/null and b/assets/images/structuring_tickets/structure-story.png differ
diff --git a/assets/images/structuring_tickets/structure-tasks.png b/assets/images/structuring_tickets/structure-tasks.png
new file mode 100644
index 0000000..0df732a
Binary files /dev/null and b/assets/images/structuring_tickets/structure-tasks.png differ
diff --git a/index.md b/index.md
index 39907c0..7e648b9 100644
--- a/index.md
+++ b/index.md
@@ -31,7 +31,8 @@ Feel free to explore, and if anything catches your attention or raises questions
- [Design Principles](product_design/design_principles.md)
- [Design Review Best Practices](product_design/design-review-best-practices.md)
- [Giving and Receiving Feedback](product_design/giving-and-receiving-design-feedback.md)
-- [How to Write User Stories](/product_design/how_we_write_user_stories.md)
+- [Epics and User Stories](/product_design/how_we_write_user_stories.md)
+- [Structuring Epics, Stories, Bugs and Tasks(product_design/structuring_epics_stories_bugs_and_tasks.md)
- [Accessibility](product_design/accessibility_guide.md)
diff --git a/product_design/design-review-best-practices.md b/product_design/design-review-best-practices.md
index af32791..b2ca791 100644
--- a/product_design/design-review-best-practices.md
+++ b/product_design/design-review-best-practices.md
@@ -1,7 +1,10 @@
# Design Review Best Practices
+* Contents
+{:toc}
+
### The goal of design reviews
-Design is an iterative and collaborative process. It takes many conversations to get from an initial idea to a complete product. Early conversations may be about getting alignment on the problem space. Other conversations may be about getting sign off to start building the design in code. For the purposes of this guide, we are looking at conversations we'll call "design reviews."
+Design is an iterative and collaborative process. It takes many conversations to get from an initial idea to a complete product. Early conversations may be about getting alignment on the problem space. Other conversations may be about getting sign off to start building the design in code. For the purposes of this guide, we are looking at conversations meant to get feedback on work in progress. We'll call these conversations "design reviews."
Design reviews give us an opportunity to step back and look at the work critically. This type of conversation helps us ensure our designs are on track. A design review has two goals. First, we must understand the design in context. Next, we give feedback to improve the design so it best meets our business objectives and the needs of our users.
diff --git a/product_design/giving-and-receiving-design-feedback.md b/product_design/giving-and-receiving-design-feedback.md
index adf76f5..e073a2e 100644
--- a/product_design/giving-and-receiving-design-feedback.md
+++ b/product_design/giving-and-receiving-design-feedback.md
@@ -1,10 +1,14 @@
# Giving and receiving design feedback effectively takes practice
-It’s not always easy to give and receive design feedback. A negative past experience might make a designer hesitant to ask for or participate in a review. Unfortunately, we can’t produce good work without getting or giving feedback.
+
+It’s not always easy to give and receive design feedback. A negative past experience or feeling uncertain about what to say might make us hesitant to ask for or participate in a review. Unfortunately, we can’t produce good work without getting or giving feedback.
Practicing giving and receiving feedback will help us grow as a team. This guide provides an overview of behaviors to strive for in a design review. We don't have to get them right each time, but making an effort counts.
+* Contents
+{:toc}
+
## Best practices for giving feedback
-The goal of giving feedback is to help evaluate a design in terms of how well the design meets its objectives. As feedback givers, we have a duty to our teammates to be thoughtful. There are several ways we can give thoughtful feedback:
+The goal of giving feedback is to help evaluate a design in terms of how well the design meets its objectives. We want to lift the idea up and make it stronger, not tear it down. As feedback givers, we have a duty to our teammates to be thoughtful. There are several ways we can give thoughtful feedback:
### Lead with questions
Asking questions about the design helps us give informed feedback. It shows the designer you’re interested in both their work and their reasoning behind it. Delivering feedback on an incorrect assumption could take the conversation off track. Asking questions helps you determine if your assumption is accurate. The resulting feedback is more likely to be relevant to the objectives.
@@ -31,7 +35,7 @@ It may seem odd to go through the process of identifying problems with a design
One exception to this guideline: when a designer asks for this type of help. It's okay to brainstorm solutions if both parties have agreed to have this type of conversation. If you're not sure if a designer is asking for this type of help, ask.
-
+---
## Best practices for receiving feedback
When asking for feedback, we are taking a step back from the generative phase to look critically at our work and how well it meets our design goals. As feedback receivers, our duty is to listen and remember that critique is about improving the design, not a judgment of us as individuals. There are several ways we can engage as feedback recipients:
@@ -48,7 +52,10 @@ If this is a follow-up critique and the reviewer contradicts their earlier feedb
If you’re struggling to both listen and take notes, consider having someone take notes for you. Another option is to take notes on a whiteboard or in a document visible to the team. This visibility will also help you and the team be sure you’re on the same page.
-If you want praise, don’t hesitate to ask: “What about this design is working well?” Don’t expect a design review itself to be a source of praise.
+### It's okay to ask for praise
+If you want praise, don’t hesitate to ask: “What about this design is working well?”
+Don’t expect a design review itself to be a source of praise.
+
### Participate
You’re allowed to critique your work, too. Try picking one of the personas and imagining what this design might be like for them. Are they able to meet their goals? This activity helps you practice critiquing skills and strengthens your ability to switch between the creative mindset and the analytical mindset. It can put the other reviewers at ease to see you talk openly about your own work.
@@ -56,10 +63,12 @@ You’re allowed to critique your work, too. Try picking one of the personas and
### Stay on target
If you feel like your discussion is getting off topic or you’re getting feedback that seems out of left field, refer to the context you set in the beginning. Is everyone on the same page? If they aren’t, we either need more alignment, or we may need to reevaluate our foundation.
+If you find your discussions frequently get off topic, review our guide, [Design Review Best Practices](../product_design/design-review-best-practices.md), for tips on how to structure the converstation for best results.
+
---
-**Sources**
+#### Sources
[Adam Connor and Aaron Irizarry, *Discussing Design* (O’Reilly, 2015.)](http://www.discussingdesign.com/)
Available in handy cheat-sheet form: [http://www.discussingdesign.com/downloads/Critique_CheatSheet.pdf](http://www.discussingdesign.com/downloads/Critique_CheatSheet.pdf)
diff --git a/product_design/how_we_write_user_stories.md b/product_design/how_we_write_user_stories.md
index 8caf079..b36728c 100644
--- a/product_design/how_we_write_user_stories.md
+++ b/product_design/how_we_write_user_stories.md
@@ -1,105 +1,89 @@
-## Why write user stories?
+## Epics and User Stories
-Lab Zero writes user stories to place a product’s users at the center of our thinking and decision-making. User stories also support our ability to validate product hypotheses, deliver value early, often and predictably, make better trade-offs, and prioritize effectively.
+* Contents
+{:toc}
-**Stories generate interest, empathy and vision.** At the highest level, stories embody the things that make your product worth building — who it’s for and what they can do to achieve their goals. If your team isn’t aligned on these core goals, they won’t know how to prioritize their work to achieve the greatest outcomes for the least effort.
+## The role of Epics and User Stories in our work
-**Stories focus conversation.** A story allows the team to make multiple confirmations of the task throughout the development process. This begins with agreement on the task to be done, and later, how it will pass acceptance testing.
+Epics and User Stories are tools that focus our conversation around what to build and why. At the highest level, they embody the things that make our product worth building — who it’s for and what that person can do with the product to achieve their goals.
-## What is needed before we write user stories?
+- Epics describe the vision and the outcomes we are striving to achieve and how we intend to measure success.
+- User stories generate empathy and alignment around a discrete effort and how that work will benefit the user. Writing user stories helps us come to an agreement on what needs to be done and what criteria we will use to tell when the work is complete.
-**Map the customer’s experience.** Armed with your customer research (you’ve defined personas based on qualitative and quantitative research, right?) put yourself in the customer’s shoes and map their journey as you understand it today.
+This document describes the best practices we aspire to. Not every project will follow this approach exactly. We’ll rely on our team norming sessions to decide how to adapt this approach so that it best supports the team in the context of their project.
-**Define a clear goal.** Review your map with the project’s stakeholders to confirm your current understanding and agree upon a single experience or interaction which matches a single business outcome. Clarify the riskiest assumption, define your hypothesis, and explain how you will test and measure success.
+## Writing Epics and User Stories is a collaborative process
+We believe writing Epics and User Stories is a collaborative process between the Product Manager, the Designer, and a Lead Engineer. In addition to the responsibilities described below, we highly encourage our teams to pair throughout the process.
-**Draft a design.** Designs help clarify to the entire team what will be done. They naturally tease out edge cases. Discuss with your team what fidelity of design is right for your situation.
+### The Product Manager is responsible for clear epics.
+The Product Manager is responsible for defining the value the product should deliver based on our current understanding of the customer’s goals, the desired business outcomes, and priorities.
-## Story Structure
+### The Designer is responsible for the clear, actionable user stories… *unless it’s a technically-focused ticket.*
+When we translate a design into tickets ready for engineering, the Designer is the person with the greatest knowledge of the user experience and what requirements need to be reflected in the ticket. That does not mean design must do this work alone. Product and Engineering feedback is valuable here and the Designer may consider scheduling time to pair to ensure tickets are clear.
-**[User] --> [does or sees something] + [optional qualifiers] --> in order to [accomplish a clear goal].**
+*The exception is when the user story does not have a design component.* In these cases, someone else is the expert. These types of tickets may be written by the Product Manager or the Lead Engineer with input from Design.
-#### User…
+### The Lead Engineer will always be consulted on epics and design-focused stories… *and is also responsible for clear, actionable technically-focused stories when needed.*
+Without an engineering perspective, all our epics and stories are just wishes. Engineering provides a critical perspective into feasibility. They need to be kept in the loop so their team is aligned on the why behind our work. They should be consulted early and often. The Lead Engineer should have weighed in on context and design well before a ticket makes it to Backlog Prioritization.
-Choose a personal or functional role within your system.
+## Why do we approach Epics and User Stories this way?
+Our approach enables
+- the **Product Manager** to focus on the **“why,”**
+- the **Designer** to focus on the **“what,”**
+- the **Engineering team** to focus on the **“how,”**
-#### …does or sees [something]” + [optional qualifiers]
+While encouraging **conversation and collaboration** along the way.
-Be concrete but not overly verbose - let the design fill in the details.
+## Our Approach: From Epic to User Story to Sprint
+The full kickoff-to-backlog process is outlined in the [Discovery Journey Map](https://www.figma.com/file/I8gn3uTpbA7dakZu7xdUjj/LZ-discovery-journey-map-%5BWIP%5D?node-id=0%3A1).
-#### ...in order to [accomplish a goal].
+The list below describes the best practices we aspire to. Not every project will follow this approach exactly. We’ll rely on our team norming sessions to decide how to adapt this approach so that it best supports the team in the context of their project.
-Describe the outcome the user achieves.
+1. **Draft speclet**
+The Product Manager begins by writing a speclet that will serve as a stand-in for the epic. High-level user stories focusing on user needs are added to this document as the Discovery progresses.
+2. **Begin design**
+When the Designer has enough context on the problem (from the speclet and discovery) they begin work on designs.
+3. **Create Epic in Jira**
+Product Manager creates the Epic(s) and possibly shell user story tickets in Jira.
+Follow [this guidance](../product_design/structuring_epics_stories_bugs_and_tasks.md#epics) on epics.
+4. **Add User Stories to the Epic**
+When designs are agreed on, the Designer prepares the designs for handoff and [writes detailed user stories based on the designs](../product_design/structuring_epics_stories_bugs_and_tasks.md##user-stories). *If the epic doesn’t have a user interface, it may be more appropriate for the Lead Engineer to write the user stories.*
+5. **Preview stories**
+The Product Manager, Designer, and Lead Engineer review all stories before Storytime and estimation.
+6. **Initial prioritization**
+Product Manager prioritizes stories before Storytime so that we estimate the highest priority tickets first.
+7. **Storytime (estimation)**
+PM and Designer schedule a Storytime meeting with the sprint team.
+- If the Designer wrote the story, they take the lead in talking through it.
+- Stories are discussed and estimated by those involved in delivering the story.
+- Stories may be broken down into smaller tickets if needed
+- User stories must have an estimation before they are considered ready to be included in a sprint.
+8. **Final prioritization**
+PM reprioritizes the backlog before Sprint Planning and Kickoff. This helps ensure the highest priority tickets are ready for the next sprint and the backlog is prioritized with this new work.
+9. **Sprint Planning**
+Meeting where we align our commitments for the next sprint with our actual capacity.
+Further information on [Sprint Ceremonies can be found here](../project_kickoff/ceremonies.md).
-## Acceptance Criteria
+## Our responsibilities during the sprint
+### Answering Questions
+If questions come up during the sprint, the Designer is the first line to answer the question. They may pull the Product Manager and/or the Lead Engineer into the conversation if needed.
-The description in your story should provide additional context and clarify what will be tested when the story is delivered.
+### Accepting User Stories
+On a pre-defined environment (for example, a Staging site), we verify that the work delivered meets the Acceptance Criteria before accepting the story.
-Consider trying the “Given-When-Then” formula, a template intended to guide the writing of acceptance tests ([Gherkin](https://cucumber.io/docs/gherkin/)). It is likely that the developer will write automated tests based on your story, some tests may match the criteria you use to accept the work.
+**Right person, right story, right time.** It is important to understand who on the team has the proper skills to accept the story at hand.
+- Design or interaction-heavy stories should be accepted by a designer, preferably the individual who created the design.
+- If you can’t verify an engineering task, don’t accept the story — find a developer who can.
+- Do not allow delivered stories to sit for more than a day without acceptance testing. This can unnecessarily lengthen the feedback loop, reducing positive momentum and allowing the team to forget the specifics of the work.
-* Given [some context, this is the pre-condition to the activity]
-* When [some action is carried out]
-* Then [a particular change or set of changes you expect due to the specified action]
+**Reject early, reject often.** The Reject action is the flag to begin a conversation. You are not saying that the effort put forth has no value, just that the Acceptance Criteria have not yet been met.
+- Comments must be added along with steps to reproduce any unmet criteria. Work out with your team the right amount of information to add when rejecting.
+- Consider using software like [Licecap](https://www.cockos.com/licecap/) if an animated gif may help clarify the actions you have performed.
-Here's an example of a login story.
->_Feature: As a user I want to sign in and see my orders_
->
->__Scenario: User supplies correct username and password__
->_Given that I am on the log in page_
->_When I enter my username and password correctly_
->_And click 'Sign in'_
->_Then I am taken to my dashboard showing my orders_
->
->__Scenario: User does NOT supply correct username and password__
->_Given that I am on the log in page_
->_When I enter my username and password incorrectly_
->_And click 'Sign in'_
->_Then I see an error message ‘Sorry, incorrect user name or password.”_
+
+
-To clarify the standard for completion for all stories in the backlog, define your team’s technical “Definition of Done” in a visible place at the beginning a project. For example, at Lab Zero, completing a story requires not only implementing it and fulfilling the acceptance criteria, but also writing tests, running test suites and using pull requests to merge code.
-
-## Who writes the stories?
-
-Lab Zero likes to have the product owner write epics, and the designer write user stories.
-
-Why?
-
-It helps plant the product owner firmly in the problem space: defining the value the product should deliver based on our current understanding of the customer’s goals, the desired business outcomes and priorities.
-
-This empowers the designer to work creatively on the customer experience moment-to-moment — the interaction patterns, design principles, edge cases.
-
-We’ve seen a number of problems arise if user stories are written prior to or without the designer’s involvement:
-
-* Design doesn’t have enough time to fully consider the customer experience. Instead, they’re forced to design based on a list of tactical stories possibly written from the business owner’s perspective, instead of the user’s.
-* The pre-written stories don’t match the final design, and dev has to reconcile the inconsistencies before starting work.
-* The stories are incomplete. It’s hard to anticipate all the edge cases of a feature before it’s gone through the design process.
-
-## Story Time
-
-Team partnership and peer review is essential to achieve strong alignment and buy-in.
-
-**Early peer review:** After the designer has written stories, the product owner should review and provide feedback on the first draft. A second pair of eyes helps ensure focus and clarity of content. It also gives the product owner time to review the backlog as a whole to confirm that it represents the scope and priority of work.
-
-**Full team review:** The designer presents each story in the backlog to the full team for feedback and estimation. Common results of an effective team review:
-
-* Stories are sized
-* Missed edge cases are exposed
-* Hidden technical work is revealed (and added to the backlog)
-* Stories are re-prioritized
-* Proposed solutions are reconsidered and stories are decomposed/rewritten
-
-**Prioritization:** Through team discussion, the team should have a good understanding of how they intend to deliver value in an incremental fashion. Now the product owner can take one more shot at the backlog to meet prioritized business & customer goals, produce a vertical slice, and/or reduce inter-story dependencies in the same sprint.
-
-## Working on a user story
-
-An effective user story stands on its own but is strengthened by the context you already know about the project. Whether you’re a designer working on an epic, or a developer working on an interaction story, do not work on a story that is unclear. Find time to clarify the task with the right person before moving forward.
-
-Delivering: a story should be marked as delivered after it’s been merged to the proper environment and the test suite passes.
-
-## Accepting user stories
-
-You must be able to verify on a pre-defined environment that the work delivered meets the Acceptance Criteria before accepting the story.
-
-**Right person, right story, right time.** It is important to understand who on the team has the proper skills to accept the story at hand. Design or interaction-heavy stories should be accepted by a designer, preferably the individual who created the design. If you can’t verify an engineering task, don’t accept the story — find a developer who can. Do not allow delivered stories to sit for more than a day without acceptance testing. This can unnecessarily lengthen the feedback loop, reducing positive momentum and allowing the team to forget the specifics of the work.
-
-**Reject early, reject often.** The Reject action is the flag to begin a conversation. You are not saying that the effort put forth has no value, just that the Acceptance Criteria have not yet been met. Comments must be added along with steps to reproduce any unmet criteria. Work out with your team the right amount of information to add when rejecting. Consider using software like [Licecap](https://github.com/justinfrankel/licecap) if an animated gif may help clarify the actions you have performed.
\ No newline at end of file
+## Related pages
+- [Development Workflow](../continuous_delivery/development_workflow.md) guide
+- [Definition of Ready and Done](https://labzero.com/blog/essential-working-agreements-ready-and-done) blog post
diff --git a/product_design/structuring_epics_stories_bugs_and_tasks.md b/product_design/structuring_epics_stories_bugs_and_tasks.md
new file mode 100644
index 0000000..48c39e5
--- /dev/null
+++ b/product_design/structuring_epics_stories_bugs_and_tasks.md
@@ -0,0 +1,142 @@
+# Structuring Epics, Stories, Bugs and Tasks
+* Contents
+{:toc}
+
+This page summarizes what an Epic, User Story, Bug, and Task is and documents our best practices for how they should be structured. Not every project will follow these practices. We’ll rely on our team norming sessions to adapt ticket writing practices so they best support the team in the context of their project.
+
+Guidance on our approach to [writing Epics and User Stories](../product_design/how_we_write_user_stories.md) can be found here.
+
+
+
+
+
+---
+## Initiatives
+Initiatives are a collection of epics that drive towards a common goal (for example: “expand in to Australia” or “launch a new product that decreases costs by 7% this year”). An initiative is broader than a single epic, and may span multiple teams and multiple quarters.
+
+## Epics
+Epics convey the overall big picture priorities. They contain a group of stories (on a particular theme) that are too big to be described by a single user story. Epics are written concisely and in a way that is simple to understand.
+- Epics are specific, achievable, and completable. They don’t exist forever.
+- The speclet becomes the Epic once there is alignment on it. ***The Jira Epic links to the speclet.***
+- Speclets are generally written and owned by the Product Manager.
+- Epics do not have estimates and are likely to span multiple sprints.
+- An epic may include a hypothesis. A hypothesis justifies the change and specifies what difference you expect to see as a result. The hypothesis should be based on data and include links to the data source.
+
+### Structure of a speclet:
+**Title:** Concise summary of the epic.
+
+**Problem Summary:** A description of the problem this epic addresses.
+
+**Vision:** A brief summary of the future state that could be achieved by completing this epic.
+
+**Stakeholders:** A list of the primary stakeholders impacted by this epic, with a very brief (one-line) description of their role.
+
+**Desired outcomes:** Including metrics where possible.
+
+**High-level user stories:** High-level stories that will later be broken down into user stories for the engineering team. These are added to the speclet during the Discovery process.
+
+**Notes:** Links to relevant documents.
+
+#### Example speclet:
+
+
+
+
+
+### Example Epic in Jira:
+**Title:** Concise summary of the epic.
+
+**Description:** Link to the speclet.
+
+
+---
+
+
+## User stories
+- User stories describe a small, discrete, testable piece of functionality from the perspective of the person who desires the new capability (usually a user or customer of the system).
+- The fibonacci sequence is used for estimating (1, 2, 3, 5, 8). Any story with more than 3 points should be broken down into smaller stories.
+ - Read about why we use these numbers in these articles by [Mike Cohn](https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating).
+- Every story should have an Acceptor assigned. The Acceptor is usually decided in Storytime.
+- Subtitles within the story should be bold, and bullet points or numbers used where possible.
+- All user stories should be part of an epic. There are multiple user stories in an epic.
+- Stories represent a full slice of functionality (ie including front end and back end).
+
+All user stories must be:
+
+| Letter | Meaning | Description |
+|:--------|:-------|:--------|
+| I | [Independent](https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Independent) | The user story should be self-contained. |
+| N | [Negotiable](https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Negotiable) | User stories are not explicit contracts and should leave space for discussion. |
+| V | [Valuable](https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Valuable) | A user story must deliver value to customers. |
+| E | [Estimable](https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Estimable) | You must always be able to estimate the size of a user story. A user story should not be larger than a team can complete in one sprint. If it exceeds this time-box, it should be split in a way that still delivers value to a customer. Ideally user stories should be sized so that they are estimated to be done in half a sprint or less so that the team has visibility on their progress. |
+| S | [Small](https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Small) | User stories should not be so big as to become impossible to plan and prioritize. |
+| T | [Testable](https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Testable) | The user story or its related description must provide the necessary information to make test development possible. |
+
+
+
+### Structure of a user story:
+**Summary:** The title of the ticket (which shows up in the Backlog list). Short, descriptive, and easy to scan. If possible putting the user first.
+
+**Description:** Expands on the title, explaining who wants the functionality, why and to what end. Format:
+
+**Why** In order to *...reason why the user would need to do this activity*,
+**Who** I, the *...persona name, with link to their persona page*,
+**What** *...need/ want/ etc.*
+
+**Acceptance criteria:** A numbered list of functionality that the Designer or Product Manager will use to test that the story has been completed. Stories can’t be rejected for a requirement that isn’t stated here (new tickets should instead be created to cover the missed criteria).
+
+**Out of scope:** Calls out any non-obvious functionality that is out of scope.
+
+**Relevant tickets:** Closely related tickets that the developer should be aware of when working on this one. Use the “Link issue” feature or link to the tickets from the acceptance criteria.
+
+**Resources:** Links to relevant designs, user flows, etc. Link to the original design (eg a screen in a Figma file) where possible, rather than attaching images to the story.
+
+#### Example user story:
+
+
+
+---
+## Bugs
+- Bugs address exceptions in a story or task that was delivered.
+- If a story has bugs that prevent it from meeting the acceptance criteria then the story should be rejected, with the bugs noted in the comments.
+ - If the bug isn’t a blocker it can make more sense to accept the story and create a new bug in the backlog.
+- Bugs shouldn’t be added to an active sprint unless they are a blocker.
+- Bugs can be written by the Product Manager, Designer, Engineering or Developers. They are prioritized by Product.
+- Bugs are not estimated.
+
+### Structure of a bug:
+**Title:** Short and descriptive, describing the problem. Example: Product Drive doesn’t display in IE11.
+
+**Test environment:** Short description of the environment used when the issue was experienced. This should include which browser (including version number) and which device.
+
+**Prerequisites:** Any prerequisites required to experience the issue.
+
+**Steps to recreate:** Steps taken to reproduce the issue.
+
+**Results and Expected results:** State what the result of the steps is, and what the result should be. Include images where possible.
+
+**Attachments:** Screenshots and/ or video are attached clearly showing the issue.
+
+#### Examples:
+
+
+
+---
+## Tasks
+- Tasks capture actionable events that need to occur during development but which don’t provide direct, obvious value to the user.
+ - The output of tasks usually isn’t visible to users: ie nothing is functionally or visually different about the product when the task is done.
+- In general, these tasks should align with one or more stories in the current sprint. Rogue tasks should at least raise questions about the relative priority.
+- Tasks do not require estimation (although it can better inform a story estimate).
+- Tasks are prioritized by the Product Manager.
+
+### Structure of a task:
+*Title:* Short description of the task
+
+*Description:* Full summary of the task, using bullet points.
+
+*Resources:* Links to any relevant resources.
+
+
+
+### Structure of a design ticket:
+(Coming soon!)