Query Regarding Configuring Jira Community Platform for Accurate Burndown/Burn-up Chart Reports

[Hamza D_]

I would like to seek assistance in configuring our Jira platform to provide accurate and meaningful burndown or burn-up chart reports. Our team utilizes multiple custom statuses, including "Resolved," "Reopened," "QA Review," and "Hold," in addition to the default statuses provided by Jira ("To Do," "In Progress," and "Done").

To align our custom statuses with the appropriate categories, we have classified "Resolved" and "QA Review" as part of the "Done" category, while "Reopened" and "Hold" fall into their respective categories. However, we have encountered an issue when generating burndown or burn-up chart reports. These reports only consider the default Jira statuses, failing to account for our custom statuses.

Consequently, our current reports do not accurately represent the progress of our projects, despite many tickets being resolved or in the QA review phase. This limitation hampers our ability to gain a clear understanding of our project's status and impairs our decision-making process.

We kindly request guidance on how to configure the Jira platform to include our custom statuses in the burndown or burn-up chart reports effectively. By incorporating these additional statuses, we aim to obtain a comprehensive and accurate visualization of our project's progress.

Thank you for your attention and support. We look forward to your expert advice and suggestions.

[Nic Brough -Adaptavist-]

Burn up and burn down both work off a simple binary flag on a board - "is the issue done or not?".

So I think you might have a bit of a broken process.  Is "QA review" really done?  Meaning no more work needs doing by the team(s) using the board?

In Jira, you indicate that an issue is "done" when it is in the last column of the board, and it really is supposed to mean "no more effort required on this issue".

So the short answer to this is to map all of your "done" status into the last column of the board.  Then your burn charts will work.

[Hamza D_]

Regarding the team's workflow, we mark tickets as "QA Review" when the work is completed and deployed. During the sprint, we consider both "Resolved" and "QA Review" tickets as "Done," as they are ready for testing in the following week when moved to the backlog. Since we have 1-week sprints, it's not feasible to test and mark the tickets as "Done" within the sprint duration.

We would like to generate a chart to track the progress of "Resolved" and "QA Review" tickets during the sprint. Can you please advise on how to configure the board and burn chart to accurately represent the work completed during the sprint, considering the above workflow?

Thank you in advance for your assistance.

[Nic Brough -Adaptavist-]

Ok, so you're not really doing scrum, as your "done" items need more work (meaning they're not done).

I would recommend that your dev and test teams work off different boards - the developers mapping QA review into the last column on their board, and the testers  mapping QA review to a to-do column.

[Hamza D_]

I would appreciate further clarification to ensure we are on the right track. We aspire to follow Scrum practices in Jira, but it seems that there might be some issues with our current approach.

To give you some context, our team is relatively small, consisting of three developers, one tester, one director, one project manager, and myself as the junior Scrum Master. Our aim is to optimize our workflow and enhance productivity through effective Scrum practices.

The initial feedback I received mentioned that we might not be effectively using Scrum. However, I'd like to understand in more detail what exactly we are doing wrong and how we can improve our Scrum implementation.

On that note, I have two specific questions:

1. Could you please provide further guidance on the aspects we might be overlooking in our Scrum implementation? Any advice on how we can better align our team with Scrum principles and practices would be greatly appreciated.

2. Additionally, I would like to learn how to set up two different boards in Jira, both running active sprints simultaneously. If explaining this through text might be challenging, I kindly request your assistance in scheduling a brief session where you could guide me through the process.

I understand that your time is valuable, and I genuinely appreciate any support or guidance you can offer. Improving our Scrum implementation is vital for our team's success, and your expertise would be incredibly valuable in this endeavor.

[Nic Brough -Adaptavist-]

Please stop using generative AI to post, it's not welcome because it is usually horribly wrong.

[Hamza D_]

I was using it so you can understand my query as English is not my first language. Anyways so you say we are not doing scrum. My first question is What did you mean by that like what exactly wrong this we doing because we follow or wants to follow scrum in Jira. Basically our team is really small. We have three developers, One tester, One director, One Project Manager in our team and my role is a junior Scrum Master. Please guide me through it. My second question is Can you provide step by step guide how to have two different boards in jira and both are in Sprint? If it can not be understood by chat. Can u please schedule your time to guide me through it about my question 1 it is really important?

[Nic Brough -Adaptavist-]

Ok, it's better to use a translation service than generative AI - write in your preferred language and let google or one of the others translate it into English.  Or even write here in your preferred language and let us use our preferred translator to read it!

In scrum, you have a multi-functional team that takes on tasks (sprint items) and completes many of them in sprints (it's fine to have sprints that only have one item, just unusual), with the aim of delivering something suitable for the end-user. 

Completion means developed, tested, documented and ready for use.  (Not necessarily the end product, but an iteration towards it)

Completion in Scrum is a binary thing - an item is either done, or it is not.  Done means no more work needs doing on it, and that includes testing.  Your QA review status is not "done", the item needs more work from the team.

You don't need two boards and sprints if your teams are doing Scrum - it's one board and one sprint per team.

If you do have separate teams, then yes, use many boards (and sprints) per team.  A common way to handle separate teams is different definitions of done.  A simple case that sounds appropriate for your two teams is to have two boards (one per team) - the developers board would have "ready for test" in the last column, and the testers board would have "ready to test" as their first column, and "tested successfully" in their last column.

[Hamza D_]

So considering Scrum is a binary thing. Our team scenario where we are using sprint of 1 week duration. What is best solution there since it is nearly impossible to test QA Reveiw tickets since we get deployment friday EOD from developers. I can show you via short call meeting how we are managing things in Jira.

[Nic Brough -Adaptavist-]

You should not be bringing stories into a sprint when they cannot be completed within it.  You need to break them up into smaller stories that can be done within the sprint.

[Hamza D_]

I believe I am getting some understanding of your explanation. Currently, when new functionality enhancements or tasks arise, we create tickets for them and assign them based on whether they relate to the front end, back end, or UI/UX. Once the assigned tasks are completed, their status is changed to 'QA Review,' and then we conduct testing on the same ticket. But We can also do that to have the option to create separate tickets for testing and link them to the development team's tickets. When the development tickets are marked as 'Done,' along with all the linked test tickets, we move them to the upcoming sprint for testing. This approach allows us to mark tickets as done during sprints. However, I am wondering if this is a good approach, as it might render the 'QA Review' status somewhat pointless in the Scrum process.

Note: Currently we have statuses of "TO DO ON HOLD REOPENED IN PROGRESS RESOLVED QA REVIEW DONE". And thank you for being so supportive and answering my questions.

[Nic Brough -Adaptavist-]

This is not what Scrum is for.  The point of Scrum is that every sprint delivers something ready to put in front of a user.  You don't develop stuff in one sprint and test it in another (not there's actually much wrong with that in real life, but if you're going to do it, you need to be working with different teams and boards, not pretending you have a multi-functional team.  Every story should be completable within the sprint for a team)

The point of the scrum is to deliver, and that's why it fits in well with Agile - it enables concrete delivery, rather than the vague (and always slipping) promises of Waterfall.