Methodology 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.
Initiatives 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)
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
