[JSWSERVER-21820] Splitting an Issue may break the Burnup Chart

Type: Bug
Resolution: Unresolved
Priority: Low (View bug fix roadmap)
Fix Version/s: None
Affects Version/s: 8.20.10
Component/s: AgileBoard, Reports
Labels:
- whl-fy24q4

Introduced in Version:
8.2
Support reference count:
2
Symptom Severity:
Severity 3 - Minor
UIS:
0
Bug Fix Policy:
View Atlassian Server bug fix policy

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)

- - Sort By Name
  - Sort By Date
  - Ascending
  - Descending
  - Thumbnails
  - List

image-2023-07-12-19-11-47-299.png
12/Jul/2023 10:11 PM
100 kB
Rodrigo Martinez

relates to

JSWSERVER-16204 Remaining Estimate not updated with Split issue feature

Gathering Impact

JSWSERVER-14719 Splitting an estimated issue destroys burndown and velocity

Closed

mentioned in: Page Failed to load

Form Name

Rob made changes - 29/Jul/2024 7:03 AM

Labels

New: whl-fy24q4

David Di Blasio made changes - 12/Jun/2024 7:50 AM

Remote Link

New: This issue links to "Page (Confluence)" [ 915874 ]

David Di Blasio made changes - 12/Jun/2024 6:54 AM

Remote Link

Original: This issue links to "Page (Confluence)" [ 915436 ]

David Di Blasio made changes - 11/Jun/2024 8:28 AM

Remote Link

New: This issue links to "Page (Confluence)" [ 915436 ]

SET Analytics Bot made changes - 07/Feb/2024 2:19 AM

UIS

Original: 1

New: 0

SET Analytics Bot made changes - 09/Nov/2023 4:03 AM

Support reference count

Original: 1

New: 2

Patrick Turbett made changes - 08/Nov/2023 3:52 PM

Summary

Original: Splitting and Issue may break the Burnup Chart

New: Splitting an Issue may break the Burnup Chart

SET Analytics Bot made changes - 23/Sep/2023 2:17 AM

UIS

New: 1

SET Analytics Bot made changes - 14/Jul/2023 4:02 AM

Support reference count

New: 1

Sławomir Zaraziński made changes - 13/Jul/2023 10:01 AM

Description

Original: h3. 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).
h3. 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 2 others, A.1 and A.2. Each of the 3 with 4 Story Points
# Add A and A.1 to the Sprint already started
# Complete Story A
# Check the Burnup Chart

h3. Expected Results

Each time Story "A" is completed, we'd see "Completed Work" drop by 4, which is the Story Points for Story A.
h3. 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:

!image-2023-07-12-19-11-47-299.png|width=542,height=69!
h3. 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).
h3. 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:
{code:none}
https://jira.base.url/rest/api/2/issue/JIRA-100?expand=changelog
https://jira.base.url/rest/api/2/issue/JIRA-101?expand=changelog
{code}
And run this Linux example command to parse the JSON into a leaner timeline:
{code:none}
$ 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]
{code}
To correlate the Sprints, you may use the DB query below:
{code:sql}
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);
{code}
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.
{code:none}
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)
{code}

New: h3. 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).
h3. 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

h3. Expected Results

Each time Story "A" is completed, we'd see "Completed Work" drop by 4, which is the Story Points for Story A.
h3. 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:

!image-2023-07-12-19-11-47-299.png|width=542,height=69!
h3. 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).
h3. 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:
{code:none}
https://jira.base.url/rest/api/2/issue/JIRA-100?expand=changelog
https://jira.base.url/rest/api/2/issue/JIRA-101?expand=changelog
{code}
And run this Linux example command to parse the JSON into a leaner timeline:
{code:none}
$ 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]
{code}
To correlate the Sprints, you may use the DB query below:
{code:sql}
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);
{code}
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.
{code:none}
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)
{code}

Assignee:: Unassigned

Reporter:: Rodrigo Martinez

Affected customers:: 0 This affects my team

Watchers:: 5 Start watching this issue

Created:: 12/Jul/2023 10:18 PM

Updated:: 29/Jul/2024 7:03 AM

Details

Description

Issue Summary

Steps to Reproduce

Expected Results

Actual Results

Workaround

Troubleshooting

Attachments

Attachments

Issue Links

Forms

Activity

People

Dates