Description
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
- Log into the
bitovi-training
account - specifying a JQL of
issue = IMP-143
- Check "Load all children of JQL specified issue"
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
andcompletedDaysOfWork
along withpercentComplete
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.