Scrum and Kanban Boards with Backlog in One Project

LoriAnne Carpenter

How do you take advantage of the Kanban backlog for a Kanban board in the same project with Scrum boards?

We have two dev teams, each running scrum with dedicated scrum boards in one project. In that same project, we have a Kanban board for our production support team. (We had this Kanban board in a separate project, but needed to consolidate into one project for various reasons).

I had to adjust the project workflow to include a Backlog status (assigned upon creation of an issue) in order to take advantage of the Kanban backlog, but bizarrely this somehow conflicts with our Scrum backlogs. Any issues with status = Backlog do not, in fact, show up in the Scrum backlogs. It's important for our Kanban board to have both a `Backlog` status as well as a `To Do` status, as backlog is where we prioritize, and To Do is the queue for work that's ready for dev.

Is there something I am missing? Have I configured this wrong? 

Thanks in advance!

Andy Heinzer

Hi LoriAnne,

These two board types work differently in Jira as you have already noticed in regards to backlogs.   Kanban boards have a relatively new feature called kanplan, this allows you to choose issues in a specific status (usually called backlog) to appear on that kind of board.  But Scrum boards will have a completely separate page for managing backlog and determine what issues go into the planned sprints.  

What are the specific board filters that each board is using here?  I want to see the JQL syntax for each board to better understand what issues are getting pulled into each board.  I suspect that your scrum board might be setup to look for issues in a specific status, in which case it might require you to change one or more filters to make this work.

However I have to question the motives behind trying to use both boards in the same project.  I know it can be done, but I'm interested to learn more about the use case here.  Are you wanting to see the exact same issues in both board are all time?

These two boards have very different means of removing issues from them when completed.  For example, when a sprint is finished, those issues completed in the sprint will no longer appear in that board.   Kanban does this differently by using a subfilter on the board. Only when issues no longer meet the subfilter criteria (which defaults to unreleased issues or issues without a fixversion value) will those issues be removed from the board.  

So I can see potential scenarios where it could be really difficult to try to use both board types in the same project to manage the same issues.  It might not be feasible to synchronize the content of both board types to show issues in all expected states.   What happens when an issues is completed in a sprint, but fails to get into a specific version number release?  The issue can disappear from the scrum board, but remain in the kanban.  

In short, it could be really complicated to try to use both competing agile boards/methodologies on the same body of work, this approach is not something I would openly recommend to everyone.   If the board filters are significantly different and meant to separate different bodies of work in the same project, then perhaps this could work out here. 

Sorry to write a book in response.  I am interested to learn more about your environment to see how we can help here.

Andy