Scaling Scrum with Nexus and Kanban


Everybody wants to Scale Scrum

So you have a couple of Scrum Teams that are working in adjacent areas and you’re starting to face some challenges in delivering value in a coordinated integrative way. This is more or less the time you started searching for “scaling agile” “scaling scrum” and exploring your options. Generally, one approach will be to add some scaling principles and practices. Another approach would be to try and refactor your organization/group so the teams actually don’t need each other that much which will reduce even the need for scaling.

Pragmatically, what I generally work out with my clients is a happy middle – refactor somewhat in order to reduce dependencies, Add the right level of Scaling support based on the number of dependencies you have.

Scaling Scrum w/ Nexus

Today I want to talk about an approach that fits well into this approach (at least in my experience). Nexus is’s framework for scaled product/software delivery. It uses Scrum as its building block and adds the minimum viable set of roles, events, artifacts, and rules that weave together the work of a set of teams.

Nexus Framework
The Nexus Framework –

If you haven’t heard of Nexus before now would be a great time to go read the Nexus Guide. Don’t worry it’s a great short read. I won’t try to repeat it here.

Scaling Scrum w/ Flow and Kanban

As you might be aware, now recommends Scrum practitioners leverage Flow thinking by using Kanban practices and flow metrics as part of their Scrum. We talk about that in the Kanban Guide for Scrum Teams and the Professional Scrum w/ Kanban class (full disclosure – I’m a co-author of the guide and co-creator and steward of the class so care deeply about both…).

What we haven’t talked about much until now in the world is how Flow/Kanban can help organizations use Scrum at Scale more effectively, and specifically how would Nexus look like when leveraging Flow/Kanban.

I’ve been using Kanban as a scaling mechanism on top of Scrum since around 2008 or so and it has been the approach I reach out to most often. (here’s a case study from the LSSC2010 conference about one such implementation, here’s another early talk)

The basis of this approach is to use a Kanban system tracking the work at an integrative higher level than the individual team (Think Features/Epics) and making sure to include upstream and downstream activities that transcend what’s going on inside a specific Scrum Team or Scrum Sprint. This brings transparency and attention to the Flow (or more typically lack thereof) at a larger scale and can help Scrum Practitioners educate/coach their organization about the value of achieving flow and how empiricism is very limited if only applied at a level of a Scrum Team stuck within a waterfall system.

Combining Nexus and Kanban

With this premise in mind, Let’s take the approach we follow in the Kanban Guide for Scrum Teams and the PSK and explore what might be the impact of applying Kanban/Flow to the Nexus Roles, Events, Artifacts, and rules.

Kanban applied to the Nexus Artifacts

In Nexus, all Scrum teams use the same, single Product Backlog. Kanban can be used to visualize the workflow and flow of work on this Product Backlog. This will include all stages of work in the Nexus – ranging from Value discovery, prioritization, refinement, Sprinting, Integrated Increment, Deploying/Releasing, and Learning/Tweaking. The items that would flow on this board would typically be somewhat bigger rocks that are meaningful to the stakeholders.

A new artifact – the Nexus Sprint Backlog helps with transparency across teams during the Sprint and is in addition to the individual Sprint Backlogs the teams maintain. The Nexus Sprint Backlog would essentially be a stage in the Product Backlog definition of workflow. And in this area, the Nexus would typically visualize work that hasn’t started in any team yet, has started in at least some of the teams, and is Done meaning integrated increment is ready and no teams have any work left.

The example below (from 2013 or so) shows one such structure. The interesting aspect here is how this group chose to visualize what’s going on while work is happening at the Team level. You can see that for each small PBI (yellow square) there’s a set of initially empty squares drawn in the Team-level PBI column. These reflect teams that are involved in this PBI and would need to complete their work before an integrated increment can be achieved. They then visualized what team-level PBI was in progress by half-filling the relevant square, and filling it completely when that team was ready to integrate and complete their work.

