Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Percent Complete #69

Open
justinbmeyer opened this issue Jun 17, 2024 · 2 comments
Open

Percent Complete #69

justinbmeyer opened this issue Jun 17, 2024 · 2 comments

Comments

@justinbmeyer
Copy link
Member

justinbmeyer commented Jun 17, 2024

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
Copy link
Member Author

@justinbmeyer
Copy link
Member Author

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

  • For each unestimated epic, add the average epic size
Initiative A

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

Unestimated - Empty Initiative

  • If an average initiative size can be calculated, use that, otherwise use 6 weeks.
Initiative A

Unestimated - Unestimated Epics

  • Provide average epic time for each epic
Initiative A

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

   Epic A (start date)
   Epic B (confidence)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant