Riding the Velocity Wave: Practical Workflow Comparisons for Agile Teams

Why Workflow Comparisons Matter More Than You Think

Many teams adopt a framework like Scrum or Kanban without fully understanding the underlying assumptions about workflow. The result is often a cosmetic implementation that misses the point: a daily standup that feels like a status report, or a board that is updated only at the end of the sprint. The real value of comparing workflows is not about picking the "best" one—it is about understanding how each model shapes the flow of work, the pace of delivery, and the team's ability to adapt. This article provides a conceptual comparison of three common approaches—Scrum, Kanban, and a hybrid model—focusing on the mechanics of how work moves from start to finish.

We will examine the trade-offs between batch-and-release cycles versus continuous flow, the role of work-in-progress (WIP) limits, and how each method handles uncertainty and change. By the end, you should be able to articulate not only what your team does, but why you do it that way—and whether another approach might better suit your context. This understanding is crucial because workflow choices directly affect predictability, team morale, and stakeholder satisfaction. Teams that blindly follow a script often end up with ceremonies that feel meaningless and a process that fights against the natural rhythm of their work. Our goal is to help you break out of that pattern by providing a framework for thoughtful, intentional workflow design.

In the following sections, we will dive deep into each model, compare them across several dimensions, and then provide a step-by-step guide for conducting your own workflow review. We will also share anonymized scenarios from three different types of teams—a product team, a support team, and an infrastructure team—to illustrate how the same model can play out differently. Let's start by clarifying the core concepts that underpin all Agile workflows.

Core Concepts: The Mechanics of Flow and Cadence

Before comparing specific workflows, it helps to establish a common vocabulary. Two concepts are central to every Agile approach: flow and cadence. Flow refers to how work items move through the system—from the moment they are identified as needing attention to the moment they are delivered. Cadence is the rhythm of the team's activities: planning, review, and reflection. Different workflows optimize for different combinations of flow and cadence. For example, Scrum emphasizes a fixed cadence (sprints) with a batch flow (work is committed in batches and released at the end of the sprint). Kanban, in contrast, emphasizes a continuous flow with a variable cadence (releases happen whenever something is ready). Understanding these two dimensions helps you see why a model works well in some contexts and struggles in others.

Work in Progress (WIP) Limits and Their Role

A crucial mechanism in any workflow is the limit on work in progress. WIP limits cap the number of items that can be in a given state at any time. The purpose is to prevent overloading the team and to expose bottlenecks. In Kanban, WIP limits are explicit and strictly enforced at each column of the board. In Scrum, WIP limits are less explicit but are implicitly set by the sprint backlog size. Both approaches aim to keep the team focused and reduce context switching. However, the way they enforce limits leads to different behaviors. With explicit WIP limits, teams naturally pull new work only when capacity is available. With implicit limits, there is a temptation to add more work during the sprint, which can lead to multitasking and reduced throughput. Many teams find that introducing explicit WIP limits, even in a Scrum context, improves focus and delivery predictability.

Cycle Time vs. Throughput

Two metrics are often used to evaluate workflow effectiveness: cycle time and throughput. Cycle time is the time it takes for a single work item to move from start to finish. Throughput is the number of items delivered in a given period. These metrics are inversely related up to a point: reducing cycle time usually increases throughput, but only if the team does not become overloaded. Different workflows tend to optimize for one over the other. Kanban is designed to minimize cycle time by limiting WIP and enabling continuous delivery. Scrum, with its fixed sprint cycle, optimizes for throughput predictability—the team commits to a certain number of story points and aims to deliver all of them by the end of the sprint. Understanding which metric matters more for your stakeholders is a key factor in choosing a workflow.

Batch Size and Release Frequency

The size of a batch—how many items are grouped together for release—has a significant impact on risk and feedback. Smaller batches reduce the risk of a release failure because fewer changes are involved, and they also allow faster feedback from users. Larger batches increase efficiency in some contexts (e.g., lower overhead per release) but delay feedback and increase the potential impact of errors. Scrum typically uses larger batches (the sprint increment) released at the end of each sprint. Kanban encourages smaller batches, releasing items as soon as they are ready. The trade-off is between coordination overhead and responsiveness. Teams that need frequent user feedback often prefer Kanban's smaller batches, while teams that need to coordinate dependencies across multiple items may find Scrum's batching more manageable.

