User Tools

Site Tools


How Do We Use Kanban at the Team Level When the ART Has a Cadenced Calendar? - SSA

As organizations deploy SAFe we typically see several questions from people wanting to have more information about how Kanban is deployed in a SAFe environment at the team level. People indicate that Kanban may be the more suitable practice for their situation. Others feel that the nature of SAFe makes it difficult to implement Kanban, at least superficially.

This page is aimed at working through those issues to provide an understanding of some specific recommended practices, especially as the team integrates into a larger ART structure. In addition, we will provide a background understanding of both the “why” and “how” to think about these practices so you can adapt them to your context. These are expected to be (at best) a starting point for implementation of your practices. You will improve on these base practices as part of your relentless improvement program.

We will begin buy reviewing the basics of a textbook implementation of both Kanban and Scrum, and then look pragmatically at approaches we can apply both at the team and train level. We will look to leverage the good parts of both Kanban and Scrum to improve our practice.

Spoiler alert! In the end Scrum teams can benefit from Kanban approaches and Kanban can benefit from Scrum approaches. While not a formal method (like Scrum and Kanban) some call this combined approach Scrumban.

How Would You Describe Scrum in a Nutshell?

  • Split your organization
    • Small, cross-functional, self-organizing teams
    • Split your work
    • Small, concrete deliverables
    • Assign someone to be responsible for the work item list and to sort the list by priority
    • Assign someone to be responsible for coaching and facilitating the team
    • Implementation team estimates the relative size of each work item
  • Split time
    • Short fixed-length iterations (Usually 2 Weeks long, but Between 1 – 4 weeks)
    • Potentially shippable solutions demonstrated after each iteration
  • Optimize the release plan
    • Update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration
  • Optimize the process
    • Retrospective after each iteration

How Would You Describe Kanban in a Nutshell?

  • Visualize the workflow
    • Split the work into pieces, write each item on a card and put on the wall
    • Use named columns to illustrate where each item is in the workflow
  • Limit WIP (work in progress)
    • Assign explicit limits to how many items may be in progress at each workflow state
  • Measure the lead time
    • Lead Time (sometimes called “cycle time”) = average time to complete one item
    • Optimize the process to make lead time as small and predictable as possible

As you can see, Kanban is very lightweight and requires a lot of (self-)discipline to implement on a team. The specific practices that Kanban teams might use include:

  • Kanban board shows all work of the team
  • Kanban board shows flow of work of the team so we can find and work bottlenecks
  • Different service levels (classes of service) for distinct types of work (e.g., expedite, fixed date, standard) are identified and supported
  • WIP limits in place and enforced
  • Kanban boards are processed “Right to left, top to bottom”
  • Continuous improvement occurring
  • Cycle time and throughput tracked, and improvements focused on improving these numbers

What Are the Similarities Between Kanban and Scrum?

  • Both are Lean and Agile
  • Both use pull scheduling
  • Both limit Work-in-progress (WIP)
  • Both use transparency to drive process improvement
  • Both focus on delivering releasable solutions early and often
  • Both are based on self-organizing (stable) teams
  • Both require breaking the work into pieces
  • Both optimize the release plan continuously based on empirical data

What Are the Differences Between Scrum and Kanban?

For folks that are into the details of these two methods. They clearly come at the problem of managing knowledge work from different perspectives. The following table provides a clear breakdown of these differences:

Scrum Kanban
Time-boxed iterations prescribed Time-boxed iterations optional.
* Can have separate cadences for planning, release, and process improvement.
* Can be event driven instead of time-boxed.
Team commits to a specific amount of work for this iteration (Sprint) Team commits to work when it is brought to the board for execution
Uses velocity as default metric for planning and process improvements Uses lead time as default metric for planning and process improvements
Cross functional teams prescribed Cross functional teams optional
* Specialist teams allowed
Items must be broken down so they can be completed in an iteration No item size is prescribed although small(-er) sized work is highly recommended
Burn down chart is prescribed No diagram type is presecribed
“Change agent” is “commitment” “Change agent” is “WIP limits”
WIP limited indirectly
* Per iteration
WIP limited directly
* Per workflow state
Estimation prescribed Estimation optional
Cannot add items to ongoing iteration Can add items whenever capacity is available
Prescribe 3 roles
* Product Owner
* Scrum Master
* Team
No prescribed roles
Prescribes 4 events
* Planning
* Daily Scrum
* Review
* Retrospective
No prescribed events
Scrum board is reset between each iteration Kanban board is persistent
Prioritized backlog is prescribed Prioritization is optional

Which is Best for My Team? Kanban, Scrum or ...?

If you treat Kanban and Scrum as if they are competing approaches, or adopt a textbook approach to their implementation, then the advice to choose one approach over the other usually breaks down as follows:

