How to change the X Axis period in Burndown chart in Jira software project

[Anandan Subramani]

I have a Sprint that started on Nov 1, 2022, and completed on 16th Nov 2022; it was a two weeks Sprint. Now, I am on Dec 18, 2022.  The burndown chart X-axis date starts from Dec 18, 2022. Hence, I cannot see correctly how Sprint was performed, meaning the actual work done line is just a vertical line, and the planned one is a slope line.

 

[Joseph Chung Yin · Accepted solution]

@Anandan Subramani -

Welcome to the community, as recommended by @Nic Brough -Adaptavist- that you will need to specify your sprint with the start and end dates.  NOTE - By default, Jira uses two weeks for the typical sprint cycle.

If you are asking if the x-axis can be change to something else rather than the time frame, then it is not possible using the out of the box report provided by the application.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Anandan Subramani]

Thanks, Joseph. 

I think my inquiry wasn’t clear enough. Let me rephrase it now.

X axis is timeframe only. In this case, Nov 1, 2022, to Nov 18, 2022.  Please refer to the attached screens of the burn-down chart, issue log. Complete sprint and velocity (17 days)

What I don’t understand from my burn-down charts are: (a) There is no planned curve (hypotenuse line from drawn point Y-axis = 17, X-Axis =0) and (b) There was no work done on Dec 18, 2022, because Sprint issue log for the first issue was on Nov 1, 2022.

For the moment, let me ignore the previous question. Here is another imaginary scenario. A team completes a sprint of 2 weeks, say in May, but fails to log their work. The team closes the sprint by clicking the " Complete Sprint in May" button.

However, the team entered the data of previously completed sprints in the month of October. Will the X axis of the burn-down chart be May only or May to October?

[Joseph Chung Yin]

@Anandan Subramani -

Once the sprint is completed (i.e. May), if you update issues associated with that sprint in October, it will not change the Burndown report data because the sprint is already closed.

Best, Joseph

[Anandan Subramani]

Thanks, Joseph, for your answer.

Closed sprints have no impact on burndown, velocity, and cumulative charts. Closed sprints are historical records, and the system should prohibit any change to closed sprints. That is clear.

My nagging doubt is, what happens when the team does some work, but for some outrageous reason, the team forgets to close the sprint?

It looks like the system considers a Sprint to be closed only when it is given 'complete sprint' status. It doesn't matter whether some issues are not done; there is no option in the 'complete sprint' button' the date of closing, by default, is the date on which the button is clicked, and that default can not be changed, For instance, I can't close a sprint on 10th but choose 5th as the date of closure.

This has an impact on all reports.

Can I circumvent this constraint?

[Nic Brough -Adaptavist-]

Burndown and velocity are products of the sprint you are looking at, they've nothing to do with other sprints.

If your teams "forget" to close sprints, then the next sprint should probably include a story for "fixing why we've forgotten to say we've done any work"

