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.
Info | ||
---|---|---|
| ||
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
Launch Timeline/Date Required
Assumptions Required, if none put “N/A”
MVP Scope Required
Nice to have Not Required
Out of Scope Required, if none put “N/A’
High Level RACI
UX Docs and Specs Required if there is any UX in the project
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.
Info | ||
---|---|---|
| ||
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:
Description:
|
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
Info | ||
---|---|---|
| ||
Required if not using System Story Title/Summary 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.
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.
Analytics Note Required on relevant stories Accessibility Note
Notes Not required
|
System Story
Info | ||
---|---|---|
| ||
Required if not using User Story
Title/Summary
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.
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.
Analytics Note Required on relevant stories Accessibility Note
Notes Not required
|
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.