While Kanban doesn’t have a direct impact on the Integrated Increment, it can bring much more transparency into the process of creating such an increment and using it even beyond the Sprint Review all the way to real users and real feedback (which is how much enterprise-level teams still work – its still rare to see integrated increments being deployed/released throughout the Sprint).

Kanban Applied to the Nexus Events

Refining the Product Backlog is an explicit event in Nexus. Kanban can be used to help the Product Owner and Nexus teams achieve a good flow of refinement – making sure there’s a solid amount of ready work for the Sprint but not too much. Applying WIP limits to the refinement stages can help ensure this healthy flow. Nexus-level Throughput based on PBIs in the single Product Backlog can help forecast how many items are needed for the next Sprint and drive a focused refinement event.

Nexus Sprint Planning can be informed by flow metrics at both the individual and Nexus levels. Throughput for each team can be used to help create realistic plans without too much time spent on detailed estimations – freeing up time to focus on the integration challenges. Teams can use their Service Level Expectations (SLEs) to create a really predictable plan. Challenging integration paths can be identified and can be tagged as special classes of service the teams address appropriately. Teams should also start planning their Nexus-level WIP – how will they avoid opening too many PBIs and actually apply “stop starting start finishing” across the Nexus? Practically this means that a Scrum Team might avoid starting an integrative PBI when they know other teams are only available to work on it later on in the Sprint.

Nexus Daily Scrum can be held in front of the big picture Kanban board and the focus should be on making sure the overall WIP at the Nexus level is reasonable. Again, Stop Starting Start Finishing is applied at the Nexus level. PBIs that are aging too much without being integrated and closed can be identified by visualizing Work Item Aging either directly on the board or using a separate chart. This way, there’s no need to review all the work across teams, just the overall flow/bottlenecks, and specific stalled items.

Nexus-level forecasts can be used in the Nexus Sprint Review to help the Product Owner make transparent what’s possible when and what the options are.

Team level and Nexus level flow metrics can inform the Nexus Sprint Retrospective. The Nexus-level definition of Workflow should be inspected and adapted as part of the Nexus Sprint Retrospective.

Kanban’s impact on Nexus Roles

There’s only one new role in Nexus – the Nexus Integration Team (a.k.a NIT). The NIT is accountable for ensuring a Done Integrated Increment is produced at least once every Sprint. In other words – they’re responsible for the healthy flow of work in the Nexus! So obviously Kanban and flow metrics will be invaluable tools they can use to help Nexus get transparency on its end-to-end flow upstream, throughout the Nexus Sprint, and downstream. The NIT would typically be the role responsible for creating the big picture Nexus-wide definition of Workflow and making it as well as flow metrics transparent as part of their role of coaching/consulting/highlighting flow issues for the entire Nexus. Kanban and the flow metrics provide a place for the bottom-up intelligence from the Nexus to be used to help achieve flow.

The Product Owner in a Nexus will appreciate having the Nexus-level Kanban Board based on the Product Backlog and the aggregated view of flow across the Nexus. This “altitude” provides the right level of transparency they’re typically looking for. Flow metrics applied at this level can help the Product Owner understand the capabilities of the Nexus and assist them in forecasting.

The Scrum Master of the Nexus Integration Team will have a key role in educating the NIT and the Nexus about Flow/Kanban and applying the practices and metrics appropriately.

Definition of Done and Definition of Workflow at the Nexus

In a Nexus the NIT is responsible for a definition of “Done” that can be applied to the Integrated Increment developed each Sprint. Similarly, the NIT would be responsible for the Nexus-level definition of Workflow. Individual Scrum teams will work within this overall big-picture definition of Workflow.

When it comes to the definition of Workflow for each Scrum Team, they are responsible for it and will self-organize to define, inspect and adapt such a definition that will help them achieve great flow. Having said that, there’s great potential for cross-pollination across the Nexus and the NIT would do well to facilitate sharing of ideas and insights about the team-level definition of Workflow, maybe during the Sprint Retrospective.

Artifact Transparency

Scrum and Nexus are based on Transparency. Kanban is an excellent complementary tool to help achieve complete transparency of the flow of work at the Nexus and support process-level empiricism. Fast feedback loops created by achieving flow through a reduction of Work in the Process help accelerate transparency as to whether correct assumptions have been made in selecting the work and developing the Increment.

