How to change status from backlog to open?

[Claudio Medina]

Hello,

We're trying to use a workflow as suggested by one user in this website:
"(...) I created a Scrum board for the backlog. Our daily Kanban board excludes the backlog status which keeps the team focused on WIP. "

What I would like is that every new issue is created with the backlog status, and when it's moved to a sprint, it's changed to an OPEN status. There doesn't seem to be any workflow in the marketplace that has this functionality though.
When a backlog issue is moved to a sprint, it does appear in the to do column, but it's status remains as "backlog". Since I would like it to show up in Kanban boards as soon as it is on a sprint, this is of no use to me.

Any ideas?

[Nic Brough -Adaptavist- · Accepted solution]

>What I would like is that every new issue is created with the backlog status,

Change the "create" transition in your workflow so that it lands in the backlog status instead of Open

>and when it's moved to a sprint, it's changed to an OPEN status.

I don't think you're quite seeing how Scrum boards work with sprints. You gather issues together to be worked on in a sprint. When you're ready, you start the sprint. That does NOT change the status of the issues, it just says "these are the ones you need to work on during this sprint". They're still in whatever status (possibly many) that mean they fall into the backlog, you don't change their status until you actually start to work on them as part of the sprint.

[Claudio Medina]

Thanks for the explanation, Nic.
This is basically what I'm doing now. Would you mind checking my workflow here and giving me your opinion?
https://answers.atlassian.com/questions/285963/what-are-your-thoughts-on-this-kanban-scrum-workflow

[Daniel McGuire]

I agree that this default workflow is painfull.

when you are ready you start the sprint

By starting the sprint, I would see this as equivalent to moving all these tasks to OPEN.

As this is not how it works, what is the point of the OPEN status? You could pick up from BACKLOG and move to IN PROGRESS, skipping OPEN.  I am in the process of trying this step to remove the OPEN status from the default workflow.

[Nic Brough -Adaptavist-]

No. 

Starting a sprint means "we commit to doing the things in the to-do list in this sprint".  You don't need, or even want to change the status. 

Imagine you have a "to do" list of 100 items.

You say "Right, I am going to do these six this week".

What has changed about the way you describe them?  They're still "to do".  It's not a status change, it's a promise to try to do them.  What happens if you don't even look at item 4?  It's still "to do" whatever the reason you never got to it.

Oh, and you're questioning a 4 year old question, and looking at the default workflow, which was better than most of the rubbish that was around at the time, but has, of course, moved on. 

And, finally, yes, you absolutely should move to a better workflow that matches your desired process.

[LoriAnne Carpenter]

And over one year later...

I don't think you're quite seeing how Scrum boards work with sprints.

It's not just a matter of how scrum boards work with sprints. The OP is using kanban in addition to scrum boards, so it's also how kanban boards work with backlogs. Using a backlog with kanban boards requires two statuses that represent unstarted work, because an issue's visibility on the board is based on status, versus the sprint field in Scrum boards. So, using your list of 6 out of 100 items example: you have selected 6 items that are ready for dev, so you change the status of those 6 items to make them visible on the kanban board. 

What this means for your Scrum backlog (which he is using for planning, so is you have an extra backlog status. One obvious way to utilize both of these "unstarted" statuses in a scrum backlog would be to let 'open' = immediate term and 'backlog' = anything beyond that (like a sprint backlog and a product backlog, respectively). Hence the reason for wanting to automate the transition of an issue upon adding a sprint tag.

Now that we've gotten that out of the way, I'd love to hear some suggestions for automating that transition. I've read about custom events and listeners, which sounds like a viable solution, assuming it's possible via cloud.

[Nic Brough -Adaptavist-]

But that's not how a scrum board works - it doesn't (and shouldn't) care about the status in the backlog, that's not what it is for.

This is one of the downsides of trying to use both types of board, the difference between the way they need to work must be understood by the people using them.  Scrum boards do not need to change the status and hence don't have a function for it. 

You're now making bodges between two very different ways of doing things, and this is less than ideal.

[LoriAnne Carpenter]

Read my comment again. I didn't imply that a scrum board should care about the status of an issue, but rather the sprint field.

the difference between the way they need to work must be understood by the people using them

If you read my comment, you would have noticed that I already explained and therefore understand the WHY behind this functionality. My question was not "why doesn't this work the way I want it to;" I am asking for suggestions based on my workaround solution. 

You're now making bodges between two very different ways of doing things, and this is less than ideal.

Didn't ask your opinion on how ideal the solution is. I have a need for this configuration, and I don't need your validation. If you have suggestions on how to automate a transition upon assignment to a sprint, I'd love to hear them. If not, then you can just say you don't have any suggestions and move on.

[M Vijay Kumar]

Hi , 

I am also looking for the similar solution, any update on the above.

[Claudio Medina]

Nevermind previous comment. It obviously remains in other boards even if they are not on the sprint.

[Claudio Medina]

I'm trying to understand this better and it's giving me a headache.
I discovered that if I add backlog to a column in any of my Kanban boards, it then will show up in the board as long as that issue is on a sprint.
But I don't understand why it should remain on the backlog status when on a sprint :S Shouldn't the expected behavior be to change to some other status, like open?