bitovi / jira-timeline-report

An open source jira to power point slide generator for high-level status reporting.
https://timeline-report.bitovi-jira.com/
6 stars 0 forks source link

Percent Complete #69

Open justinbmeyer opened 2 months ago

justinbmeyer commented 2 months ago

Description

Calculate the amount of work complete within a parent jira issue type.

Out of Scope

Integrating the value into the UI

MVP Acceptance Criteria

  1. Log into the bitovi-training account
  2. specifying a JQL of issue = IMP-143
  3. Check "Load all children of JQL specified issue"

image

If I open the console, there is a report showing the percentage completion of all issue types above epic. Perhaps something like:

[
  {"Issue Type": "Milestone", averages: {totalDaysOfWork: 200, childIssues: 5},
   issues: [
     {"Summary": "Milestone A", ...otherJiraKeys, percentComplete: 20}
   ] 
  },
    {"Issue Type": "Initiatives", averages: {totalDaysOfWork: 50, childIssues: 6},
     issues: [ {"Summary": "Initiative B", ...otherJiraKeys, percentComplete: 20}, { ... }, ...] 
  }
]

We might want to include something like totalDaysOfWork and completedDaysOfWork along with percentComplete

Calculation

Total Work

FOR EACH intiative within a parent, sum the following

  if( initiative has no epics )
  -> USE average initiative time

  if( initiative has estimated epics w/o start and due date)
  -> USE estimated time adjusted for confidence

   if( initiative has start and due date )
     -> USE due_date - start_date

Completed Work

FOR EACH initiative, sum the following

   if( initiative has start before NOW , but end date after now)
   -> USE NOW - start_date

   if( initiative has start and due date before NOW )
   -> USE due_date - start_date

average initiative time

AVERAGE ( TIMED_INTIATIVES + FULLY_ESTIMATED_INITIATIVES )

Don't include partially estimated initiatives. 3 epics have an estimate, but 1 does not.

What if there are no initiatives that are estimated or timed? Average initiative should 6 weeks.

estimated time adjusted for confidence

We need to inflate estimates with a confidence factor (driven by a log-normal distribution).

We should pass some functions that we can later fill in. I think we should use similar function signatures to what the autoscheduler uses: https://github.com/bitovi/jira-auto-scheduler/blob/main/public/schedule-prepare-issues.js#L13

function getAdjustedWorkingDaysForIssue(issue, 
  {
    getTeam = (issue) => TEAM_KEY,
    getDaysPerSprint = (TEAM_KEY) => 10,
    getVelocity = (TEAM_KEY) => 21,
    getEstimate = (issue) => issue["Story points median"],
    getConfidence = (issue) => issue["Confidence"],
    getStartDate = (issue) => issue["Start date"],
    getDueDate = (issue) => issue["Due date"],
    getParallelWorkLimit = (TEAM_KEY) => 1 // this probably isn't needed
    uncertaintyWeight = 80
  }
) {

}

The implementation might look a lot like: https://github.com/bitovi/jira-auto-scheduler/blob/main/public/schedule-prepare-issues.js#L119

We could move that function to shared and put it in both projects. Eventually, code should be shared.

Implementation Suggestions

The easiest place to start would be to create a function in a new JS file ... something like public/percent-complete/percent-complete.js.

Import that function in /public/timeline-report.js and call it here:

https://github.com/bitovi/jira-timeline-report/blob/main/public/timeline-report.js#L781

            const formatted = rawIssuesToBaseIssueFormat(issues, serverInfo);
            console.log(formatted);
            percentComplete(issues)
            return formatted;

I would use the issues format instead of formatted. There's a reason why I simplified it previously (b/c I used to use excel), but I should have bit the bullet earlier and used what Jira gives back. Also, you should be able to read the issue hierarchy (instead of making assumptions).

percentComplete would calculate the percent complete on every issue. It should take configuration arguments above.

function percentComplete(issues, 
  {
    getTeam = (issue) => TEAM_KEY,
    getDaysPerSprint = (TEAM_KEY) => 10,
    getVelocity = (TEAM_KEY) => 21,
    getEstimate = (issue) => issue["Story points median"],
    getConfidence = (issue) => issue["Confidence"],
    getStartDate = (issue) => issue["Start date"],
    getDueDate = (issue) => issue["Due date"],
    getParallelWorkLimit = (TEAM_KEY) => 1 // this probably isn't needed
    uncertaintyWeight = 80
  }
) {

}

You'll need to set up a tiered parent/child relationship.

Then you'll start on the "epic" level and calculate all the "known" epics.

You'll then need to move up one level (initiatives).

On initiatives you'll need to calculate and use an average initiative size for "unestimated" initiatives. You'll need to repeat this for every part of the topology.

justinbmeyer commented 2 months ago

https://github.com/bitovi/jira-auto-scheduler/blob/main/public/estimation-progress-report.js#L349

justinbmeyer commented 2 months ago

Total Work Estimated Cases

Fully estimated

Initiative A

   Epic A (start date, due date)
   Epic B (story points median, confidence)
Initiative A

   Epic A (start date, due date)
   Epic B (story points)
Initiative A
   Epic A (start date, due date)
Initiative A
   Epic B (story points)

Partially estimated

Initiative A

   Epic A (start date, due date)
   Epic B (story points median)

Unestimated - Empty Initiative

Initiative A

Unestimated - Unestimated Epics

Initiative A

   Epic A (start date)
   Epic B (story points median)
Initiative A

   Epic A (start date)
   Epic B (confidence)