Methodology

Issue Type=EPIC > NAME and Summary will be annotated with "INITIATiVE: (description of new feature, functionality or work)"

Under issue Description add the following

Goal Required

• Limit to 1 or two short paragraphs, but can also be accomplished in a sentence or two.  This is to help contextualize the project for the digital team. Think about: why is this meaningful for NYPL (patrons, staff, etc), what does it support, who are the users, what systems does it unify, etc?  
• Include Strategic Alignment Goal

Launch Timeline/Date Required

• This may change as scope and resources shift, however try to add at least a general timeline, if possible.
  

Assumptions Required, if none put “N/A”

• Example Assumptions may be:
  • “Project A is complete, and live in production”
  • “This project does not need to use System X, but can be completed using an MVP work around.  Once System X is complete, we will assess if it can be used for this feature.”
  • “This feature is part of a larger effort with University Library B and Institution C.  As such, the exact launch date is dependant on their teams.”

• Different roles and individuals on the dev team may have different perspectives, use the “Assumptions” section to help level-set what the team knows and should expect.  There is no need to go into detail about items that team members already know, but it may be helpful to make a note to keep everyone on track.

• Usually a bulleted list.

MVP Scope Required

• List out major feature sets that are in MVP scope.  Keep in mind that the details for each of these feature sets will be captured in User Stories.  This is meant as quick guide for readers to understand what to expect from the project. This is specifically what is in MVP for this project -- what features absolutely must be completed in order of the project to launch/be considered done.

Nice to have Not Required

• If there are feature sets that would help shape the project into a better product, that the project is not dependant on, but would be good features to have to create a complete experience.
• Be honest, do not move nice to have items into MVP.  In most cases it is imperative for us not to jeopardize timelines.
• These features can fall to a future project phase, and may be considered MVP for the next or future phase.

Out of Scope Required, if none put “N/A’

• Be explicit about items that are out of scope for this phase.  (These items may be featured in other phases of a project.) This section is meant to help the team frame the scope and limits of the project.

High Level RACI

• (R)esponsible
• (A)ccountable
• (C)onsulted
• (I)nformed

UX Docs and Specs Required if there is any UX in the project

• Links to relevant UX documentation — use links here so that any updates will be captured in the epic.  
• Can include wireframes, but ideally links to final designs.
• Does not preclude UX User Stories, just allows for view into all of the relevant files

Notes/Additional Information Not Required

Can include tables, notes, things that do not fit in the above sections that the team should know.

Attach any relevant documentation about the overall project to the Epic

Link any Epics to your first Initiative Epic by using JIRA’s “link —> ticket relates to” feature.  Link related Stories directly to the Epic. (Note: if the project is small enough, you may not need these epics, and can link stories directly under the initiative.)

Items in bold represent the sections of an Epic:

Summary/Title:

• Should clearly state the segment/chunk of work as distinguished from other Epics in the project

Description:

• One or two sentences to describe what the segment of work is/why these are naturally grouped.  

Required if not using System Story

Title/Summary
User Stories describe the feature from the end-user perspective.  

Description

They are written in the first person, explicitly state who the user is, and what the reason is for the features.  They are written is prescribed manner to insure consistency and give a short-hand spec and purpose of what needs to be developed.

Format: As a ____, I need a way to/want to/must/etc ____, so that _____. Be specific as to who the user is.  “As a…” Whenever possible avoid using, “As a user…” as ‘user’ does not give any information about who the feature impacts.  The user should help to set up the context of the story.

• As a librarian…
• As a patron
• As a product searcher
• As a curator
• As a child visiting a branch library, Etc

If the feature is a software level that is not necessarily user facing, instead of the prescribed traditional user story, write a single sentence that describes what needs to be complete.  This descriptor should include as much detail as a user-facing story would, including the context of the feature, what is impacted, and why it is needed.

Acceptance Criteria (use as a section header) Required, for all kinds of stories.  

• If System Story, depending on the fidelity of the story, or if there are multiple given/then/when statements you may be able to have little to no Acceptance Criteria.
• This is a bulleted list of the conditions/specifications that the product must satisfy to be considered done (or “accepted”), by the user, QA, system, etc.
• In general, and in a TDD environment, acceptance criteria are written for the QA team, to ensure that the functionality meets the intended spec.  QA should base their tests on this list.
• Be as specific as possible here.  If you can include routes, urls, DB Tables, etc, do so -- the goal is to be as clear and obvious as possible.  
• HOWEVER, user stories should not dictate how the development team should architect, design, or develop the feature.  That is their domain, and will be specified in Dev Tasks

Analytics Note Required on relevant stories

Accessibility Note

• Required for all front/user facing stories

Notes Not required

• Add any information that is not covered by the user story or acceptance criteria that may be helpful
• Attach any relevant documents or images that help describe and add clarity.

Required if not using User Story

Title/Summary

• Feature — Terse yet descriptive text of what is desired in order to realize the business value.  “As a business actor, I want to gain some meaningful outcome.”
• Scenario — determinable business situation

Description

System stories can be used to describe software level stories, instead of (or in addition to) user behavior stories.  They are most often used in a Behavioral Driven Development or Test Driven Development, also called Cucumber Scenarios.  

• GIVEN — the system is in a known state/precondition
• WHEN — describes the key action, by system or user
• THEN — describes the observed outcome

You can use: “AND”, to describe multiple given/when/then conditions; “BUT NOT” to describe a condition that should not occur

Acceptance Criteria (use as a section header) Required, for all kinds of stories.  

• If System Story, depending on the fidelity of the story, or if there are multiple given/then/when statements you may be able to have little to no Acceptance Criteria.
• This is a bulleted list of the conditions/specifications that the product must satisfy to be considered done (or “accepted”), by the user, QA, system, etc.
• In general, and in a TDD environment, acceptance criteria are written for the QA team, to ensure that the functionality meets the intended spec.  QA should base their tests on this list.
• Be as specific as possible here.  If you can include routes, urls, DB Tables, etc, do so -- the goal is to be as clear and obvious as possible.  
• HOWEVER, user stories should not dictate how the development team should architect, design, or develop the feature.  That is their domain, and will be specified in Dev Tasks

Analytics Note Required on relevant stories

Accessibility Note

• Required for all front/user facing stories

Notes Not required

• Add any information that is not covered by the user story or acceptance criteria that may be helpful
• Attach any relevant documents or images that help describe and add clarity.