Burndown chart report - sprint start don't include all issues types

[Júnior Silva]

Hi everyone,

We have a problem with burndown chart report.

We have a customized issueType called "Bug" with a customized workflow, screens, etc.

When we start sprint, these issues types (Bug) didn't appear on the first row of table in the "Burndown chart" report.

I checked the workflow and i saw the post-function there "Update change history for an issue and store the issue in the database".

We have others customized issues types that appear in the "start sprint" event.

Thanks,

[Júnior Silva]

https://community.atlassian.com/t5/Jira-questions/Some-stories-aren-t-presents-in-Sprint-Start-Event/qaq-p/870135

[Júnior Silva]

I have in the same sprint, 1 issue (New Bug) that was considered into "Sprint Start" event and other issue (New Bug) that wasn't considered isto "Sprint Start". Both issues were estimated before sprint start.

[Ignacio Pulgar]

Hi Júnior,

A couple of questions:

1. Is the burndown chart set to be based in Story Points?
2. If so, is the Story Points field mapped to the Bug issue type through a context?

Thanks and regards.

[Júnior Silva]

Hi @Ignacio Pulgar ,

1. Yes, the board is configured with "Story Points".

2. We have Global.

[Ignacio Pulgar]

Jira Software Server or Cloud?

If Server, what version?

[Júnior Silva]

Server v7.3.8.

[Ignacio Pulgar]

Is your custom Bug issuetype of subtask sub-type? If so, that's the cause.

Story Points on subtasks are not included in the Burndown Chart. (Only Story Points on parent tasks are included.)

https://confluence.atlassian.com/jirasoftwarecloud/burndown-chart-777002653.html

[Júnior Silva]

No, it's Standard issue type.

[Ignacio Pulgar]

Oh, I see! I was about to suggest contacting Atlassian Support, but fortunately anyone else already did (I'll paste the known issue here just for other users convenience):

https://jira.atlassian.com/plugins/servlet/mobile#issue/JSWSERVER-13996

The bug occurs on issue creation, just with issues which automatically transitiion to a diferent status from the initial one as soon as created.

As you mentioned that it happened just with some issuetypes, I guess in your case the automatic transition is performed by a post-function on the Created transition of the workflow(s) set to be used by those issuetypes.

Of course, removing that automation would prevent this issue from happening again. May you possibly describe in detail the need that is covered by said automatic transition? Maybe we can find a different way for meeting your requirements that don't need to transition on isdue creation...

Regards.