Beginning on 9/18 you will be able to change your enterprise password from within Jira!

Skip to end of metadata
Go to start of metadata

Overview


Major portions of the platform will be developed as Projects.  The projects will consist of initiatives focused on delivering key features or functionality. To work within the Agile Paradigm and JIRA (our tool for project management and development) initiatives will be managed as EPICS.  Typically referenced as a THEME, the project will annotate the EPIC as an INITIATIVE. The INITIATIVE will be further divided into traditional EPICS (User Story arcs) that describe the user journey.   EPICS are further broken down into a series of USER STORIES to describe the specific feature or functionality from a users perspective.  Lastly, the USER STORY is broken into discrete development TASK for development.

EPICS


 

Initiative Epics and their use in JIRA

The projects product Road Map is managed in Jira.  For describing the an initiative we will use EPICs and describe them as follows.

INITIATIVE (Epic)

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

Traditional Epics use in JIRA

Epics describe a large chunk of work that that has one common objective.  It can be a feature, business requirement, or a functional objective. A single Initiative can have multiple Epics.  This should be a high-level description of the chunk of work that really serves as a ‘home’ to group related stories under.

Traditional 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.  

 


User Stories


For NYPL USER STORY can be traditional description of the desired feature or experience from a users perspective or SYSTEM STORY for systems or software engineering perspectives. Mostly applied to backenf system logic or application development where the function vs the user facing feature is being developed.

Traditional User Story

User Story

 

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.

System Story

System Story (User Story)

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.

IMPORTANT:

  • All user-facing and measurable features should ALWAYS include information on Analytics Specification, and a information on Accessibility.  
  •  If each of these aren’t their own user stories, please add a section for “Analytics” and “Accessibility” to all relevant stories.
  • All user stories outlining new functionality or pages should specify analytics requirements.  This can happen in Acceptance Criteria.
  • All user-facing stories that imply or impact design should include an Accessibility section.   This can happen in Acceptance Criteria.
  • No labels