How to make your sprint burndown recognize a ticket as Done when it is not in the board last colum

[Moon]

Hey Everyone,

I have a jira board where tickets from left to right go through various states/columns in order to get ready for staging. Last four columns on the far right are READY FOR STAGING, IN STAGING, READY TO DEPLOY, and DEPLOYED. 

I am trying to get the sprint burn down to recognize tickets in the READY FOR STAGING and beyond as Done. This is mainly because our production deployments happen after the sprint is closed and I'd like to deem a ticket as Done if it moves into the READY FOR STAGING column and therefore reflected in the sprint burn down.

I've tried editing the READY FOR STAGING status to be Done rather than In Progress but the burn down chart is not recognizing it. Wondering if I need to do that for all last 4 columns.

Any insight would be appreciated to understand if the sprint burn down can recognize a ticket as Done if it is not in the last column of the jira board.

Thank you!

[Nic Brough -Adaptavist-]

You can't do this.  The last column is "done", and that's it.  You need to include all your done status in the last column for it to work.

There is a common question of "why don't we allow the done column to be further left, having 2, 3, 4 etc columns on the right being done".  This would sort of work, but it is missing the whole point of a board.

A board is there to show the team the issues the team are currently working on.  Once they have finished with it, they don't need to see it anymore, beyond being able to see at a glance that it is done.  The team doesn't care what status it is in after they have finished with it.

So extra "done" columns are functionally useless.  They waste space and don't tell the people using the board anything they need to know.

[Moon]

Thank you @Nic Brough -Adaptavist- for your prompt response!

I think "useless" is a strong word. I've explained the use case I am after. For our cross-functional scrum team:

• for the developers Done means when development is complete and testing is complete.
• For our release team Done means when development work is released to production.

I don't think it is too unrealistic to expect a board to display the full journey of the ticket from development to release to the live site and along the way account for burns as tickets are deemed Done but not necessarily moved to the last column. In our case last column of the board is when we deploy our tickets to production.

Unfortunately our release to production will happen after the sprint is complete. Therefore the burn down chart does not recognize the tickets as Done until they go live, and that happens in the following sprint. This makes our burn down flat with no burn in the current sprint.

In an ideal scenario the burn down would be tied to the "Category" that defines the status of a ticket. I can configure the category of a status to be either "To Do", "In Progress", or "Done". If I define the status of a ticket to be of "Category" Done, then that ticket should be deemed as done and recognized by the burn chart regardless of where it is in the board. This approach will provide a lot of flexibility to the user.

Re your comment "There is a common question of "why don't we allow the done column to be further left, having 2, 3, 4 etc columns on the right being done". This would sort of work, but it is missing the whole point of a board." Does this exist today or merely a request?

Thank you!

Moon

[Nic Brough -Adaptavist-]

Yes, "useless" is a strong word, but it is accurate.

Once an item is done, a team has no further interest in it.  So what use is having a load of columns they don't care about on their board?  None.  

>For our release team Done means when development work is released to production

Ok, that's fine, that means that you have "released" in the last column and all the other status before it are in other not-done columns because they are not done.  

That probably won't work for you, because the development team's "done" almost certainly is not "released", it's "development complete".   Anything after that is also done for them, needing no more of their attention, so why put it in different columns?  It's done for them, so more columns have no use.

[Moon]

Unfortunately in our case different columns of Done are required because the scrum team is not just made up of developers. If I pile everything in the same column it will be hard for the release team to know what tickets are ready for Staging, and what tickets are ready for deployment (unless I set up a different board for them). If the scrum team was made up of only developers putting everything in one column would work, but in our case that is not the case. So I am looking for a flexibility that satisfies both requirements so I can serve the entire scrum team and not just the developers.

[Nic Brough -Adaptavist-]

I'm going to have to pick that apart in pieces:

>the scrum team is not just made up of developers.

Yep, that's absolutely right.  A scrum team is made up of a load of people who need to work on stuff together to get it done.

>If I pile everything in the same column it will be hard for the release team to [...]

Yes, it will.  But your release team is NOT your Scrum team.  The boards are for each team.  Your release team is not your scrum team and shouldn't be looking at the scrum team's board.  Even if they work in a Scrum fashion, their board is looking at different things to your developer team.

>So I am looking for a flexibility that satisfies both requirements so I can serve the entire scrum team and not just the developers.

Your "scrum team" is not a scrum team.  It's two different teams, with two different ways of working, and hence different ways to use a board.  

There is a very simple solution here - have two boards, one for each team.  Your developers simple "done" column can contain all the things the developer team is finished with, and the release team can have a board with all the post-development status arranged in a way that works for them.

[Samer Mansour]

I would also add that development teams can want it to work non-traditionally, so even if all the academic books and scrum leaders of the world are like "No, that's not done", at the end of the day there are dev teams in the trenches who need functionality like this to track their work, whether Atlassian wants to recognize non-conformity or not.

So your response is dismissive of the realities faced by development teams and how they choose to organize. And makes the Jira software poorer.

Whats the point of category then??? Remove it if we're that confident : ) and see the complaints come in.

Also it used to be supported https://community.atlassian.com/t5/Jira-questions/Workflow-status-with-a-category-of-DONE-does-not-appear-as-DONE/qaq-p/735487

My request is to respect the category over the column ordering.

[Nic Brough -Adaptavist-]

I'm afraid that's simply wrong.  The point of category is to help people with complex processes see the broad overview of what's happening.  It's not to classify issues as done.

In complex processes, sometimes one team's  "done" is another team's "to do".  Categories can't support that.

[carlosughini]

Hello there,

You can read in this documentation that:

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.

Basically, to make the burn down on status, put the status in the last column on your board.

Please give it a try and let me know how it goes.

Regards,

Carlos

[Moon]

Thanks @carlosughini for your comment. I completely understand that. However, I am trying to make it more flexible so it supports different use cases. Please see my reply above re a solution that will provide a lot of flexibility.

Thank you!

Moon

[Samer Mansour]

My change request is to respect the category over the column ordering. It is Beta after all, I'm sure the smart developers at Atlassian can support this change.

[Nic Brough -Adaptavist-]

It's never going to happen, it's the wrong thing to do.