It seems to me (but please tell me that I'm wrong if I am here), that your people are putting bad data into your system - wrong sprint start and end dates, plus forgetting to close them.  I think that's a human problem that needs fixing, not a tool problem.

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

This looks like you didn't tell Jira that the sprint started on the 1st of November, you told it to start on the 18th.

Go to the sprint management section and check what the start and end dates on the sprint are.

[Anandan Subramani]

Well, I did tell Sprint the start and end dates.

[Trudy Claspill]

Hello @Anandan Subramani 

I have a clarifying question.

You said the sprint time frame was X to Y, and that X was entered in the Sprint Start Date and Y was entered in the Sprint End Date.

Was the "Start Sprint" button clicked for the sprint on date X? If not, on what date (relative to X) was the sprint actually started?

And was the Complete Sprint button clicked on date Y? If not, on what date (relative to Y) was the sprint actually completed?

[Anandan Subramani]

Thanks, Trudy Claspill:

Your answers to my doubts lie in your return questions themselves. Thanks.

Though the sprint was executed in a previous month, i.e., November, the data was entered in this month, i.e., December.

The start button clicked on December 18th. Complete Sprint, too, was clicked on the 18th. Now I understand why this goof up.

What I infer from this is this. The Sprint Start and Sprint complete dates supersede the dates given inside the issues.

I have done a Sprint with a custom Sprint duration of 9 AM to 4 PM for Dec 20, 2022. I have attached the screenshot of the burn-down chart. I added an issue in the sprint at 11 AM, which, I suppose, is a scope change or a scope creep. I would appreciate it if you clarify some doubts springing up from this chart. Sorry to consume your time.

• Is this correct, or is there something amiss in the chart?
• Why is the planned line not showing up in the scope change? In fact, there is no planned line. A guideline, I suppose, is not a planned line.
• There is an eclipse on the top RHS, which allows the reopening of the Sprint. I thought once a Sprint is done, it is a releasable delivery increment, and in some situations, it may already have been delivered to the end user. Hence, why is the system allowing modification to a completed Sprint?
• Usually, the Sprint outcome must be acceptable to the client, which is done at the Sprint Review ceremony. Can this instance be added to the Board as the last column? In this case, ‘Complete Sprint’ can be clicked after the Sprint Review meeting.

Thanks again

[Trudy Claspill]

• Why is the planned line not showing up in the scope change? In fact, there is no planned line. A guideline, I suppose, is not a planned line.

What do you mean by a "planned line"? There is no feature of the Burndown chart called a "planned line". The grey Guideline gives you a linear progression of your burndown rate to reach 0 by the end of the sprint. It is based on the value for your Estimation Statistic at the moment that the sprint is started (Start Sprint button clicked).

• There is an eclipse on the top RHS, which allows the reopening of the Sprint. I thought once a Sprint is done, it is a releasable delivery increment, and in some situations, it may already have been delivered to the end user. Hence, why is the system allowing modification to a completed Sprint?

One reason the ability to re-open the sprint is provided is in case the sprint was closed in error, before its planned End Date, and needs to be reopened so it can be continued. The erroneous completion or reopening of a sprint can be mitigated by reducing who has permission to manage sprints.

• Usually, the Sprint outcome must be acceptable to the client, which is done at the Sprint Review ceremony. Can this instance be added to the Board as the last column? In this case, ‘Complete Sprint’ can be clicked after the Sprint Review meeting.

You can add another issue status to the workflow for 'client accepted' and map that to the right most column, or add another column to the right side of the board for just that status, if you wish (and if you have sufficient permissions). When the Complete Sprint button is clicked only the issues in statuses that are mapped to the column farthest to the right will be considered "complete". Issues in any other column will be considered "incomplete" and you will be prompted to accept moving all the incomplete issues to the Backlog or another sprint. Note that it is not possible to prevent the use of the 'Complete Sprint' button based on the status of the issue. A sprint can be completed at any time by a person with sufficient permissions, regardless of the status of the issues in the sprint.

Back to your first question...

• Is this [chart] correct, or is there something amiss in the chart?

What this chart tells me is:

1. You clicked the Start Sprint button on Dec. 20 sometime shortly before 10:00.
2. At that point there was approximately 20 Story Points assigned across all the issues in the sprint.
3. Next, your incomplete story points decreased by 5 (to 15 points). This could occur because issues transitioned to the "done" status (the one in the right-most column) or because the Story Point values in some of the issues were reduced.
4. Next, your incomplete story points were again decreased by 5, and then shortly after that increased by 2 (or 3?). The decrease reasons are given above. The increase reason could be that you increased Story Points assigned to issues in the sprint or, as you stated, you added another issue to the sprint. Note that these don't affect the Guideline because that line is based solely on the number of Story Points in the sprint at the moment it started.
5. Next, your incomplete story points increased by 1 and then a bit later decreased by 1. The decrease and increase reasons are explained above.
6. Your story points stayed at that level for a period of time.
7. Your incomplete story points decreased to 0 all at once.
8. A short time later you clicked the Complete Sprint button.

Note that the time axis of your sprint will be based on the date/time when you originally click the Start Sprint button and the last time you click the Complete Sprint button. The dates that you enter for the Start and End Dates of the sprint are your plan, but for reporting purposes it is when you click the buttons that matters. The dates that issues change status only matter when the status changes happen within the time range that the sprint was active. If the status changes before the sprint is Started or after it Ends that will not affect the report.