Can I tie a Kanban board to a Scrum Board?

[Eric Bailey]

We currently have been running 2-week sprints via a Scrum Board.  Management has constantly been directing us to work on tasks created after the sprint has started.  Usually, these are tasks that are negatively impacting our client base, but are not so urgent they have to necessarily be worked right away.  Previously, we have been adding these tasks to the sprint as injections and developers have worked them as the next item when they completed the task they were working on.  

Due to the negative impact on our planned work, my manager is looking at tracking these via a Kanban board outside of the Sprint Scrum Board.  If they can't get to them by the end of the sprint, they will be planned for the next sprint.  Note, these are "important" tasks that need to be worked even though the "Priority" on the ticket doesn't reflect that.

Convoluted at best, I know.  But in any case, is there any way to tie the Scrum Board to the Kanban board so developers can easily jump over to that board should they have time to work those items?

[Ste Wright · Accepted solution]

Hi @Eric Bailey 

In my opinion, this isn't a great solution - adding them to the Sprint shows the impact of unplanned work on planned deliverables. Doing this "separates" them out, and has the exact same impact on the dev team, but means they have to check/update issues on 2 boards rather than just 1!

---

Mikael is correct that the Boards will be both listed from the left-hand menu (assuming it's for the same Project). But these are just two separate boards. You couldn't have them filtered in the backlog to be "pulled" into the Sprint once a dev is free instead?

---

I'd also consider...

• Modifying the Scrum filter to ensure these issues are not visible on both Boards
• Exempting active issues from the Kanban filter

...so there's no confusion or double-handling of tasks.

Ste

[Matt Parks · Accepted solution]

If your boards are associated with a particular project, they will show up in the drop-down list in the left-hand sidebar. If both your Scrum board and Kanban board are associated with the same project, they will both be in the same drop-down list, which will make it easy to move from one to the other.

The way to associate a board with a project is to have that project as part of the filter query that populates the board.

At my company, the boards pull in any work that is assigned to the team (based on the Team field), but we include the project that the team works out of the most. The queries are written in a way that they pull in work for the team regardless of the project, however. As an example:

project = GROWTH and Team = 12 or Team = 12

In the below example, the Cache Money board is the one that is shown in the drop-down list but, if I clicked the list, I will see all of the boards associated with the GROWTH project.

[Mikael Sandberg · Accepted solution]

It is possible, at its core boards are just filters showing different issues. So you can create a Kanban board that is using the same filter as your Scrum board is using. You could even limit it so the Kanban board only show the issues that you have marked that the developers need to work on.

[Eric Bailey]

We have a Scrum board that will include the tasks from the Kanban board in its backlog (not in the sprint itself).  We also set up the Kanban board to simply pull in anything with a specific label, currently "Extra".  These items have NOT been added to the sprint.

We are trying to see if a dev is working on the Sprint board and runs out of tasks, is there a way to have a link over to the Kanban board to pick up the "Extra" work, or will they just need to know the Kanban board?  Everything I read leads me to "no, they are separate".  

Of course, the default behavior is to inject the tasks, then try to pull a report with all the injections/removals from the sprint. 

[Mikael Sandberg]

They would have to know the board name. It has been a while since I used JSW DC, but I believe there should be a carrot button next to the board name that allows you to switch between boards that lives within the project you are on. Something like this:

That should list all the boards within the project.

[Eric Bailey]

I truly appreciate all of the input on this.  There are some company setups and pressures preventing some of the suggestions.

1. @Ste Wright @Matt Parks @Mikael Sandberg I like this idea, however.....When Jira was set up years ago, the company set up "Projects" as meaning the type of development work that needs to be done.  For instance, Automated Processing, File Building, Internal Tools, GUI, etc.  The team works on all of these "Projects" during a sprint.  As such, the drop-down on the project may/may not be an option.  I will play around with things and see if I can get it to work, but not hopeful.

2. "Pulling" the task into the sprint is exactly what my manager is trying to avoid, hence the separate Kanban board in the first place.  @Ste Wright NOTE:  I agree that this is how we should be working them, with the added step of pushing out an equal-level task to maintain velocity.  I got overridden.

3. Tasks getting added are Management priorities that crop up, but do not have the calculated priority and other criteria to naturally float to the top of the Backlog (unless marked Urgent), so "grabbing the top item in the backlog" isn't currently an option either.  That said, I may be able to combine the idea of the Label I am using as part of the filter in the backlog so it can float to the top, but not sure that will be approved either.

[Ste Wright]

Hi @Eric Bailey 

It sounds like there are some setup issues within your instance, based on the above.

It's complicated though when not everyone agrees - but you're essentially working around the problem it feels like, rather than implementing an appropriate solution.

Ste

[Eric Bailey]

You are correct.  I have been with the company 10 months and my manager has been here 6 months.  We are trying to incrementally get where we need to be, but unravelling the mess that has been in place for 10 years is difficult at best, but we are always optimistic.