Question Kanban Scrum
Primary Consideration
* Work for the team is more than 50% demand driven (team's priority is responsiveness) X
* Work for the team is most project driven (team's responsibility is predictability, forecasting and productivity) X
Secondary Consideration
* Team questions value of estimation and planning X
* Team struggles to break items into small pieces X
* No or low appetite for significant process change X
* Some or high appetite for significant process change X
* Team members have significant self-discipline X
* Team members have limited self-discipline X

Some people feel like Kanban is easier to implement and so opt for that. The reality is that the WRONG reason to implement Scrum is because the Team is simply unwilling to do Scrum-like events or find that they cannot finish a Story in one Iteration.

A notes on this criterion. Many teams whose work is the result of a ticketing system assume that all their work is demand driven, and that Kanban is therefore their only option. This is a problem in that if the team can plan work, they usually are also able to deliver better and faster over time.

Experience has shown that work coming from the ticketing system does not mean that we must treat every work item as interrupt-driven and therefore you are unable to plan it. For example, teams that are pure production support have different classes of incoming problems and so can vary how quickly you would need to respond to that problem. A production site is down request is going to need a more urgent response than say a minor defect because of a workflow problem. This gives as an option to plan more items and would mean that Scrum practices are useful. For example, if we can suggest to the customer “that they wait for (on average for a 2 week Iteration) 1 week for us to work this defect” then we can treat this as an input into the next planned Sprint (iteration) in a Scrum implementation.

In some instances up to 65% of the incoming work for a Team can be treated this way.

In some ways the discussion about whether you use EITHER Scrum OR Kanban is misleading. Like all agile approaches the best idea is to leverage Kanban and Scrum to improve how you deliver value. Scrum teams can benefit from ideas like understanding the workflow, WIP limits, classes of service. Kanban teams benefit from an understanding of the purpose of Scrum events, roles, and artifacts and incorporate some or all of them into their practice.

Here are some more specific approaches people have tried:

  • Team Examples
    • Kanban Teams are set up as cross-functional
    • Scrum Teams set WIP Limits within a Sprint
    • Kanban Teams Setup cadence of retrospectives, daily meetings, etc
    • Scrum Teams establish (capacity-based) rules for Break-fix or other “interruptions”
  • Team-of-Teams (Scaling) Examples
    • Kanban Teams commit to work on Sprint Schedule to aid in synchronization and Alignment
    • Portfolio and Program level work is set up as Kanban
  • Retrospectives drive improvement
    • Scrum and Kanban as a toolbox of ideas to Leverage
    • Use whatever helps you improve

What Are the Guidelines for Kanban Teams Operating in a SAFe Environment?

A Kanban team within an ART needs to adapt to some of the requirements prescribed by SAFe to ensure alignment to the ART while still maintaining the benefits of the Kanban flow. The following guidelines address some of those conditions to maintain alignment and allow Kanban teams to contribute effectively within an ART.


While there are no prescribed team roles in textbook Kanban, SAFe calls for the nomination of someone on the Kanban team to fill the roles of a Scrum Master and Product Owner as you would see on a typical Scrum team. The following are the ways you would apply these roles on a Kanban or Scrumban team:

  • Product Owner (aka Service Request Manager or Service Manager)
    • Single point of contact for the work of the Kanban team in the Team Backlog (incoming, in progress, etc.)
    • Representation on the Product Management team (PMs, POs for the Train) who define the work of the ART and Teams
    • Attend the PO Sync and represent at the System Demo
    • Accepts User Stories as complete
    • Assigns the User Story to the iteration it is completed in (used for Velocity)
  • Scrum Master (aka Service Delivery Manager, Delivery Manager, or Flow Master/Manager)
    • Experience has shown that there is usually an advantage to having someone who worries about how well the team works even for Kanban teams, aka: the coach of the Team
    • Attend SoS and be on point to provide metrics, work impediments, etc.
    • Focus on team performance and improvements
    • Report on team Velocity

Cadence & Events

ART Events

SAFe is based on a series of events (meetings) held on a cadence, to synchronize activities across multiple teams. This means that at the ART (team-of-teams) level, Kanban teams that are integrated into an ART need to support these events “as is.”

  • PI Planning: to build an aligned plan
    • A SAFe Kanban team is expected to commit to Objectives just like a Scrum team
    • Kanban Teams estimate user stories for capacity and load calculations
    • Kanban Teams plan what they can into iterations (especially for fixed date dependencies with other teams, and any other known work) and usually leave a lot of capacity for the unknown
    • ART Sync (SoS, PO Sync): to ensure we are progressing this PI and getting ready for the next
    • System Demo: to have an objective view of the system we (the ART) are delivering
    • Inspect & Adapt: to help improve the ART (not just team) performance

Team Events

There is benefit for Kanban teams to establish cadences (e.g., ensures time is taken to do the work, makes unpredictable events more predictable, etc.), but unlike Scrum, Kanban teams do not have to use the same cadence for all events. By understanding the purpose of an event, we can determine approaches we could bring into our Kanban implementation.

  • Daily Standup - Kanban Teams meet daily, but rather than just answer questions aimed at understanding whether we will meet the Iteration goal, these meetings are usually needed to prioritize work and plan the teams’ work for the day.
    • Use a Kanban Board as a tool to help visualize the work during this event.
  • Planning – Kanban Teams focus more on prioritizing the next pieces of work than planning an iteration of work. This is done in the Daily Standup, where teams will decide which stories they will be working on that day and ensuring they are story pointed. If needed, teams may schedule a separate prioritization or refinement meeting which should then be on a cadence (e.g. every week).
  • Refinement - For Kanban teams this is usually incorporated in the daily prioritization/planning discussions.
  • Review/Demo - The purpose of the review / demo is to get feedback on the work completed. Kanban teams often demo individual stories as they are completed to get feedback. Many Kanban teams also report lack of participation from customers to these demonstrations, and so see a benefit in setting up a regularly scheduled Review event every couple of weeks where multiple stories are demonstrated.
  • Retrospective - The purpose of a retrospective is to take time to improve how we work. Many Kanban teams set up a cadence of retrospectives to ensure it gets done.
    • At a minimum recommendation is to set up a retrospective at least once every two weeks, so once an iteration.
    • Consider a shorter cadence to improve faster (e.g. weekly, daily)
    • Consider retros as flow based in lieu of a standalone event (see What Can We Do To Improve Our Retrospectives? e.g. POPCORN flow)
    • Be sure to move improvement items into the team’s backlog

Visualizing Work on a Kanban Board

A Kanban board is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency (or flow). When implementing a Kanban board for your team, it's important to include the following:

  • Workflow States
    • Map the teams’ workflow to define the states (columns) of the Kanban board
      • The more workflow states (columns) that are defined (beyond To do, In progress, and Done), the easier it is to identify bottlenecks and optimize the flow.
      • Having more than say 10 workflow steps will result in higher administrative burden, and create a board where it is hard to see the big picture
      • Refrain from basing workflow states on people/individual skill. This allows team members to swarm to a different state as needed.
      • Enable the “pull” method by using “in progress” and “done” states (e.g. Development Done, Testing Done, or Ready for Test). Stories can be pulled from the “done” states as the WIP limits allow.
    • Define clear exit agreements for each State (e.g. code checked in, documentation updated, unit tests run, iteration updated at acceptance). These can be added directly to the Rally “Team Board”.
  • Classes of Service (aka Service Level Agreements)
    • Classes of Service are used to prioritize work based on Cost of Delay – or in other words, prioritize based on urgency and economic impact. Examples include:
      • Expedite – highest priority or cost of delay, not to be interrupted
      • Fixed Date – high cost of delay (e.g. deliverable/dependency to another team)
      • Standard – low to medium cost of delay, typical for most work
      • Investment – intangible; lowest cost of delay (e.g. maintenance task with low prioritization)
  • Work in Progress (WIP) Limits
    • WIP limits restrict the maximum number of work items in the workflow's different stages
    • WIP limits are set based on capacity and adjusted as needed to optimize the flow of value delivered
      • A good rule of thumb to start with is to set WIP for a state to the number of people who are skilled in that Status minus one.
    • WIP limits allow an opportunity to identify bottlenecks in workflows, which can be easily identified on a Cumulative Flow Diagram.


Cycle Time

In Kanban, Cycle Time is a key metric for measuring team performance, process efficiency and identifying bottlenecks.

  • Cycle time is calculating the actual work-in-progress or the time between the work on a user story beginning to the time it is accepted. Keeping track of your cycle times enables you to measure your team performance.
  • Low cycle times mean that your team is efficient. Keeping cycle times down keeps lead time down. The key to keeping cycle time down is managing WIP limits – maybe you’ve heard the phrase… “Stop Starting, Start Finishing”
  • High cycle times indicate stalls, bottlenecks, and backlogs.

A Cumulative Flow Diagram (CFD) visualizes your teams’ workflow (cycle time, WIP, bottlenecks) by charting the total number of work items in each workflow state per day. It’s a fundamental Kanban tool used to understand where teams may need to focus to make their process more predictable and efficient. Ideally you want to see evenly rising bands on the chart as opposed to sudden spikes or flat lines, so watch out for the following:

  • An expanding “work in progress” state may be an indication of a bottleneck or potential problem.
  • A narrowing state may indicate that you have too much capacity in that state.
  • Stepped flat lines suggest work is being batched rather than continuously flowing.


Traditional Kanban teams use cycle time and through-put to understand how much work they can take on (capacity) and forecast when items will be completed. Scrum Teams in SAFe use story points and velocity to accomplish the same thing. The ART Product Management Team needs to be able to understand capacity of the ART and forecast completion. We therefore need a common unit of measure for all teams on the ART – story points!

  • In SAFe, Kanban teams estimate their work in story points, and as stories are completed it’s important to that the PO updates the Iteration it was completed in when they accept the stories. This then allows teams to report back their “velocity” by calculating how many story points they completed in the previous two weeks.
  • Kanban teams estimate all incoming items (including defects, KTLO, etc.) in story points prior to working on the item using:
    • Relative size estimation based on modified Fibonacci numbers – 1, 2, 3, 5, 8, 13, 20, 40, 100
    • Normalized per SAFe guidance so that stories with estimates of 8 and below can typically be completed in a two-week period (iteration).

Want to Know More?

/home/hpsamios/ · Last modified: 2023/03/07 12:26 by hans