A Scrum-like Multi-level Kanban Implementation
This article is part of my series on Competence and Discipline: The Pillars of Excellence, where I try to share my know-how with others. Know-how translates to the dimension of competence. So here, you can learn some good practices[1] for implementing a Scrum-like approach using Kanban. To be precise, it is NOT Scrumban; it is still Kanban. Thus, you can learn the following:
- What does multi-level Kanban mean?
- How to set up a Scrum-like Kanban approach?
- How to use epics as a flow-like alternative to sprints?
- How can I set up everything in Jira?
Similarities and Differences between Scrum and Kanban
Following David J. Anderson’s definition, Kanban, in the context of software development, is a lean, flow-oriented method to foster evolutionary change. It consists of four principles and six practices — and that’s it. Scrum is a framework for agile software development defined by the Scrum Guide. It consists of three accountabilities, a process of five events, three defined artifacts, and five values.
In short, Scrum and Kanban are entirely different in their general approach.
Scrum asks you to implement the framework and use it. There are some degrees of freedom, for example, on how to define backlog items and the development process itself. But everything described in the Scrum Guide must be in place.[2]
With Kanban, you start with what you do now. You use the visualization of your work and process combined with the limitation of work in progress to identify shortcomings and opportunities for improvement.
Therefore, using Kanban, you can end up with waterfall or anything else that fits best your current situation — at least that’s the theory. Thus I will describe what it can look like when you end up with something very similar to Scrum.
Since I think Scrum is an excellent framework for agile software development, I find many aspects of Scrum meaningful. Therefore, I want to use this article to present how the ideas of an iterative approach like Scrum can be transferred to a flow-oriented approach using Kanban.[3]
A Two-Level Approach in Jira
Since most companies I know use Jira, I use an example project I created with my personal Jira instance. Thus, the work item types are the most commonly used Jira issue types. Consequently, I will distinguish between Jira issue types and items as their manifestation.
At first, we need to understand the general structure of our system.
The image above shows the three levels of our multi-level Kanban system. However, since I say level 0 is optional, I call it a two-level Kanban system.
Like Scrum, I use the terms Product Owner (PO) and Development Team (DEV). You can see both roles (or accountabilities) on the right side of each level. I underlined the role that is mainly responsible for the respective level.
The most aggregated items on the top level are epics. Each epic contains stories, tasks, and bugs. And each item on level 1 may contain sub-tasks. However, I never use sub-tasks within epics. The image below illustrates the relations.
Let us now walk up the different levels to understand how they are designed and interact with each other.
Level 0: Support
Every item on Gemba Level may contain several sub-tasks that only act as small checkboxes. Thus, I call this level Support since this way of using sub-tasks supports you in your work, but it’s not a classic task breakdown many teams use with Scrum.
Consequently, with Scrum, you may use the same workflow as for the items on the Gemba Level. Of course, you can do this with Kanban as well. But I want to incentify to have small items on Gemba Level as you do not break them down again.
The smaller your items are, the higher the probability that your deviation of lead times is smaller. This helps you to stabilize your system which supports predictability.
Coming back to sub-tasks, I already described this approach in my article A Kanban Task Management Approach for Jira. Thus I will keep it short at this point.
You see, you can move a sub-task to DONE, and you can make clear that someone is working on it using the status DOING. DELEGATED means that some external party is responsible. Also, this simple workflow underlines that I regard sub-tasks as optional.
Level 1: Gemba
I call this level Gemba because this is where the real work takes place.[4] Meaning this is where the development team creates working software.
Over time, I have worked with many software development teams. Interestingly, most of them, if not to say all of them, came up with more or less the same process in the end.
At first, there is an analysis part, followed by a final refinement. Then the programming starts. After that, another developer does a code review to ensure (code) quality. Then, besides automated testing, there is some manual testing either by the development team or the product owner, and when everything is done, the item is set to DONE.
Since Kanban asks us to visualize the steps of a process, my example workflow for the Gemba Level makes all these steps explicit.
Please note that the grey statuses are waiting queues to ensure the pull principle.
Upstream, Downstream, and Commitment Point
Between REFINED and NEXT lies the so-called commitment point. It means that for every item that crosses this line, the development team is committed to working it off — as soon as possible. Before that, an item is still optional. This mechanism supports the third principle of lean software development, “decide as late as possible.” [5]
See the illustration above. Before the commitment point, there is the so-called upstream. Meaning, that the development team, together with the product owner, prepares the item. When crossing the commitment point, the development team must have all the information to start the implementation work.
To start means that NOT everything needs to be clear upfront. User stories, tasks, and bugs should always be an invitation for a conversation. It means the understanding of an item will grow over time.
Usually, when a developer has started to implement a story, some questions will come up — and that is OK! Otherwise, you would spend way too much time on the analysis part, which would generate waste. Thus, clarify details when the implementation work started.
The downstream is the part of the process where the development team implements the software—meaning, programming, UX engineering, designing the UI, testing, etc. Of course, the first ideas for UX, UI, or architecture already came up during analysis in the upstream. But the team does well if it reduces this upfront work to the necessary minimum.
Split the Jira Boards in Up- and Downstream
I usually split the upstream and downstream into two separate boards where status NEXT is the hand-over. It reduces the distraction for all parties.
Please note that there are minimum WIP limits for the status READY FOR REFINEMENT, REFINED, and NEXT. A so-called minimum order point generates a pull signal to ensure that your downstream never runs empty.
The above image shows the Gemba downstream board. Its first status is the status NEXT. Except for NEXT, there are no minimum WIP limits since the goal is to have as few items in your system as possible.
Sad but true, Jira does not support multi-column WIP limits by default.[6] However, it would make sense to have a common WIP limit for all downstream columns to limit the absolute number of items inside the overall system.
Level 2: Coordination
The Coordination Level holds the issue type Epic only. The product owner is mainly responsible for this level. However, the development team assists or works with the product owner to define, analyze and prioritize epics.
The approach I present here uses epics in terms of work packages. When using Scrum, I often see that epics are used as large user stories that are always open, broken down into smaller user stories, and may grow over time.
Instead, I want to distinguish the use of epics clearly from large user stories. I say that ‘large user story’ is an antipattern because the larger an item is, the larger the uncertainty underlying it — growing exponentially. And that will destabilize your system in terms of the deviation of lead times.
Following Klaus Leopold, I call this level the ‘Coordination Level.’ Thus you are using epics to coordinate the overall work in your system. It requires each epic to have a clear status following a workflow. Each epic must be considered as being done and not being reopened again at a certain point in time.
The workflow is quite simple. After its creation, there is a short analysis part if everything is in place. Then, the epic is set to READY FOR DEVELOPMENT. When the product owner sets the epic to IN DEVELOPMENT, she signals that the development team can start working on its items on the Gemba Level.
Consequently, there is another commitment point on the Coordination Level between READY FOR DEVELOPMENT and IN DEVELOPMENT. Whenever an epic has been set to IN DEVELOPMENT, the product owner and the development team gave their commitment to work off all its contents.
When all Gemba Level items are set to DONE, the product owner sets the epic to READY FOR REVIEW. When the review for an epic has taken place, the product owner or the development team sets the epic to DONE.
Accordingly, the board looks like the following.
Interaction of Gemba and Coordination Level
Quite notably, the items on the Gemba Level are created at first.[7] Thus your approach cannot be breaking large items down. Consequently, I recommend using methods like domain storytelling[8] to explore a domain and user story mapping[9] to create a structured product backlog — without creating epics up-front.
Since we are not using Scrum, we cannot slice the product backlog by sprints into sprint backlogs. Instead, we slice the product backlog using epics. We cluster and package the existing product backlog items by creating epics in the second step.
The epic is now in status DRAFT. Use the epic to describe the goal you want to achieve with the given items inside the epic. It’s also wise to explain why you want to achieve the goal.
Now the product owner moves the epic to status IN ANALYSIS. This status is used to do the following two things:
- Discuss the goal with all necessary stakeholders. Adjust it if necessary and find the proper priority for this epic — at best by using a combination of sorting the epics and applying a class of service.[10]
- Ensure that all needed Gemba-level items are inside the epic to achieve the goal. Of course, when development has started, the team may identify some gaps, and some more issues get added.
The team can only move Gemba-level items to NEXT when the epic is set to the status IN DEVELOPMENT. It means IN DEVELOPMENT is the signal to the team that they can start working on it.
Translation of the Scrum Artifacts and Events
Now that we have our setup described let me explain how this translates to the Scrum world.
Product Backlog
You can regard the upstream part of your process on the Gemba Level as your product backlog. It means everything that comes before the status NEXT is the product backlog.
The great thing about the upstream process is that the status of the items provides information on how ripe an item is. Thus, the column REFINED is a backlog — or prioritized list — of the ripest Gemba-level items.
Sprint Board
You can assume the downstream board on Gemba Level as your sprint board. I would say that’s a no-brainer, but I mentioned it for completeness.
Of course, the sprint board is no official artifact of Scrum. However, most teams I know visualize their progress on a Kanban-like board. Jira calls it sprint board.
Sprint Backlog
On the Gemba Level, the column behind your commitment point is your sprint backlog. In our case, it’s the column NEXT. Also, the Sprint Backlog in Scrum defines what comes next.
However, you don’t use a Sprint Planning meeting to fill up the column NEXT in our approach. Instead, in a flow-oriented way, you replenish items to the column NEXT whenever you think it is necessary or whenever there’s a pull signal by the minimum order point.
As we create epics after creating items on the Gemba Level and we use the epic as a work package, the packaging of an epic is similar to what you do during a sprint planning session. You define which items should be worked off next. And that is what you do when you package and prioritize your epics.
There is another effect to mention. The team can only move Gemba items over the commitment point to the column NEXT where the parent epic is in the column IN DEVELOPMENT.
Since the column IN DEVELOPMENT on Coordination Level has a WIP limit, the combination of epics and the commitment point on Gemba Level has a similar restrictive effect as sprint planning. It ensures the development team’s constant and sustainable pace, supporting the 6th principle of lean software development ‘build integrity in.’ The Agile Manifesto defines it in the 8th principle as follows.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Sprint Goal
Since we use epics as work packages, we should define the goal behind a work package inside each epic. This goal is similar to a sprint goal. The team should ask what they want to achieve with a specific work package.
I recommend using a template stating the goal of an epic and reasoning why it should be done. Usually, the description field of my epics looks like this.
Sprint Review
Having a review with the customer and ideally with the end-user is indeed valuable when using Kanban. For every value-driven product development, it is indeed the essential feedback loop.
Therefore, our epic workflow provides the waiting queue READY FOR REVIEW. Every work package in this column must be presented, ideally in the form of a demo of working software, to customers, end-users, and other essential stakeholders.
Like sprints, I recommend having a review meeting each week or bi-weekly. Thus, whenever an epic is set to READY FOR REVIEW, it is ready to be considered in the following review session. Then, the development team and the product owner present what has been achieved with the given epic, and they can collect feedback. Afterward, the team moves all presented epics to the column DONE.
You might set a maximum WIP for this column. It allows your team to schedule ad-hoc review sessions every time it overruns the WIP limit. Too many items per review session reduce the quality of feedback you receive during a review meeting. Avoid that.
Keep in mind that the review meeting is not an approval meeting. It’s a feedback loop to adjust the product to the users’ needs where the product owner and the development team are in the lead.
Scrum on Gemba Level
Of course, if you say you want to use epics as described above, you can use Scrum on Gemba Level instead of Kanban. Then, use epics on the Coordination Level to track your lead times only since your Scrum implementation now handles your Sprint Review meeting.
From my point of view, embedding Scrum into a Kanban process makes sense since it allows you to provide more transparency and increase the focus on larger topics that may take multiple sprints for completion.
However, whatever you do on Gemba Level, Kanban, or Scrum, the problems will remain the same. But that’s something I will discuss in a separate article since it would stretch the scope of this one.
Therefore, stay focused and flow.
Footnotes
[1] I do not use the term Best Practices since best is absolute. Think about it. In complex situations, you never know if there’s a better practice.
[2] If you need to know what Scrum is, you can read the Scrum Guide. For Kanban know-how, I recommend the knowledge base of Kanbanize. Besides Kanbanize being a great tool, they also provide deep knowledge about Kanban — it also contains good practices by the Kanban community.
[3] However, I will not discuss a Service Delivery Review and how to use the Monte-Carlo Simulation statistical method to do Probabilistic Forecasting. I will also not discuss the very basics of Scrum and Kanban. Instead, I will discuss an example workflow and how it translates to Scrum. Therefore, Scrum and Kanban know-how are required for understanding this article.
[4] You can translate Gemba as the actual place where the real work occurs. See this Wikipedia article.
[5] You can find more information on the principles of lean software development in this Wikipedia article.
[6] Of course, there are add-ons in the marketplace like Kanban Combined WIP. However, I say that multi-column WIP limits must be a standard feature.
[7] It is quite the opposite of what Klaus Leopold tells us about his flight levels. Leopold defines the items on the upper level first. Also, it must be clear that Leopold is not the inventor of multi-level Kanban systems. His flight level approach is only one possible approach to doing multi-level Kanban.
[8] Domain storytelling is an excellent approach to visualizing processes. It’s an intuitive combination of traditional use case diagrams and activity diagrams known by UML. You might read the article Collaborative Modeling: Domain Storytelling as a Catalyst for Product Backlogs.
[9] For user story mapping, I recommend reading Jeff Patton’s book and the articles Story Mapping — Part 1 and Story Mapping — Part 2.
[10] I described how I prioritize using sorted lists combined with classes of service in my article A Kanban Task Management Approach for Jira.
Book Recommendations
Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Kanban from the Inside
Mike Burrows
Kanban Change Leadership: Creating a Culture of Continuous Improvement
Klaus Leopold
Practical Kanban: From Team Focus to Creating Value
Klaus Leopold
Essential Scrum: A Practical Guide to the Most Popular Agile Process
Kenneth S. Rubin
Large-Scale Scrum: More with LeSS
Craig Larman
User Story Mapping: Discover the Whole Story, Build the Right Product
Jeff Patton
Fifty Quick Ideas to Improve Your User Stories Taschenbuch
Gojko Adzic, David Evans
Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software
Stefan Hofer, Henning Schwentner