Planning Horizons and Commitment

Another key difference is how far ahead the team plans and what level of commitment they make. In Scrum, the team commits to delivering a specific set of items by the end of the sprint. This commitment creates a predictable target for stakeholders but can lead to stress if estimates are off. In Kanban, the team makes no such commitment; they simply pull work as capacity allows. This reduces stress but may make stakeholders anxious about when specific features will arrive. Some teams use a hybrid approach: they plan in iterations but make commitments only for a subset of high-priority items, using a buffer for uncertainty. The choice depends on the degree of uncertainty in the work and the stakeholders' tolerance for variability. Teams that work on highly unpredictable tasks, such as bug fixes or research, often find Kanban's lack of commitment liberating. Teams that work on well-understood features may appreciate the structure of sprint commitments.

These core concepts provide a lens for comparing workflows. In the next sections, we will apply this lens to Scrum, Kanban, and a hybrid model, using a consistent set of criteria: WIP management, batch size, release cadence, planning cycle, and team structure. We will also highlight common pitfalls and how to avoid them.

Scrum: Structure, Cadence, and the Sprint Rhythm

Scrum is the most widely adopted Agile framework, and for good reason. Its fixed-length sprints (typically one to four weeks) provide a predictable cadence for planning, review, and retrospection. The roles—Product Owner, Scrum Master, and Development Team—are clearly defined, and the ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) create a rhythm that helps teams stay aligned. However, the structure that makes Scrum successful can also become a straitjacket if applied rigidly. In this section, we examine how Scrum handles flow and cadence, and where its strengths and weaknesses lie.

How Scrum Manages Work in Progress

In Scrum, WIP is managed implicitly through the sprint backlog. The team selects a set of items from the product backlog during Sprint Planning, and they commit to completing all of them by the end of the sprint. During the sprint, the team should not take on new work, but in practice, new items often creep in due to stakeholder pressure or discovery of high-priority issues. This implicit WIP limit can be problematic because there is no explicit constraint on how many items are in progress at any given time within the sprint. Teams may start multiple items and finish none, leading to a pile-up of nearly done work. To counter this, many Scrum teams adopt an explicit WIP limit within their process, even though it is not part of the official framework. For example, they may limit the number of items in the "In Progress" column on their board to three or four. This hybrid approach can improve flow without abandoning the sprint structure.

Batch Size and Release Cadence in Scrum

Scrum's default model is a batch release at the end of each sprint. The team integrates all completed items into a potentially releasable increment. This batching has advantages: it reduces the overhead of frequent releases and allows the team to coordinate dependencies across items. However, it also means that stakeholders must wait until the end of the sprint to see value, and feedback is delayed. For teams working on products that require rapid iteration, this delay can be a problem. Some Scrum teams mitigate this by doing continuous deployment within the sprint, releasing items as they are ready. This is essentially a hybrid approach—Scrum's planning and review ceremonies combined with Kanban's continuous release. The decision to release within the sprint or at the end depends on the technical infrastructure and the business need for speed.

Common Pitfalls in Scrum Implementations

One of the most common pitfalls is treating the sprint as a deadline rather than a timebox. When teams feel pressure to deliver, they may cut corners on quality or skip the retrospective. Another pitfall is having too many items in the sprint backlog, which leads to overcommitment and stress. A good rule of thumb is to plan for about 60-70% of the team's capacity, leaving buffer for unexpected work. A third pitfall is the "Scrum-but" syndrome: teams follow the ceremonies but ignore the principles, such as self-organization or cross-functionality. For example, a team might have a Sprint Review but only show progress, not solicit real feedback. To avoid these pitfalls, teams should regularly inspect and adapt their process, using the retrospective as a true opportunity for change. It is also helpful to have an experienced Scrum Master who can guide the team through the early stages and help them internalize the values behind the practices.

