Burndown chart based on status

[swheat]

I have the same question as the author of [this question](https://community.atlassian.com/t5/Jira-questions/Burndown-chart-on-issues-that-are-Dev-complete-but-not-yet/qaq-p/1390640).

Accepted answer is not good for us however - much too much paperwork.

In same thread cited above, Samer Mansour asks if the burndown chart might be made to "use status category over the column ordering".  I'm not sure I understand his request but mine is probably similar if not the same:

Can the burndown chart be made to show issues that have moved to at least a selected step in the workflow?  So if I select "QA" when displaying the burndown chart it will show all issues moved to QA, approved by QA, and beyond (to the right).

[Mark Segall]

Hi @swheat and welcome to the community!

This is a common theme that crops up.  Jira is designed with the purest form of Agile in mind where management is too focused on individuals or sub-teams instead of placing full focus on the stories.  There is no "Dev" or "QA" velocity... The definition of velocity is cumulation of story points not team points.

If there's no way around your current team make up, your best bet is to simply split the two workstreams into separate workflows and/or boards.  When dev is complete, the story is marked as done and the burndown is updated accordingly.  You can set up automation to have it automatically spawn a Testing task for QA to manage with their own workflow/board so they can track their testing velocity.

I strongly encourage changing the reporting to focus on the story.  This puts equal accountability on both the developers and testers to work collaboratively and deliver high quality work efficiently.  In my experience, the hand off approach doesn't work because it creates an environment of finger pointing when releases are ultimately delayed...

"I handed off to QA. I don't know why they're so slow."
"pushed it back to Dev because it didn't pass AC"

[Nic Brough -Adaptavist-]

I think it's important to point out that Agile in general works with Scrum and Kanban on the concept that Board = Team.  Also, teams are supposed to be mulit-functional, you would not have a developer and QA teams separated - the team delivering a story would develop and QA it all themselves.

Once you understand that is what Jira is coded for, you will find it easy to adapt it to multiple teams, the trick is to have a single workflow for the story, but map only parts of it into a team's board, exactly as Mark suggests.

[swheat]

I very much appreciate your response and Mark's also. Honestly I'm incredulous at how you both have responded.

Sounds like the short version of the answer is "I understand what you need, others have asked for it, out software does not do it, and we are not going to change it." The part about the purest form of Agile seems an attempt to justify this response. The purest form of Agile is the form that enables the team to maximize delivery of working software. If that requires hanging post-its on a whiteboard so be it.

Regarding "focus on the story" and "one workflow" - that is exactly what I want - I want to be able to measure work at different points throughout the issue lifecycle. Maintaining two boards seems like a lot of work to achieve this very reasonable and simple goal.

We have only one team. Developers and QA testers on this team work at different cadences due to different workloads. This is common as Mark acknowledged.

The handoff approach does work and isn't going to change. This is due to fact that different people are responsible for different tasks. These tasks are sequential. Only when one person is done with their task can the next person begin.

Reporting is necessary to ensure accountability. Neglecting to report on the handoff process does not mean that problems will by definition go away. This is similar in nature to closing your eyes while facing an oncoming train. The fact that you don't see it does not mean it is not there.

Once again I appreciate your thoughtful responses. It is not my intent to be disrespectful or demanding. However I feel like my ask is reasonable and has been diminished in the name of theoretical principals that are irrelevant to what I need to accomplish. 

[Nic Brough -Adaptavist-]

>Honestly I'm incredulous at how you both have responded.

I cannot speak for myself on your understanding of Marks's response, but they gave you an honest and accurate one.  He has written it up better than I would.  It is not quite what I would have written, but it is, in my opinion, right.

>Sounds like the short version of the answer is "I understand what you need,

Yes, we have, you want to be a bit more agile.

> The purest form of Agile is the form that enables the team to maximize delivery of working software.

Yes, the whole point of Agile is to deliver.  You can't do that when your process and reporting are broken like yours.

>Regarding "focus on the story" and "one workflow"

Another thing not mentioned, the simple story is,as mentioned, you have a story, deliver that thing.

- that is exactly what I want - I want to be able to measure work at different points throughout the issue lifecycle. Maintaining two boards seems like a lot of work to achieve this very reasonable and simple goal.  So don't.

This really is not as complex as you seem to think.  

[Mark Segall]

@swheat - The point we're trying to make is that at the very core of Agile, is the story.  Velocity is based upon the aggregate of stories and the burndown is based upon completion of stories so Atlassian or any competitor that embraces Agile methodologies is not going to make up something that doesn't exist in the Agile space (i.e. A burndown based upon team activity/status).  

It's also important to note that you'll run into the same issue with any enterprise system (ERP, CRM, etc.). All such systems are designed for some type of industry standard business process and successful implementations require customers to adopt those industry business processes rather than trying to employ heavy customizations to make the system fit the process.  Atlassian is no different.

In a nutshell, my response was intended to:

• Educate on why Atlassian is not going to make these changes
• Educate on best practice team structure to get the most out of Jira
• Offer an alternative solution if you were unwilling/unable to make the team adjustments provided

So, my response was not intended to diminish, but instead hit on the points I just summarized.  

One more piece of advice if you're going to continue down your existing path.  Instead of viewing a burndown, you could create a dashboard and leverage the average time in status gadget as a means for seeing how long issues are staying in a specific status and use that in your retros to identify ways to shrink that time.

[swheat]

@Nic Brough -Adaptavist-  I don't need any personal attacks from you. 

What evidence do you have that my team does not deliver quality software? What evidence do you have that my process is broken? 

As for my reporting being broken - that is self-evident at this point.  I'm glad we are both in agreement on that.

[Nic Brough -Adaptavist-]

I am sorry that my writing came across as a "personal attack".  It was certainly not intended as any form of attack.

I did not question your team's delivery capability though, please don't attack me with that.

I was merely pointing out that you have a conflict - you want to be "Agile", but your processes are probably not (I am guessing at that, but "handoff" is usually a very strong indicator that a group is not Agile)

"Broken" was far too strong a word.  I should have said "not consistent."

[Mikhail Sasnavik]

Hi there. I was searching this forum and marketplace for an answer to the same demand. 

Big shoutout to Danut M _StonikByte_ to mention their app as a solution in this thread

I tried it in my test Jira instance and it just does the job!