In this way, Flow and Kanban help minimize risk and maximize value both at the Scrum Team level as well at scale at the Nexus.

Nexus and Kanban – Achieving empiricism and flow at scale

In this article, I’ve gone through the exercise of thinking through how the ideas of Kanban and Flow can be used to complement Nexus and create a lightweight scaling framework.

SPS scaled professional scrum

The Scaled Professional Scrum class is the best place for a deeper dive into the lightweight perspective on how to scale Scrum. When I’m teaching the class I’m bringing flow thinking into it as well.

Subscribe for Email Updates:



Lean Budgeting
Elastic Leadership
Agile Product Ownership
Scrum Values
Lean Risk Management
PI Planning
Lean and Agile Techniques
Rapid RTC
Nexus vs SAFe
Portfolio for Jira
Agile in the Enterprise
Operational Value Stream
Scrum Guide
Value Streams
Games and Exercises
ScrumMaster Tales
Pomodoro Technique
Development Value Streams
Certified SAFe
Kanban Game
AI Artificial Intelligence
Sprint Retrospectives
Agile Exercises
Managing Risk on Agile Projects
Risk Management on Agile Projects
Agile Community
Professional Scrum with Kanban
Release Train Engineer
PI Objectives
Lean and Agile Principles and Practices
Scrum Primer
Lean Agile
Built-In Quality
ART Success
RTE Role
Legacy Enterprise
Accelerate Value Delivery At Scale
Scrum Master Role
Acceptance Test-Driven Development
Agile Israel Events
Test Driven Development
Agile Contracts Best Practices
Achieve Business Agility
Manage Budget Creation
Continuous Planning
Kaizen Workshop
What Is Kanban
Lean-Agile Budgeting
The Agile Coach
Agile Program
Agile Mindset
Agile Techniques
Lean Startup
Entrepreneurial Operating System®
Agile Project Management
Lean Agile Basics
A Kanban System for Software Engineering
Agile Marketing
Hybrid Work
Professional Scrum Product Owner
Reading List
Risk Management in Kanban
Effective Agile Retrospectives
Perfection Game
Story Slicing
Lean-Agile Software Development
Applying Agile Methodology
Agile Outsourcing
Nexus Integration Team
Agile Project
Agile Release Management
The Kanban Method
System Team
Advanced Roadmaps
System Integration Environments
SAFe Release Planning
Agile Development
Business Agility
Kanban 101
Large Scale Scrum
Managing Projects
Scrum and XP
Limiting Work in Progress
Agile Product Development
Daily Scrum
Systems Thinking
Software Development
Quality Assurance
Lean Agile Organization
Agile Risk Management
Engineering Practices
SAFe DevOps
Process Improvement
lean agile change management
System Archetypes
Professional Scrum Master
Legacy Code
Jira Plans
Continuous Improvement
Releases Using Lean
speed @ scale
Agile for Embedded Systems
Software Development Estimation
Agile Games
Risk-aware Product Development
Enterprise DevOps
Iterative Incremental Development
Sprint Iteration
Agile and DevOps Journey
IT Operations
Implementation of Lean and Agile
Continuous Delivery
speed at scale
Scrum With Kanban
Kanban Kickstart Example
Principles of Lean-Agile Leadership
Nexus and SAFe
Continuous Integration
Kanban Basics
Coaching Agile Teams
Change Management
Jira Cloud
Agile Release Planning
Introduction to Test Driven Development
Scaled Agile Framework
Product Ownership
Scrum Master
Implementing SAFe
Nexus and Kanban
Artificial Intelligence
Lean Agile Leadership
Agile Basics
Agile Delivery
Agile Assembly Architecture
Agile Testing Practices
Agile Games and Exercises
Agile Israel
ALM Tools
Program Increment
Agile India
Continuous Deployment
Product Management
Lean Software Development
An Appreciative Retrospective
Introduction to ATDD
Sprint Planning
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart