Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

When opening a new sprint all tickets in 1 column on our second board go into Backlog. Why?

Clare King October 20, 2021

I have 2 boards set up: a Dev board and a Test board.  There is a flow between the boards such that once the developers have done their work they put the ticket into the last pipeline on their Board, which is the first pipeline on the Test board.  

When I close a sprint I always set the unfinished tickets to move into the next sprint.

When I start the new sprint all the tickets in every pipeline on both boards EXCEPT this one pipeline which connects the two boards, moves into the next sprint and stays in its location on each board.  All the tickets in this joined pipeline go into the Test board Backlog.  

So far I have tried changing the status of this pipeline, using BACKLOG, and READY FOR TEST.  I have also tried changing the ticket statuses from IN PROGRESS to DONE. Changing the statuses of tickets and pipelines did not change this behaviour.

I need the status of the tickets to show as DONE otherwise the reports don't work (we can't see how Dev work is progressing unless tickets change status to Done).  

Can anyone shed any light on why this is happening?  It's incredibly time consuming having to go through all the tickets in Test Backlog and put the relevant ones back into the sprint board every 2 weeks.

 

 

 

1 answer

0 votes
Trudy Claspill
Community Champion
October 20, 2021

Hello @Clare King 

Welcome to the community.

Can you provided a detailed example of what is occurring? I am lost between your comments that you move all the tickets to the next sprint, you see that they are there (except the ones in the status shared between the boards), the ones in the shared status go into the Test board's backlog, and then your last comment that you need the status of the tickets to show as Done.

Can you share with us...?

1. the workflow/statuses for these tickets

2. The columns and status mappings for each board

3. The details for a specific issue's movement through the statuses, and the how the end results is not meeting your needs.

Clare King October 21, 2021

1. I have 2 workflows, one for bug tickets and one for everything else. The bug workflow starts with BUGS TO DEV:

bugticketworkflow.pngissueticketworkflow.png

 

2. Dev Board: Column Title is "Test", Status is "READY FOR TEST"

Test Board: Column title is "Ready for Test", Status is "READY FOR TEST"

 

3. All tickets move from either TO DO or BUGS TO DEV into IN PROGRESS, then READY FOR TEST whereupon they appear on the Test Board and then move through that.  All ticket types that are sitting in the READY FOR TEST part of the workflow go into the Test board backlog when a sprint is closed/a new sprint is started.  All tickets are marked with status 'Done' when they are moved into READY FOR TEST so that they can be used in the reports.

Trudy Claspill
Community Champion
October 22, 2021

Hello @Clare King 

I'm sorry, I'm still not clear on exactly what you are trying to accomplish or the problem you are trying to solve.

I understand you have two boards; a Dev board and a Test board.

Are you trying to run separate sprints for Dev and for Test? Can you explain how you are creating sprints in each of these boards?

Is "Ready for Test" the status that is shared between the boards?

Can you show us the Columns page from the Board Settings for each board?

You said "I need the status of the tickets to show as DONE otherwise the reports don't work (we can't see how Dev work is progressing unless tickets change status to Done). "

An issue cannot have more than one Status. It cannot be both "Ready for Test" and "Done" at the same time.

It appears that you are trying to track development work separately from testing work (for the item that was developed). It sounds like you are trying to run Sprints for development separately from sprints for testing. It sounds like you want to be able to show "completed" stories for development when the development work is done and the issues are set to "Ready for Test" while at the same time showing that work remains to be done for the Test team. And it sounds like you are trying to do this using a single issue to track both the development and testing effort.

Have I understood your scenario correctly?

If I have, where exactly in this process are things not working the way you desire?

I know this sort of scenario has come up in other posts in this community. You can search for those posts to see the various advice posted on them. My advice in this scenario is generally two-fold

1. When tracking dev/test work in a single issue, the issue should not be considered complete until the testing is complete.

2. If you absolutely must track work in a manner where development and test efforts are considered separate, and be able to show development work completed in sprints when an issue becomes "ready for testing" , then you should track the development work as one issue and the test work as a separate, linked issue.

Trying to use a single story to track two different work efforts and show the first half of the work as "complete" when the issues is not completely through the workflow doesn't work well and is very difficult to get implemented.

Like Bill Sheboy likes this
Clare King October 25, 2021

So I'm trying to run both boards to the same sprint schedule. Jira does not let me start a sprint in one board and then start a sprint in the other board - I can only start a sprint and complete a sprint. This is how I want it to work though so this is fine.

Yes, Ready for Test is the status that is shared between the boards.

The statuses are either grey, blue or green.  The green colour signifies 'Done' in relation to the reports.  Grey signifies 'To Do', blue signifies 'In Progress'.  