Overall, Scrum works well for teams that have a clear, prioritized backlog and a relatively stable set of requirements over the sprint duration. It is less suitable for teams that face high unpredictability or frequent interruptions, such as support teams or operations teams. In the next section, we look at Kanban, which was designed specifically for those contexts.

Kanban: Continuous Flow and Pull-Based Work

Kanban originated in manufacturing and was adapted for knowledge work by David J. Anderson in the mid-2000s. Its core principles are: visualize the workflow, limit WIP, manage flow, make process policies explicit, and improve collaboratively. Unlike Scrum, Kanban does not prescribe roles, ceremonies, or fixed iterations. Instead, it provides a set of practices that help teams regulate the flow of work. This makes Kanban especially suitable for teams that handle a continuous stream of incoming tasks, such as IT support, maintenance, or DevOps. In this section, we explore how Kanban's pull system works, how it manages WIP, and where it may fall short.

The Pull System and WIP Limits

In a Kanban system, work is pulled into each state only when there is capacity. For example, if the "In Progress" column has a WIP limit of three, a new item cannot be started until one of the current items moves to the next column. This prevents the team from being overloaded and ensures that work flows smoothly through the system. The WIP limits are typically set based on the team's historical throughput and are adjusted as needed. The pull system reduces context switching because team members focus on finishing items before starting new ones. It also makes bottlenecks visible: if items stack up before a certain column, that column is the constraint. The team can then decide whether to add more capacity to that step, improve the process, or reduce the inflow. This empirical approach to improvement is a key strength of Kanban.

Cadence and Release Frequency in Kanban

Kanban does not have a fixed release cadence. Instead, releases happen whenever a batch of items is ready, which could be multiple times a day or once a week. This is ideal for digital products that can be deployed continuously. The team can also use a "service level expectation" (SLE) to communicate to stakeholders how quickly different types of items are likely to be delivered. For example, the team might say that 80% of standard items are delivered within three days. This provides predictability without a fixed commitment. The lack of a sprint review means that feedback is gathered from real usage rather than a meeting. However, teams that are used to the rhythm of Scrum may feel lost without the regular checkpoint. To address this, some Kanban teams hold a weekly "operations review" to discuss flow metrics and process improvements, similar to a retrospective.

When Kanban Might Not Be the Best Fit

Kanban's flexibility can be a disadvantage for teams that need structure or are new to Agile. Without the guardrails of sprints and ceremonies, teams may struggle to establish a regular cadence for planning and reflection. The lack of a sprint goal can also make it harder for stakeholders to see progress, because work is delivered continuously rather than in visible chunks. Additionally, Kanban requires a mature understanding of flow metrics to be effective. Teams need to track cycle time, throughput, and WIP, and use that data to drive improvements. If a team is not ready to engage with metrics, Kanban can degenerate into a simple to-do list. For these reasons, many coaches recommend starting with Scrum and transitioning to Kanban later, as the team's understanding of flow deepens. Another option is to use a hybrid that borrows the best of both, which we explore next.

Kanban is powerful for teams that face high variability in their workload, such as incident response teams, customer support, or R&D groups. Its emphasis on flow and limiting WIP can dramatically reduce cycle time and improve predictability. However, teams must invest in measuring and analyzing their flow to realize the benefits.

Hybrid Approaches: Blending Scrum and Kanban Elements

Many teams do not fit neatly into either Scrum or Kanban. They may need the planning structure of sprints but also the flexibility of continuous delivery. This has led to the rise of hybrid approaches, often called "Scrumban" or simply a customized workflow. A hybrid model allows teams to cherry-pick practices from both frameworks to suit their specific context. In this section, we describe a common hybrid pattern: using a sprint cycle for planning and review, but within the sprint, using a Kanban-like pull system with explicit WIP limits. This approach can provide the best of both worlds, but it also introduces complexity and requires careful design.

Designing a Hybrid Workflow: Key Decisions

