Jira Process (Updated July 8)

Owned by Pierre Dane
Last updated: Jul 11, 2019 by Annie Martin
6 min read

This document describes the process of issue and feature tracking and managing their scheduling into new releases of Reveal. This tracking will take place in Jira, through Atlassian platform that integrates with Confluence, where project scoping, note-taking, and general documentation is stored.

Access to this platform will be initially given to those in the Reveal Consortium and its partners, VitalWave and CHAI. As implementations develop, program managers responsible for the technical aspects of the Reveal tool will also have access. We do not envision, at this point, that all users of the Reveal tool would have access, but rather the third and highest tier of the help desk who may be users or administrators.

Management of the platform and the roadmap will be co-owned by the Akros Product Manager and the Ona Development Manager. New issues and their priorities added to issues will be reviewed on routine implementation planning calls. These will be reviewed at high level on routine Reveal Consortium Calls. Akros and Ona will work to evaluate level of effort and schedule the features and bugs accordingly and plan future releases/versions.

Issue Types 

There are various issue types enabled in the Reveal Jira configuration. The configuration of the different types is defined here:

https://docs.google.com/spreadsheets/d/1Yme-sC1yEn4VIE6xhf2p7VIrSOKGGiouL80qwtDut3I/edit?ts=5d10e50b#gid=0

Epic (User Story of Feature): Epics will be used to track user stories or features, which will often represent a collection of development tasks. Epics will be entered by implementation users, the product manager, or the development manager. The development manager will work to split Epics into individual development tasks. Other issue types can be linked to Epics if they must be addressed to complete the work for that particular epic.

Bug: Bugs will be entered against current Reveal versions by any user who discovers said bugs. 

Form Change: Form changes will often be country specific requests to modify the forms that are attached to tasks in Reveal.

Question: The question field may be used by developers or implementers to resolve a question related to scoping or intended functionality.

Task: Tasks will represent individual development tasks. Translation and string changes should be captured as tasks.

Adding an Issue 

  • Before adding a new issue, go to to issues and search all. If you haven't found the issue yet, then go to the Backlog and repeat your search here.  
    • If it is a duplicate of a resolved bug, move the status to 'New' and add a Label of 'Reopened'
    • If it is a duplicate but there is new information, a change in priority, or change in other information, add that to the existing issue.
  • Press 'C' and enter details for the issue. Note the required fields differ slightly depending on which type of issue is selected.
  • Fields include:
    • Epic Name used to name the feature or user story.
    • Summary to include all keywords for searching and should be as short and succinct as possible. 
    • Platform field used to capture which Reveal platforms are most relevant for this issue.
    • Device/Hardware entered if a bug or issue is experienced on a particular hardware type.
    • Operating System entered if a bug or issue is experienced on a particular OS.
    • Priority as perceived at the time of entering the issue
    • Extra detail to go in the Description field. Screenshots can be pasted here or uploaded as attachments (former preferred).
    • Affects version to capture the release version that this bug or issue is related to.
    • Implementation/Location captures which locations or implementations this issue or bug is relevant to. This is a label field, meaning the user can create different values on-the-fly.

Historical Issues

Triaging Issues

The issue workflow will move issues through set of statuses which can be visualized on the Kanban board.

  • Any user should be able to add a bug or feature to ‘New’. Akros Product Manager monitors  ‘New’, ensures that issues are not duplicates, cleans up Summary and Description, and ensures all necessary info is included (e.g. steps to reproduce, task type, software version, OS, browser version etc). Discusses priority with CHAI and VW and modifies as necessary.
    • Move to ‘Triage’
    • Move to ‘Scoping Needed’
    • Move to 'Won't Fix' if the issue is not relevant.
    • Move to 'Backlog' if the issue is low priority and not something to focus on now.
    • If duplicate and any issues type but Epic, link to duplicate issue with "is duplicated by link", and mark newer issue as 'Won't Fix'
    • If duplicate and issue type of Epic, list duplicate Epic number in title and comments and mark newer issue as 'Wont' Fix'.
    • Add appropriate labels.
  • Ona Development Manager monitors ‘Triage’ and ensures that issues are ready for dev or may need scoping. 
    • Moves to 'Ready for Dev' or 'Scoping Needed'
    • Adds 'Fix Version'
  • Akros Product Manager monitors 'Scoping Needed', creates scoping documentation, assigns owner of feature scoping on the issue. When scoping is complete:
    • Moves to 'Triage' 
  • Ona Development Manager and developers monitor ‘Ready for Dev’ and schedules.
    • Moves to 'In Progress'
  • Developers handle ‘In Progress’
    • Move to 'In Review' when dev complete and version with the fix or feature is released.
  • Akros to monitor 'In Review,' and move to 'Done' when testing passes, or back to ‘Triage’ (with a red  ‘Reopened’ label) if necessary. Note the ownership of this task differs slightly for DSME user stories (see below).

As a product team, we will aim to look at the new and triage columns on a daily basis, working to move items from new into triage within 2-3 days.

Scoping and linking between Confluence and Jira

When an issue is moved into the "Scoping Needed" column, it indicates that significant scoping is needed for that item before development can process. This should correspond to a scoping document in Confluence. Each scoping document should have the following summary table at the top that links it to the relevant issues. Every scoping document must have a test case as well that outlines what the development must do to pass requirements.

The issue in Jira should also be linked to the Confluence document through the Confluence link in Jira (see add link button and see linked Confluence document below):

Labels

  • Labels can be used for ad-hoc classifications that don't have pre-defined fields to measure them against. Please DO NOT create labels without consulting the Akros Product Manager.
  • The following labels exist currently
    • Implementation/Location labels → for each country or location implementing, we have a label.
    • Reopened → this label will be added to bugs or issues that are reopened after being completed
    • DSME_User_Story → this label will be applied to user stories on the DSME road map
    • Tags to indicate buckets of major work. This list can be expanded as it is helpful/needed for filtering purposes.
      • IRS_Plan
      • IRS_Features
      • FI_Plan
      • FI_Features
    • Scoping_Needed We will not use this anymore as a label, instead we will have a column and status associated with an issue if scoping is needed. See scoping section above.

Releases

  • Releases will be tracked through Jira release versions.

  • Users can track issue progress against versions by clicking on the hyperlinks.

DSME Tracking

  • All user stories added to the roadmap will have a label "DSME_User_Story"
    • User Stories will be considered complete when moved to the "Done" column. Akros will review the user story when in the "In Review" column and then reassign to VitalWave for a secondary review and move to the "Done" column.
  • DSME priorities will be translated as follows:
DSMEJira
CriticalHighest
MVPHigh
Must haveMedium
Should haveLow
Could haveLowest