I want a single ticket for the piece of work. I am using XRay to apply one or more tests to that ticket once the development work has been done. I want the ticket to flow through the Dev Board, appear on the Test board once moved into the final column of the Dev board and then flow through the Test Board as the testing methods are applied to it.  I do not want to have to write separate tickets for development and testing as this is inefficient. I did have the grey/blue/green todo/in-progress/done applied to the tickets originally such that the status would not be green/considered done until testing was complete.  This however meant that we could not use the reports to plan/manage our development workload.  If Jira needs us to only apply green/considered done 'status' to our tickets once tickets have passed testing then we will have to consider how to work differently as a team. 

Here are screenshots of the boards and their columns.  

Dev Board

DEV_columns.png

 

Test Board

TEST_columns.png

 

Ultimately, if you can tell me what to change such that when a new sprint is started the tickets in the Ready for Test column remain there rather than all being moved into the Test Board's backlog, then that is what I will do :)

Trudy Claspill
Community Champion
October 25, 2021

Hi @Clare King 

Thank you for providing the additional details about your scenario and configuration.

The short answer is, I don't think there is a way to solve your issue with the way you have set up your project, your statuses, and your workflow.

Having said that, I'm not familiar with Xray so I don't know what is possible or what additional limitations are introduced by that.

As to the inefficiency of having a separate issue for testing, you have to measure the perceived inefficiency against the struggle to get the boards and reports working the way you want with your current setup. If you are concerned about having to manually create additional issues for testing and linking those to the dev issues, that could be handled by automation that is triggered when the dev issue is set to Ready For Test (Done).

 

Here's the longer version of that answer.

There are three things in your response for which I need more details.

1. You said you are running the boards on the same sprint schedule. Are you trying to use the same individual sprints in both boards with both Dev work and Test work in a shared sprint? Or do you set up a Dev Sprint for the development work in the Dev board and a separate Test Sprint in for the test work happening at the same time (but on a different set of issues) in the Test board?

2. You said you could not use "the reports to plan/manage our development workload" unless you make the Ready For Test status part of the "Done" Status Category (the statuses that are green). Which reports were not working and how did they not work when Ready For Test was part of the In Progress (blue) Status Category?

3. You said "Jira does not let me start a sprint in one board and then start a sprint in the other board - I can only start a sprint and complete a sprint". Can you provide more details on exactly how you are defining, starting, and completing your sprints?

Regarding the third question above, you may be encountering the situation where you are allowed to have only one active sprint on a board. If that is the case you need to get Parallel Sprints enabled. That is a Product Configuration option for Jira, and as such would enable Parallel Sprints on all Scrum boards.

Alternately, perhaps you mean that you can't have the one story in two active sprints at the same time. That is by design in Jira.

 

I did an experiment that I think is like your scenario.

I created a project with statuses

- To do

- In progress

- ready for test

- done

The last two statuses I assigned to the Done Status Category (green).

I created two boards. In the first board I set the filter to include issues only in the first three statuses. In the second board I set the filter to include issues only in the last two statuses. So "ready for test" was the shared status.

In the first board I added a story to a sprint and started the sprint. I set the issue to "ready for test". At that point, because that status put it within scope of both boards, then the first board's active sprint started displaying in the second board. 

I then Completed the active sprint in the first board. It showed the one issue in the "ready for test" as Completed for the first board. When I completed the sprint, that one story in the "ready for test" status moved to the Backlog list in the second board. I don't see any way to avoid that because

1. the issue can be in only one active sprint at a time, so it can't be in both the active sprint for the Dev board and an active and separate sprint for the Test board, and

2. When you Complete the sprint in the Dev board, the story is considered done. It won't give you an option within that process to assign the story to another sprint, because it is done and (from the Dev board perspective) it doesn't need to be assigned to another sprint. Since it can't automatically be assigned to another sprint within that process, the only place for it to go is into the Test board Backlog.

 

With Parallel Sprints enabled, and a unique sprint defined on each board, I was able to have a sprint in the first board Started with issues for 'dev' work in that sprint, and at the same time I was able to Start a sprint in the second board with 'test' work in the sprint. One quirk to note is that for any issues in the shared status, when those issues are in an Active Sprint in either board then those Active Sprints will show in both boards. But only the issues that are in the shared status will be visible in the "other" board's active sprint.

Like Clare King likes this
Clare King November 3, 2021

Thank you so much for all your input on this @Trudy Claspill I'm learning a bit more now about how X-Ray works, and with this in mind and your feedback I think I'll reconfigure my boards so that I have separate Dev tickets from Test tickets - When using XRay specific test tickets are created, so it makes sense now to change to your initial suggestion.  The XRay test tickets and Jira Issues are linked so I could possibly apply some automation such that when the test ticket is closed the Dev ticket is closed too, thereby keeping both boards tidy.  :-)

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events