Kanplan: where your backlog meets kanban

There’s no silver bullet when it comes to picking an agile framework for your agile team. Whether you use kanban, scrum, or a combination of the two, like scrumban and kanplan, agile is a team process. Every team needs to figure out which framework works best as a foundation for how to plan, track, and release great software.

Kanban aims to give team members just enough work so the team is consistently working at capacity. Teams that practice kanban benefit from flexible planning, clearer focus, and total transparency because whatever’s on the board is the top priority. That’s what developers are working on. Kanban is great for operational teams focused on continuous delivery with changing priorities.

By contrast, scrum divides work into a series of fixed-length iterations called sprints; whatever is scheduled for a sprint is the team’s top priority (e.g. a particular feature or group of features). Product teams with a clear roadmap and prioritized chunks of work typically benefit most from scrum.

But maybe your team would benefit the most from a combination of scrum and kanban? Or wants to transition from scrum to kanban? If that sounds like your team, the solution is scrumban. This mixed methodology manifests itself in different ways, but the most common trends among scrumban teams involve using sprints with a backlog from scrum, and WIP limits and cycle time from kanban. (Note: cycle time is the amount of time it takes for a task to go through a team’s workflow.)

What about teams that don’t want to work iteratively, but still want the ability to backlog groom? Kanplan (or activating the kanban backlog feature) in Jira may be the answer.

Kanplan is a mixed methodology for practicing agile software development. Like scrumban, it combines features from both scrum and kanban. Kanplan is ideal for teams who want the ability to backlog groom, but don’t want to work in sprints. 

Atlassian’s build engineering team is in charge of a platform used to build, test, and deliver Atlassian software. Developers depend on a reliable infrastructure and fast Continuous Integration (CI). Four years ago this looked like 21,000 builds per month. Today this number exceeds 150,000 builds per month.

This ability to scale can be attributed to team growth, moving from Subversion to Git, automated testing, and something less obvious: the decision to move from scrum to kanban. The nature of build engineering work (think ad hoc requests, incidents, innovation work) didn’t fit well within a scrum framework. So the team decided to introduce scrumban, which quickly turned into kanban because the team didn’t like working with sprints. But, it turns out, kanban wasn’t the elixir they hoped for either. Like many teams, they tried to make it work. They went from one board to multiple, a support engineer board, a project work board, and others, all with different workflows. But their biggest pain point across all boards? The “wasteland,” as one team member put it, of untriaged issues that needed to be moved into ready for work mode. Once in the In Progress column, the team was good to go, but their To Do column – the wasteland column – was just that: a wasteland.

Our build engineering team tried to combat their long and disorganized to-do list with daily stand-ups and weekly planning meetings. But what they really needed was a backlog instead of more meetings.

Since kanban boards traditionally don’t have backlog functionality, product managers, development managers, and team leads use issues in the first column to plan. As this list grows, it’s hard to see and prioritize issues. The build engineering team split up their boards based on different areas of work, but the combined team board stayed overwhelming (a lot of scrolling is involved).

So instead of trying to figure out different ways to reorganize the team, boards, or reinventing the wheel, the Jira team decided to bring backlogs to kanban. The kanplan feature introduces a wide column backlog with issues in a listview. This splits the kanban board into two different screens; the backlog for backlog grooming and the kanban board for the engineering team to select and move tasks through the workflow.

This functionality is no different than the backlog of a scrum board in Jira. For example, when you click the backlog icon in the sidebar, it takes you to a wide column of backlog issues. After grooming your backlog, you can drag and drop issues into the next step in your workflow.

This combination of the backlog screen from scrum and the kanban board into one agile board functions like a scrum board backlog. When you click on an issue, the issue detail view shows up. Focused views like the issue detail view allow each member of the team to perform tasks more quickly with less distraction.

Finally, for those non-scrum teams that use epics and preassigned versions to organize their releases, they can benefit from tools found in scrum boards like view issue or quick edit. This simple and quick editing gives product managers, development managers, and anyone else working in plan mode, the ability to efficiently manage epics and versions.

Kanplan is meant to, as one customer put it, bring you “the best of both worlds.” You can move cards around without having a sprint in progress and enter tasks in a backlog to help you plan better. It removes the wasteland that the build engineering team at Atlassian experienced and gives kanban teams a plan mode that hasn’t existed in a kanban world before. It also shepherds in a new way to do work for teams that don’t feel like kanban, scrum, or scrumban give them the foundation they need to do the work they want.

By opening up the plan mode on a kanban board, teams new and old to kanban can find ways to make this agile framework work instead of trying to follow best practices that might not apply to their team. Remember: agile development is about continuous improvement over best practice.