What is best workflow setup to have new issues start in backlog?

I setup my kanban board with my project and did the simplify workflow step. However, new issues coming in were ending up in "To Do" instead of backlog. I would llike to only have things in ToDo that I have had time to prioritize so my team knows what is important to work on. So, I went into the workflow editor and moved the "New Issue" transition line from Open to Backloged. And this worked, new issues come in backlogged. However, on the kanban board when I drag an issue from backlogged -> Todo it now provides 2 drop zones within that column. One for "Opened" and one for "Reopened". How can I make it so backlogged -> todo can only mean Backlogged -> Open, since Reopened doesn't make sense in this context. Some how the simplified workflow without my changes didn't have this behavior, and I can't quite figure out how.

Thanks

3 answers

Hi pdm,

It looks like you have converted the default JIRA workflow in to a simplified workflow. As you can see, the simplified workflow has two 'Open' steps, 'Open' and 'Reopened'. If you look at your column configuration for your board you will see that there are two statuses in the 'To Do' column, 'Open' and 'Reopened'. That's why you're getting two drop targets. If you do not want two drop targets, just delete one of those statuses, probably the reopened one.

As you know, you can definitely have a backlog in Kanban, though we haven't yet enabled the 'Plan' mode of kanban boards in GreenHopper. I'd recommend a two board approach, one board with two columns, Backlog and To Do, and another with To Do, In Progress, Done etc. This means you can use the first board to prioritize the backlog but the team can use the second board to only see things that need to be worked on.

Thanks,
Shaun

Thanks this is helpful! I did not realize that ordering between boards would be shared. I setup a scrum board with the same filter/projects and that let me organize the backlog, but it doesn't work so well for moving things into todo, since i'd have to start a sprint to accomplish that it seems. Setting up a 2nd kanban board would still be somewhat helpful for organizing backlog/todo, but having planning be available in Kanban would be the best. I really like the way you can see a ton of issues at once with the concise layout. I hope planning mode comes to Kanban soon. Having exactly what is in scrum without the 'sprint' UI would be good enough for me.

Hi pdm,

I'm not sure what you mean. You can definitely have two Kanban boards with just one column in common to achieve what you want.

I'm suggesting one Kanban board for planning with two columns: Backlog and To Do. Than another Kanban board for working where the first column is To Do and the other columns are whatever you need. When you move an issue from Backlog to To Do on the planning board it will appear in the To Do on the working board. Does that make sense?

You won't need a Scrum board at all. When we enable plan mode for Kanban we currently expect it to be exactly like I've described (i.e Plan mode will be just like work mode but have only two columns where the second column is the same as the first column on work mode).

Thanks,
Shaun

What I am trying to say is, that the scrum 'plan mode' is more compact, than the simulated planning mode of having a kanban board for planning, with just Backlog and Todo. That is, I hiave a lot of issues, and only so many can fit on the screen at once. Making drag/drop sorting easier. So, the 2nd kanban board for plannig is useful, but the compact view of scrum planning mode is more useful.

Thanks again for your help with the 2nd board idea.

Example:

As far as I know, there is no real backlog in Kanban (at least in GreenHopper, for now). Hence creating a kanban board in Greenhopper gives you no option at all to organise a backlog of any sorts. However in Scrum mode there is a backlog, appearing in the "Plan"-view of the board. This siew is just not available in Kanban.

What you are describing is a modified workflow. as far as I now JIRA does not allow any (custom) status in front of the "open" status unless you force it to. I'm not entirely sure how the simplifiy workflow option works, but I strongly suggest to cross check with the instructions listed here: https://confluence.atlassian.com/display/JIRA/Configuring+the+Initial+Status

For Scrum we use something like that.

Keep in mind that Crucible is responsible for shifting to the "In test" status.

To get to "In test" issue has to have at least one review and no open Crucible Reviews.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,755 views 11 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot