Hi. Here's a simplified view of my team's issue workflow Planned (Status type: 'To do') → Ready for sprint (Status type: 'To do') → In progress (Status type: 'In progress') → Testing (Status type: 'In progress') → Prod (Status type: 'Done') Is anything reflected in sprint burndown chart if I: * Change the status of an issue from Planned (Status type: 'To do') to Ready for sprint (Status type: 'To do') * Change the status of an issue from Ready for sprint (Status type: 'To do') to In progress (Status type: 'In progress') The main reason why I am asking this is that we are only marking items as Prod (Status type: 'Done') at the very end of the sprint, all in one go. Does this mean that the sprint burndown chart will have a large cliff at the end instead of gradual step-like progression as is ideal? If so, what can I do to make the sprint burndown chart useful for our team? Should we add another status with the type 'done' that comes before Prod?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Does sprint burndown chart update when I switch between 'to do' & 'In progress' statuses?

Siddhant Modi_z5tgxx

Hi.
Here's a simplified view of my team's issue workflow

Planned (Status type: 'To do') → Ready for sprint (Status type: 'To do') → In progress (Status type: 'In progress') → Testing (Status type: 'In progress') → Prod (Status type: 'Done')

Is anything reflected in sprint burndown chart if I:

Change the status of an issue from Planned (Status type: 'To do') to Ready for sprint (Status type: 'To do')
Change the status of an issue from Ready for sprint (Status type: 'To do') to In progress (Status type: 'In progress')

The main reason why I am asking this is that we are only marking items as Prod (Status type: 'Done') at the very end of the sprint, all in one go.

Does this mean that the sprint burndown chart will have a large cliff at the end instead of gradual step-like progression as is ideal? If so, what can I do to make the sprint burndown chart useful for our team?

Should we add another status with the type 'done' that comes before Prod?

Accepted answers

Trudy P Claspill

Are you using a Company Managed (classic) project or a Team Managed (next gen) project?

Referencing https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-burndown-chart/

"The Burndown Chart is based on your board's column mapping. An issue is considered to be 'To Do' when it is in a status that has been mapped to the left-most column of your board. Similarly, an issue is considered to be 'Done' when it is in a status that has been mapped to the right-most column of your board."

So adding another "done" status before the Prod status is not going to show the issues burning down, unless you remove the Prod status from the board. But that would impact closing your sprints.

For a Company Managed project you could add another "in progress" type of status prior to Prod, and create a second scrum board with the same filter, and just not include the Prod column/status on that second board. In the second board you would see the burndown reflecting gradual change as the issues moved to that new status (after In Progress). But, you would NOT want to use that second board for closing sprints. And, as soon as you moved the issues to the Prod status and closed the sprints in your main board, then the burndown chart in the second board would get a giant up-tick.

There is not a good way to do what you want, in my opinion.

The real question is when is your work really done and what does the Prod status represent? If there is incomplete work until the issue is set to Prod and the work is not actually completed until the end of the sprint, then a burndown with a cliff at the end is accurate. If there is no actual work done as part of the transition to Prod, then why do you have that status?

All comments

Trudy P Claspill

Are you using a Company Managed (classic) project or a Team Managed (next gen) project?

Referencing https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-burndown-chart/

So adding another "done" status before the Prod status is not going to show the issues burning down, unless you remove the Prod status from the board. But that would impact closing your sprints.

There is not a good way to do what you want, in my opinion.

Bill Sheboy

Hi @Siddhant Modi

It appears that you posted this same question as both a discussion topic and a question, so I am posting the other link here to help the community align the ideas they give you:

https://community.atlassian.com/t5/Jira-discussions/Does-sprint-burndown-chart-update-when-I-switch-between-to-do/td-p/1659922

Best regards,

Bill

Siddhant Modi_z5tgxx

Thanks @Trudy P Claspill

Ours is a next gen project so based on your answer, the option of adding a second scrum board won't be available to us, right?

Your answer gave me some thoughts on approaches that we could go with:

Replace 'Prod' with 'Ready for deployment' on board
1. Remove 'Prod' from board. But let it remain as a status because we will still want to know which items are in prod.
2. Add another status called 'Ready for deployment' (Type: Done) and add it as the rightmost column to the board.
3. Add 'Deployment to Prod' as a recurring task to each sprint. It's a one time activity which takes 2-3 hours in each sprint.
Disregard the sprint burn down chart altogether

What do you all think?

Also, I am very new to product management (& to Jira), so I am not aware of how other software product teams go about structuring their boards. Do they consider 'prod' as done? Or do they consider 'Ready for deployment' as done? If I could get some insight on that, it would be helpful.

Trudy P Claspill

I don't work with Team Managed (next gen) projects on a regular basis. We use Company Managed (classic) projects.

In our organization we consider "ready for deployment" as "done".

We assign issues to releases/versions. When a release is actually deployed, the Release status is changed to Released. That is how we know which changes are in production.

I would recommend using the "ready for deployment" as you last status, get rid of the "prod" status, continue to review the burndown chart, and use Releases to identify the issues that have been deployed to production.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

burndown