-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
8.20.10
-
8.2
-
2
-
Severity 3 - Minor
-
0
-
Issue Summary
Splitting an Issue makes the Burnup Chart calculate completion in a wrong way.
Reproduced on 8.20.10 but possibly affecting other versions, too (both older and newer).
Steps to Reproduce
With a Board using Story Points:
- Create a Sprint set to start a few days past
- Create a Story "A" with 12 Story Points
- Add Story A to the Sprint
- Remove Story A from the Sprint
- Start the Sprint
- Split Story A into 3 issues: A, A.1 and A.2. Each of them with 4 Story Points
- Add A and A.1 to the Sprint already started
- Complete Story A
- Check the Burnup Chart
Expected Results
Each time Story "A" is completed, we'd see "Completed Work" drop by 4, which is the Story Points for Story A.
Actual Results
Each time Story A is completed, we see the "Completed Work" drop by 8 instead of 4, as if accounting for the A.1 too:
Workaround
No workaround available at the moment. An alternative is for the affected Sprints to rely on other Charts that are not affected (like the Burndown).
Troubleshooting
To help investigate the timeline of events concerning the Sprint and Issue Splitting, we may rely on the procedures below.
Save the output of each Issue involved in the splitting into a json file:
https://jira.base.url/rest/api/2/issue/JIRA-100?expand=changelog https://jira.base.url/rest/api/2/issue/JIRA-101?expand=changelog
And run this Linux example command to parse the JSON into a leaner timeline:
$ cat JIRA-100.json JIRA-101.json | jq -j '.fields.created, "\t", .key, "\t", "CREATED", "\n", .key as $key | (.changelog.histories[] | .created as $changelogdate | (.items[] | select(.field == "Sprint" or .field == "status" or .field == "Story Points") | $changelogdate, "\t", $key, "\t", .field, "\t[", .fromString[0:30], "]\t->\t[", .toString[0:30], "]\n"))' | column -t -s $'\t' | sort -k1 -k2 -s 2023-06-02T12:51:49.000-0500 JIRA-100 CREATED 2023-06-02T12:51:50.000-0500 JIRA-100 Story Points [null] -> [10] 2023-06-02T14:32:48.000-0500 JIRA-100 Sprint [null] -> [Some Sprint] 2023-06-05T11:42:53.000-0500 JIRA-100 Sprint [Some Sprint] -> [] 2023-06-07T16:58:30.000-0500 JIRA-100 status [Open] -> [In Progress] 2023-06-07T19:35:29.000-0500 JIRA-100 Story Points [10] -> [12] 2023-06-12T11:14:06.000-0500 JIRA-101 CREATED 2023-06-12T11:14:06.000-0500 JIRA-101 Story Points [null] -> [4] 2023-06-12T11:14:07.000-0500 JIRA-100 Story Points [12] -> [4] 2023-06-19T12:48:24.000-0500 JIRA-100 Sprint [null] -> [Some Sprint] 2023-06-19T12:48:28.000-0500 JIRA-101 Sprint [null] -> [Some Sprint] 2023-06-19T13:04:47.000-0500 JIRA-100 status [In Progress] -> [Resolved] 2023-06-19T13:05:57.000-0500 JIRA-101 status [Open] -> [Resolved] 2023-06-19T13:06:39.000-0500 JIRA-100 status [Resolved] -> [Closed] 2023-06-19T13:06:56.000-0500 JIRA-101 status [Resolved] -> [Closed] 2023-06-19T16:56:50.000-0500 JIRA-100 status [Closed] -> [Reopened] 2023-06-19T16:58:42.000-0500 JIRA-100 status [Reopened] -> [Resolved] 2023-06-19T16:58:49.000-0500 JIRA-100 status [Resolved] -> [Closed] 2023-06-19T16:59:38.000-0500 JIRA-101 status [Closed] -> [Reopened] 2023-06-19T17:00:30.000-0500 JIRA-101 status [Reopened] -> [Resolved] 2023-06-19T17:00:34.000-0500 JIRA-101 status [Resolved] -> [Closed]
To correlate the Sprints, you may use the DB query below:
select i.id as "Issue Id", concat(p.pkey, concat('-', i.issuenum)) as "Issue Key", cf.id as "CF Id", cf.cfname as "CF Name", v.stringvalue as "Sprint Id", s."NAME" as "Sprint Name", s."RAPID_VIEW_ID", s."STARTED", s."CLOSED", s."START_DATE", s."ACTIVATED_DATE", s."END_DATE", s."COMPLETE_DATE" from jiraissue i inner join project p on p.id = i.project inner join customfield cf on cf.cfname = 'Sprint' inner join customfieldvalue v on v.issue = i.id and v.customfield = cf.id left join "AO_60DB71_SPRINT" s on concat(s."ID", '') = v.stringvalue where i.id in (1000000, 1000001, 1000002);
Filtering by the Issue Ids (from the JSON files) or somehow.
To translate the dates below from Epoch Time to human readable you can use any Epoch Time conversion utility or website.
START_DATE: When the Sprint was planned to start ACTIVATED_DATE: When the Sprint was actually started (button pressed) END_DATE: When the Sprint was planned to finish COMPLETE_DATE: When the Sprint was actually finished (button pressed)
- relates to
-
-
- Gathering Impact
-
-
JSWSERVER-14719 Splitting an estimated issue destroys burndown and velocity
- Closed
- mentioned in
-
Page Loading...