What are your thoughts on this Kanban + Scrum workflow?

Claudio Medina1

We're a game development team. We're using a Scrum board to plan development and see the big picture. The board filter issues from all the areas. Issues are created with the BACKLOG status and they have to be dragged into a sprint and then change to OPEN before they show in their respective Kanban Board/Area (Programming, Art, Production...).

So basically this means that everbody in our team can log issues, but the project manager will have to assign them to a sprint and open them before they show up in the day-to-day working boards.
Does this seems like a good workflow to you? Any suggestions?
I just wished that not every user or department had to go to this "moderation" process. For instance, we don't really see the need for us to be apporving Marketing tasks, we would rather let them manage their Kanban board as they please. But since we cannot assign a different issue status on creation for them, I don't know how to help.

Nic Brough -Adaptavist-

That's not really the way Agile is usually done.

The usual generalised approach is to say "here's a big pile of items that need doing". That's your backlog, and you expect issues in there to be in states that mean "needs doing". You prioritise and estimate the more urgent ones, building up to a point where you've got estimates that are at, or slightly beyond what you think you can do in the next sprint and then start the sprint.

You do NOT usually change the status of the issues in the sprint. If you imagine your big pile of items as cards, you're basically taking the top chunk off the top and writing "sprint X" on them. They're still in the backlog, you've not changed their status or anything else.

Now, when your developer comes to work on something (I'll skip over who assigns/gets assigned, it's not important here), they should pick up the next card and go "I'll work on that", pulling it out of the backlog and into a status/column meaning "it's in progress".

A scrum board helps you with the prioritising and handling a sprint. You can set up more boards if you want, and Kanban ones are rather handy for users who don't really have an interest in the sprint (or aren't working in sprints at all). The trick with boards is to remember that they are a VIEW of a set of issues, so you can essentially use them how you want.