What are your thoughts on this Kanban + Scrum workflow?

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.

1 answer

1 accepted

1 vote

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.

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 ...

3,338 views 14 20
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