To design a hybrid workflow, a team must decide which elements of each framework to keep. Typically, the team retains Sprint Planning and Sprint Review from Scrum, but replaces the Daily Scrum with a Kanban-style standup focused on flow (what did you complete, what are you working on, are there any blockers). The team also adopts explicit WIP limits for each column of their board, and they use a continuous delivery model rather than a batch release at the end of the sprint. The sprint backlog becomes a commitment to a set of items, but the team can adjust the scope mid-sprint if new priorities emerge, using a process like "swimlanes" to separate committed items from opportunistic ones. The key is to be explicit about the policies: when can an item be added to the sprint? What happens if WIP limits are exceeded? How is the sprint goal used? Without clear policies, the hybrid can become a messy mix of practices that satisfy no one.

A Common Hybrid Pattern: The "Sprint-Within-Flow" Model

One popular hybrid pattern is the "sprint-within-flow" model. The team works in two-week sprints, but within the sprint, they operate like a Kanban team. They have a board with columns: Backlog, Ready, In Progress, Review, Done. Each column has a strict WIP limit. At Sprint Planning, they pull items from the product backlog into the sprint backlog, but they do not commit to all of them; instead, they commit to a daily rate of delivery based on historical data. The sprint goal is a broader objective, not a fixed list of features. Throughout the sprint, the team pulls work based on priority and capacity. At the Sprint Review, they demonstrate what was actually delivered, which may be different from what was planned. This model gives the team the predictability of a regular planning cycle while maintaining the flexibility to respond to emerging issues. It works well for teams that have a mix of planned and unplanned work, such as product teams that also handle support tickets.

Potential Drawbacks of Hybrid Models

The main risk of a hybrid is that the team ends up with the overhead of Scrum ceremonies plus the complexity of Kanban metrics, without fully benefiting from either. The sprint planning meeting may feel less urgent if the team knows they can change scope mid-sprint. The review may be confusing if stakeholders expect a fixed set of deliverables. Another risk is that the team may ignore the WIP limits during the sprint, treating them as suggestions rather than constraints. To mitigate these risks, the team should start with a simple hybrid and gradually refine it based on data. It is also helpful to have a coach or experienced practitioner guide the transition. Some teams find that they eventually move toward pure Kanban as they become more comfortable with flow-based management, while others find that they need the structure of Scrum and revert to a more traditional approach. Hybrids are best seen as a stepping stone or a custom fit, not a permanent destination.

In the next section, we compare these three options side by side using a structured table, which will help you see the trade-offs at a glance.

Side-by-Side Comparison: Scrum, Kanban, and Hybrid

To make the differences concrete, we have built a comparison table that evaluates each workflow across several dimensions: WIP management, batch size, release cadence, planning cycle, team structure, and suitability for different types of work. Use this table as a reference when evaluating which workflow might be a good starting point for your team, and which aspects you might want to customize.

Comparison Table

How to Use This Table

When considering a workflow change, start by identifying which dimension is most critical for your team's success. For example, if stakeholder predictability is your top priority, Scrum's fixed commitment may be best. If reducing cycle time is paramount, Kanban's WIP limits and continuous flow may be more effective. The hybrid approach is often a safe middle ground, but requires discipline to avoid becoming a cluttered process. Use the table as a discussion tool with your team: mark where you think your current workflow falls on each dimension, and where you would like it to be. The gaps will highlight what needs to change.

In the next section, we will walk through a step-by-step guide for conducting a workflow review, which can help your team make an informed decision.

Step-by-Step Guide: Running a Workflow Review and Selection

Choosing a workflow is not a one-time decision. Teams should periodically review their process to ensure it still serves their needs. This step-by-step guide provides a structured approach to conducting a workflow review, from gathering data to making a recommendation. The process is designed to be collaborative and data-informed, not top-down. It typically takes two to four weeks, depending on the team's size and willingness to change.

Step 1: Gather Data on Your Current Workflow

Before deciding on a new workflow, you need to understand how work currently flows. Collect data for at least four weeks: track cycle time, throughput, WIP levels, and the frequency of interruptions. Also gather qualitative feedback from the team: what frustrates them about the current process? What do they think is working well? Use a simple board or spreadsheet to record the start and end dates for each item, as well as any blockers. This data will serve as a baseline for evaluating the impact of any changes. Without baseline data, it is impossible to know if a new workflow is actually an improvement.