Project Status Tracking in JIRA Proposal

Background

The wiki has been used to track the status of projects (scorecards) and achievement of release milestones.

Problem

The update of the wiki pages is manual and time-consuming for PTLs and Release Manager.

Proposal

Raise JIRA tickets in each ONAP project for each milestone and/or release requirement

• JIRA tickets are assignable to people for implementation and follow-up.
• JIRA tickets communicate priority, completion status and dates.
• JIRA tickets can be queried and filtered to provide summary reports.
• JIRA tickets can be linked to other JIRA tickets for dependencies, blockers and related issues.

Frankfurt Proposal

• Move the source of truth from wiki_checklists to Jira Epic/Story/Task 
  • ?TSC Jira project OR new Release project?
• All stories must be tied to a UseCase OR Infra (using tags)  
  • Move OVP to a usecase
• Each milestone has a user story and subtasks 
  • subtasks are milestone deliverables (eg. Story=M4, Subtask=Completion of Vulnerability table)
  • ?Special type task that has only open/complete states?
• Create wiki/Jira dashboard using tags/queries

Maybe there could be new JIRA configs to assist, e.g.

• Issue Types for Scorecards
• project Components for Milestones
• Labels for cross-cutting concerns like needing TSC approval and being POC

Based on all that JIRA ticket information, a Kanban board will show visually when a Milestone or Release is Done!

Discussion

• Integration with Development process and "definition of done"
  • Release criteria already requires JIRA tickets to be Closed
  • Benefits of this criteria discussed here https://lists.onap.org/g/onap-arc/message/1100
• Time element
  • Creating a framework with a time line to hang activities would be necessary
  • Epics for each milestone?
    • tasks replicated per project due for each milestone
    • can use the TSC JIRA project for the epic, then distribute Scorecard/Story JIRA cases to individual ONAP projects
  • Probably could diagram this out to get some idea how it all would work
  • Automation via JIRA CLI tool could be used to script the creation of releases and milestones, since it's a fairly static config consisting of many instances of known templates
• Follow-ups
  • Release Manager has needed to chase PTLs for completion status
  • JIRA could be used to remind people of remaining cases by subscribing to an issue filter (see https://jira.onap.org/secure/ManageFilters.jspa?filterView=popular ) with appropriate criteria, e.g. Open Bugs Highest and High https://jira.onap.org/issues/?filter=11367
• Skeptics Corner
  • Feels like we're re-inventing scrum
    • Referring to https://www.researchgate.net/publication/290823579_Agile_Can_Scale_Inventing_and_Reinventing_SCRUM_in_Five_Companies
    • "A typical Burndown Chart is illustrated in Figure 1. It consists of the cumulative time it takes to complete outstanding tasks for deliverable software for a SCRUM

      sprint. Each developer breaks down tasks into small pieces and enters into an automated backlog system"

    • What is JIRA if not an "automated backlog system"? The tool feels like SCRUM because it is used to support SCRUM!
  • As a release mgr, it sounds like the same amount of paper chasing with a different user interface...

Experiments

• SANDBOX-55 - Getting issue details... STATUS
• https://jira.onap.org/secure/RapidBoard.jspa?rapidView=195&projectKey=SANDBOX

Implementation

• Tools
  • TBC
• Processes
  • TBC