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).
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"
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.
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.
>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.
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!
It looks like you're new here. Sign in or register to get started.
