You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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
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?
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?
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.
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.
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?
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.
- 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:
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.