Kanban Forecasting with Service Level Expectations

Service Level Expectations (SLEs) are an instrumental addition to mature Kanban systems. They operationalize the flow, drawing on historical cycle times to forecast the probable delivery times, as well as to sequence work and highlight risks. So, while SLEs are not there to guarantee set outcomes, they work to expose the system’s factual capabilities, moving away from a reliance on contractual obligations. They are expectations, not promises, or agreements (SLAs). The very shift from deterministic statements to probability-based estimates grounds your relationship with the customer in evidence, not ambition.

Why does a mature Kanban system need SLEs?

The flow of work in Kanban is continuous, rarely partitioned out into set delivery intervals. This can make teams understandably nervous when facing a customer requesting an estimated end date for their project. A team that relies solely on work-in-progress observation may indeed be tempted to make commitments that contradict all empirical evidence hidden within the board’s cycle time distribution and throughput. Setting up SLEs counteracts this by creating a shared reference point for how long items typically take to traverse the system.

A Service Level Expectations value is expressed by a percentile (% probability of completion) within a threshold of the cycle time distribution (# of days) for a specific workflow (between the work initiation and completion columns).

This estimation is a statistical artifact of the workflow’s current performance, serving as a practical forecast boundary that draws from team capabilities and constraints, as well as task variability and dependencies.

Using cycle time distribution to make SLEs

Since the cycle time data is the base here, unclear or fluid definitions of when work begins and ends will undermine the entire model. The Kanban pipeline must accurately capture active work commitment and exit points.

From such a consistently formed dataset, a team can extract the cycle time distributions. Most knowledge-based delivery systems with high task variability reflect heavy-tailed distributions, with the most time consuming items skewing their averages. Switching to probability percentiles eliminates this issue. By selecting a percentile that aligns with the company’s risk tolerance - typically between the 70th and 95th percentiles - the SLE threshold can be set to balance predictability with observation.

SLEs, not SLAs

SLEs describe the likelihood of outcomes, sidestepping the rigidity of typical Service Level Agreements. SLA asserts a minimum standard of delivery for a team to uphold, or compensate for. SLEs are diagnostic, not prescriptive. If an item exceeds the forecast delivery window, it isn’t a breach of contract, but a signal that the circumstances for that item diverged from a historical completion pattern. While it may warrant investigation, it is not an issue demanding a fix.

This important distinction alters the tone of the team’s planning discussions. Instead of using pressure or arbitrary deadlines to force a commitment, a team analyzes where a proposed work item is likely to sit within the known cycle time distribution. That assessment then informs work sequencing and funding, managing stakeholder expectations, but does not set the delivery date in stone. The tone switches from obligation to probability.

SLEs for managing variation

Even the most precise Kanban system cannot eliminate all variability. Task inter-dependencies, batch work arrivals, availability of expert team members, and unplanned work all cause cycle time fluctuations. SLEs explicitly state this variability: the width of the SLE window shows exactly how turbulent the workflow currently is. A narrow SLE window (e.g., 90% of items complete in 3–5 days) marks stable execution and consistent throughput, while a wider SLE window (e.g., 90% of items complete in 3–12 days) suggests that some classes of work suffer significant delays and/or unpredictability.

To form better estimates for stakeholders, teams can take one step further and calculate SLEs for various task types. It’s quite common for small tasks (i.e., feature enhancements, minor bugs) to cluster around short cycle times, while large ones (i.e., compliance work, new product design) are more likely to show widely dispersed cycle times. This method of segmenting forecasts provides stakeholders with a clearer insight into the risks associated with different categories of work.

The SLE feedback loop

Since SLEs reflect existing system behavior, they evolve, with each delivery event becoming a new data point for the distribution. As workflow policies, staff, and external demand change, so does the cycle-time pattern. Mature teams regularly review their SLEs, adjusting them at points when changes will not disrupt workflow stability. Cyclical re-calibration ensures that SLEs continue to serve as trustworthy representations of current performance.

Such iterative review also aids continuous improvement. High deviations from an existing SLE value can signal systemic issues such as excessive multitasking, neglected upstream refinement, poorly articulated work items, or bottlenecks at particular workflow steps. Of course, the SLE doesn’t resolve these issues, but exposes them quite precisely for the team’s attention.

Presenting SLEs on the Kanban board

Teams often place SLE markers directly on their digital Kanban boards, enabling stakeholders to inform release planning, coordinate across teams, and even shape funding strategies using probabilistic insights. Such visible alignment of expectations with evidence also reduces unnecessary friction between delivery teams and stakeholders.

Another common practice is to show the age of each item, either as a bare time value or as a relation between that time and the SLE boundary. Doing this adds a time-oriented risk dimension to the board.
Tasks crossing the forecast boundary immediately draw attention, but the purpose is not so much escalation as anomaly detection, alerting the team to revisit prioritization guidelines and flow policies. This added visibility strengthens operational discipline and warns of fluctuations in the ongoing delivery cycle.

Integrating SLEs with other metrics

As SLEs operate alongside throughput, work-in-progress limits, arrival rates, and task aging metrics, it’s best to build an ecosystem in which these elements can reinforce one another. For instance, if an SLE proves significant unpredictability, throughput data can help identify whether arrival rates regularly exceed capacity. Tracking adherence to WIP limits can reveal if tasks are being started concurrently, eroding predictability.

Similarly, Little’s law can cross-check the validity of the presented SLE: if the average WIP task count and throughput value do not align with the average cycle time, then the used SLE may be resulting from local anomalies or inconsistent definitions of completion state. Performing a regular cross-metric check should reinforce system integrity and prevent misinterpretations.

Embedding SLEs in policy

As SLEs gain a stronger footing in the system, they often become integrated with the company’s operational policies. For instance, a policy might state that items approaching the SLE boundary get priority attention, or that work types historically exceeding forecast delivery rates demand extra refinement. These types of policies build mechanisms for guiding the workflow without imposing quotas or strict deadlines.

Managers can also use SLE data to spot performance trends, using SLEs in place of traditional performance assessments to examine distribution shifts, changes in completion predictability, or the results of improvement experiments on an SLE curve.

SLE adoption calls for culture adjustment

Adopting SLEs assumes a cultural shift toward transparency and a higher tolerance for uncertainty. Teams adapted to deterministic project plans are prone to resisting probability-based forecasts, because their old way of planning granted them an illusion of total control. However, at the heart of Kanban lies an emphasis on enabling flow through observation and adaptation, not removing uncertainty through artificial commitments.

After a team has internalized the new mindset, SLEs form a natural instrument for operational transparency, facilitating open dialogue about risk, variability, and constraints. That, in turn, allows for making more informed trade-offs and removes the tension typical in deadline-driven models.

Service Level Expectations provide Kanban teams with a data-based mechanism for analyzing and forecasting flow performance by capturing the statistical reality of cycle time distributions. Built entirely on real data, SLEs enhance the team’s credibility and provide an accurate understanding of the delivery rates the team can reliably achieve.