Comparing Kanban vs Scrum to Find Your Team's Best Workflow
This skill teaches you how to systematically evaluate kanban vs scrum across concrete dimensions of your team's work, then make a defensible choice, blend, or migration plan rather than picking a method based on trend or habit.
Score your team's context across six dimensions: work predictability, requirement stability, planning cadence preference, team structure, delivery frequency needs, and organizational culture. Teams with highly variable incoming work, continuous delivery needs, and service-oriented functions lean Kanban. Teams with stable requirements, dedicated members, and clear sprint goals lean Scrum. Many teams blend both, using Scrum's sprint structure with Kanban's WIP limits and flow metrics.
Outcome: You produce a scored comparison worksheet that maps your team's real constraints to each method's strengths, yielding a clear recommendation (pure Kanban, pure Scrum, or a specific hybrid configuration) with an implementation sketch your team can act on immediately.
Prerequisites
- Basic understanding of Kanban boards and continuous flow (see /methods/kanban)
- Familiarity with Scrum ceremonies (sprint planning, standups, retrospectives, reviews)
- Access to your team's recent work history (last 30-90 days of tickets or tasks)
- Knowledge of your team's current delivery cadence and stakeholder expectations
Overview
Most teams approach the kanban vs scrum question as if it were a personality test. They read a blog post, see a feature comparison table, and pick whichever method sounds more appealing. The result is a method that fights the team's actual work patterns instead of amplifying them. This skill replaces gut-feel selection with a structured, evidence-based comparison grounded in the six dimensions that actually determine which method fits: work predictability, requirement stability, planning cadence, team structure, delivery frequency, and organizational culture.
The comparison process sits naturally within the Kanban method because Kanban's core philosophy is to start with what you do now and evolve. Even if you conclude that Scrum is the better fit, the act of mapping your workflow to both methods teaches you about your own constraints. And if you land on a hybrid, Kanban's principles of visualizing work, limiting WIP, and managing flow become the connective tissue that holds the blend together. The skill connects directly to siblings like setting WIP limits and measuring flow metrics, because those practices often become the deciding factors in the comparison.
The concrete artifact you produce is a comparison worksheet: a six-dimension scoring grid with your team's real data filled in, a recommendation with rationale, and an implementation sketch that names specific ceremonies, cadences, and board structures to adopt. This is not a theoretical exercise. A team lead should be able to present the worksheet to their manager and say, "Here is why we're switching to X, here is what changes in week one, and here is how we'll measure whether it's working."
Success looks like a team that operates within a method chosen for structural reasons rather than fashion, with clear answers to the inevitable "why don't we just use Scrum/Kanban instead?" questions that surface in retrospectives and stakeholder meetings.
How It Works
The comparison works because Kanban and Scrum are not competing philosophies. They are different answers to the same underlying question: how should a team coordinate to deliver valuable work predictably? They differ in the constraints they impose and the freedoms they preserve. Scrum constrains time (fixed sprints) and scope (committed sprint backlog) while preserving freedom in process within the sprint. Kanban constrains throughput (WIP limits) and flow (pull policies) while preserving freedom in timing and scope changes. Choosing between them is really choosing which set of constraints will help your team more.
The six-dimension model works because each dimension isolates a specific variable where the two methods diverge. Work predictability measures how much your incoming work varies in size and arrival rate. Requirement stability measures how often priorities shift mid-cycle. Planning cadence captures whether your stakeholders expect regular planning ceremonies or continuous reprioritization. Team structure examines whether members are dedicated or shared across teams. Delivery frequency tests whether you need to ship continuously or in batches. Organizational culture checks whether your company values fixed commitments or adaptive response. None of these dimensions alone determines the answer, but scoring all six reveals a pattern.
The scoring uses a simple 1-3 scale per dimension, where 1 favors Kanban and 3 favors Scrum. A total of 6-10 points leans Kanban, 11-13 is hybrid territory, and 14-18 leans Scrum. This is deliberately coarse. The point is not mathematical precision but forcing explicit discussion about each dimension. Teams that skip this step and "just try Scrum" often discover three months later that their work is too unpredictable for sprint commitments, a conclusion they could have reached in an afternoon with the worksheet.
The hybrid zone is where most modern product teams actually land. The most common blend uses Scrum's sprint cadence for planning and retrospectives while adopting Kanban's WIP limits and cumulative flow diagrams to manage daily work. This configuration, sometimes called Scrumban, preserves the rhythm and commitment structure that stakeholders appreciate while adding the flow visibility that helps the team spot bottlenecks early. The Kanban method explicitly supports this kind of layering because it was designed to overlay onto existing processes rather than replace them.
The model deliberately excludes team preference as a scoring dimension. Preference matters for adoption, but it is a separate concern. A team that prefers Scrum but works in an environment with constant priority changes will fail at sprint commitments regardless of enthusiasm. The worksheet separates structural fit from adoption strategy so you can address each honestly.
Step-by-Step
Step 1: Gather Your Team's Work History
Pull the last 60-90 days of completed work items from your project tracker (Jira, Linear, Trello, a spreadsheet, whatever you use). You need three pieces of information per item: the date it entered your queue, the date it was completed, and whether it was planned in advance or arrived as an interrupt. If you track item size (story points, t-shirt sizes, hours), include that too. Export this into a spreadsheet or document you can reference throughout the comparison.
Count the total number of items, the number that were interrupts versus planned, and the average time from arrival to completion. This raw data fuels the scoring in steps 3-5.
Tip: If you do not have 60 days of clean data, use 30 days and note the smaller sample size. Even a rough count of planned versus unplanned work over two weeks is better than guessing.
Step 2: Interview Stakeholders on Expectations
Spend 15-20 minutes with each of the 2-3 people who most frequently request work from your team. Ask three specific questions: How far in advance do you typically know what you need from this team? How often do priorities change after you've submitted a request? Would you prefer a regular planning meeting where you commit priorities for a period, or a continuous queue where you can reprioritize any time?
Write down their answers verbatim. You are not looking for method preferences. You are looking for the planning reality your team operates in. If stakeholders say "I need to be able to change priorities daily," that is a strong signal for Kanban.
If they say "I plan my needs a month ahead and just want reliable delivery dates," that leans Scrum.
Tip: Ask stakeholders about their behavior, not their preference. "How often did you change priorities last month?" is more useful than "Would you like to be able to change priorities?"
Step 3: Score Work Predictability (Dimension 1 and 2)
Open your comparison worksheet (a simple table with six rows, one per dimension, and columns for score, evidence, and notes). For Work Predictability, look at the ratio of unplanned to planned items in your work history. If more than 50% of items were interrupts or unplanned, score 1 (favors Kanban). If 20-50% were unplanned, score 2 (neutral).
If fewer than 20% were unplanned, score 3 (favors Scrum). For Requirement Stability, review how often completed items had their scope or priority changed after being started. If requirements shifted on more than 40% of items, score 1. If 15-40%, score 2.
Under 15%, score 3. Write the actual percentages in the evidence column so your rationale is transparent.
Tip: Count scope changes that happened after work started, not before. Pre-start reprioritization is normal backlog grooming. Mid-work scope change is the signal that sprint commitments would be at risk.
Step 4: Score Planning and Structure Dimensions (Dimension 3 and 4)
For Planning Cadence, use the stakeholder interview data. If stakeholders overwhelmingly want continuous reprioritization and resist fixed planning windows, score 1. If they are comfortable with regular planning meetings but want some flexibility, score 2. If they prefer committed plans with clear delivery dates, score 3.
For Team Structure, assess your team's allocation. If most team members are shared across multiple teams or projects and their availability fluctuates week to week, score 1 (Kanban handles variable capacity better). If there is a stable core with some shared members, score 2. If the team is fully dedicated with consistent membership sprint to sprint, score 3.
Tip: Shared team members are the single most common reason sprint commitments fail. If even two of your five engineers are regularly pulled into other work, that instability makes sprint velocity meaningless.
Step 5: Score Delivery and Culture Dimensions (Dimension 5 and 6)
For Delivery Frequency, examine how often your team ships to users or hands off completed work. If you deploy continuously or multiple times per day and batching would slow you down, score 1. If you ship weekly or biweekly and batching is acceptable, score 2. If you release in scheduled batches (monthly, quarterly) and coordinated releases are the norm, score 3.
For Organizational Culture, assess how your broader organization operates. If the company values adaptive response, tolerates uncertainty, and does not require teams to commit to fixed sprint goals, score 1. If there is a mix, score 2. If leadership expects sprint commitments, velocity tracking, and predictable delivery dates, score 3.
This last dimension matters more than people admit. A team running pure Kanban inside a Scrum-oriented organization will spend enormous energy translating their metrics for leadership.
Tip: Be honest about organizational culture even if you disagree with it. You can advocate for change, but your initial method choice should account for the reality you operate in today.
Step 6: Total Your Score and Identify the Zone
Sum the six dimension scores. The minimum is 6, the maximum is 18. A total of 6-10 indicates a strong lean toward Kanban: your work is unpredictable, requirements shift, the team is shared, and you deliver continuously. A total of 14-18 indicates a strong lean toward Scrum: your work is plannable, requirements are stable, the team is dedicated, and stakeholders want committed delivery dates.
A total of 11-13 places you in the hybrid zone, where elements of both methods would serve you. Note which specific dimensions scored highest and lowest. A team with a total of 12 but a culture score of 3 (strongly Scrum-oriented org) has a different hybrid configuration than a team at 12 with a culture score of 1.
Tip: Do not agonize over borderline scores. If your total is 10 or 11, you are in hybrid territory regardless of which side of the line you fall on. The individual dimension scores matter more than the total.
Step 7: Design Your Specific Configuration
Based on your zone and dimension scores, write out the specific practices you will adopt. If pure Kanban: define your board columns (see designing Kanban boards), set initial WIP limits (see setting WIP limits), and establish your cadences (see running Kanban cadences). If pure Scrum: define your sprint length, ceremonies, and roles. If hybrid: name the specific elements you are taking from each.
A common hybrid takes sprint planning and retrospectives from Scrum (providing rhythm and reflection) while using Kanban's WIP limits, cumulative flow diagrams, and pull-based work assignment within the sprint (providing flow visibility and reducing overcommitment). Write this as a one-page configuration document: ceremonies with frequency, board structure, metrics to track, and roles.
Tip: For hybrids, start with the Scrum skeleton (sprints, planning, retro) and add Kanban elements (WIP limits, flow metrics) rather than the reverse. It is easier to relax sprint constraints later than to add them to a pure flow system.
Step 8: Define Your Evaluation Criteria
Before you implement, write down three to four specific metrics you will use to judge whether the chosen method is working. Good metrics include: cycle time (how long items take from start to finish), throughput (how many items completed per week), sprint goal completion rate (for Scrum or hybrid), and stakeholder satisfaction (a simple 1-5 rating collected monthly). Set a baseline from your work history data and define what "better" looks like. For example: "Our current average cycle time is 8 days.
" Set a review date, typically 6-8 weeks after implementation, when you will compare actuals to baseline and decide whether to continue, adjust, or switch.
Tip: Track cycle time regardless of which method you choose. It is the universal signal of workflow health, and it is the one metric that both Kanban and Scrum teams can compare apples-to-apples.
Step 9: Present the Recommendation and Get Buy-In
Assemble your worksheet, configuration document, and evaluation criteria into a single brief (one to two pages). Present it to your team and your manager or stakeholders. Walk through the six dimensions, show the scores with evidence, explain the recommendation, and describe what will change in the first week. Address the most common objection preemptively: "We chose this based on our actual work patterns, not a preference.
" Ask for a committed trial period (6-8 weeks) with a clear review checkpoint. This framing reduces resistance because it positions the choice as an experiment with defined success criteria rather than a permanent commitment.
Tip: If your team has strong existing opinions about Kanban vs Scrum, share the blank worksheet first and have each person score independently before revealing results. This prevents anchoring and surfaces genuine disagreements about how the team actually works.
Examples
Example: SaaS Product Team Moving from Ad-Hoc to Structured
A 6-person product team at a B2B SaaS startup has been working without a formal method. They ship features when ready, handle bugs as they come, and hold weekly syncs. The CTO wants to introduce a process but the team is divided between Scrum advocates and those who want to keep things flexible. Work history shows 30% unplanned items. Requirements change on about 25% of items after start. Stakeholders plan 2-3 weeks ahead. The team is fully dedicated. They deploy daily. The broader company has no strong method culture.
The team scored: Work Predictability 2 (30% unplanned is moderate), Requirement Stability 2 (25% changes, right in the middle), Planning Cadence 2 (stakeholders plan ahead but not rigidly), Team Structure 3 (fully dedicated), Delivery Frequency 1 (continuous deployment), Culture 2 (no strong organizational norm). Total: 12, squarely in hybrid territory. The team adopted two-week sprints for planning and retrospectives, giving stakeholders the predictable rhythm they wanted. Within sprints, they used a Kanban board with WIP limits of 2 items per engineer in progress, eliminating the context-switching that had been slowing them down.
They tracked both sprint goal completion and cycle time. After 8 weeks, cycle time dropped from 6 days to 4 days, and sprint goals were met 80% of the time. The daily deployment cadence was preserved because sprint goals were not tied to a release train.
Example: IT Operations Team Handling Tickets and Projects
A 4-person IT ops team at a mid-size company handles a mix of infrastructure projects and incoming support tickets. Roughly 60% of their work is unplanned tickets. Project requirements rarely change once started but ticket priorities shift constantly. Stakeholders (other department heads) submit tickets ad hoc and want quick turnaround. Team members are shared: two are pulled into security reviews monthly. They do not have formal releases. The company runs Scrum across engineering, and leadership asks for sprint reports from all teams.
Scores: Work Predictability 1 (60% unplanned), Requirement Stability 2 (projects stable, tickets shift), Planning Cadence 1 (stakeholders want continuous queue), Team Structure 1 (shared members), Delivery Frequency 1 (no batch releases), Culture 3 (company expects Scrum reports). Total: 9, strong Kanban lean, but the culture score of 3 creates tension. The team adopted Kanban with a twist: they used a two-week reporting cadence that mirrored the engineering sprints, producing a summary of throughput and cycle time every two weeks in a format leadership could compare alongside sprint reports. Their board had three swim lanes, one for tickets, one for projects, and one for security reviews, each with its own WIP limit.
They set a WIP limit of 3 tickets and 1 project in progress at any time. 8 days because the WIP limit stopped engineers from juggling five tickets at once. Leadership accepted the Kanban reporting format because it delivered the same predictability signal as sprint velocity.
Example: Large Enterprise Team Migrating from Scrum to Kanban
A 12-person platform engineering team at a Fortune 500 company has been running Scrum for two years. " Work history shows 55% of sprint items are unplanned production incidents. The team is dedicated. They deploy via a weekly release train. The organization has a PMO that tracks all teams via Jira sprint boards.
Scores: Work Predictability 1 (55% unplanned), Requirement Stability 1 (production incidents change everything), Planning Cadence 2 (stakeholders accept planning but want interrupt flexibility), Team Structure 3 (fully dedicated), Delivery Frequency 2 (weekly release train), Culture 3 (PMO expects sprint data). Total: 12, but the pattern is revealing. Three dimensions scored 1 while two scored 3, indicating a team whose work screams Kanban but whose organization screams Scrum. The team proposed a phased migration: Phase 1 (weeks 1-4), keep two-week sprints but add WIP limits and separate the board into planned work and interrupt lanes, tracking each independently.
Phase 2 (weeks 5-8), replace sprint commitments with flow-based forecasting using cycle time data, while maintaining the two-week review cadence the PMO expected. Phase 3 (weeks 9-12), drop sprint planning in favor of continuous backlog refinement, using throughput data to provide delivery forecasts. They presented the PMO with a mapping document showing how Kanban metrics (throughput, cycle time, CFD) answered the same questions the PMO had been asking via velocity charts. The PMO agreed to the trial.
After 12 weeks, sprint goal failures were no longer a topic because there were no sprint goals to miss. 1 days, giving the PMO more reliable forecasting than erratic velocity had ever provided.
Example: Agency Creative Team Choosing a Method for Client Work
A 5-person design agency team handles 3-4 client projects simultaneously. Each project has defined scope and deadlines, but clients frequently request revisions and new directions mid-project. The team lead wants to introduce structure without adding overhead. Two designers are junior and new to any formal method. There are no deployments per se, but deliverables go out at project milestones. The agency has no method culture.
Scores: Work Predictability 2 (projects are planned but client revisions are frequent), Requirement Stability 1 (clients change direction regularly), Planning Cadence 2 (milestone-based, moderately predictable), Team Structure 2 (mostly dedicated but occasionally pulled for pitches), Delivery Frequency 2 (milestone-based delivery), Culture 1 (no organizational method norms). Total: 10, leaning Kanban. The team set up a single Kanban board with swim lanes per client project and a WIP limit of 2 active design tasks per person. They held a 15-minute daily standup (borrowed from Scrum) and a weekly board review where they reprioritized across clients.
No sprint planning was needed because client priorities shifted too frequently for two-week commitments to hold. They tracked cycle time per deliverable type (logo concepts: 2 days, landing page mockups: 4 days) and used these benchmarks to give clients realistic timelines. The junior designers appreciated the visual board because it made the team's capacity tangible. After 6 weeks, the team lead reported that client satisfaction scores improved because delivery estimates, based on actual cycle time data rather than gut feel, were met 90% of the time.
Best Practices
Score each dimension independently with evidence before discussing as a group. When teams discuss dimensions together from the start, the most vocal person anchors the conversation, and scores converge around opinion rather than data. Independent scoring followed by discussion surfaces genuine disagreements about how the team actually works, which is often the most valuable part of the exercise.
Use real work data, not aspirational descriptions of how you wish the team worked. A team that describes itself as "highly plannable" but has 45% unplanned work in its ticket history is fooling itself. The worksheet only works when the evidence column contains numbers from your actual tracker, not estimates from memory.
Weight organizational culture more heavily than your worksheet score suggests if you are new to the organization. A team that picks pure Kanban in a company where every other team runs Scrum will spend half its energy on translation and justification. Start with the organizational default and modify it based on your dimension scores rather than swimming against the current from day one.
Re-run the comparison every 6 months or whenever your team composition, stakeholder mix, or product stage changes significantly. A team that was rightfully Kanban during a support-heavy phase may shift toward Scrum when it moves into a planned feature-building phase. The method should follow the work, not the other way around.
Document your hybrid configuration precisely instead of saying "we do Scrumban." Scrumban means different things to every team that uses the word. Write down exactly which ceremonies you hold, at what cadence, what WIP limits apply, and which metrics you track. This prevents the configuration from drifting as team members change.
Treat the comparison as a team exercise, not a manager decision. The people doing the work have the most accurate picture of how predictable their incoming work is, how often requirements change, and whether sprint commitments feel realistic. A manager who imposes Scrum on a team whose work is fundamentally unpredictable will get compliance without results.
Keep the evaluation period short enough to be meaningful but long enough to show patterns. Six weeks is the minimum for a method change to stabilize. Anything shorter captures only the disruption of transition. Anything longer risks sunk-cost attachment to a method that is not working.
Separate the method decision from the tool decision. Pick the method first based on your dimension scores, then choose tooling that supports it (see choosing Kanban tools). Teams that start with a tool and adopt whatever method the tool defaults to are letting vendor UX design their workflow.
Common Mistakes
Choosing based on what the team has heard about rather than what the work requires
Correction
This happens because Scrum has vastly more training, certification, and published material than Kanban, so teams default to it out of familiarity. The signal to watch for is a team that cannot articulate why Scrum fits better than Kanban beyond "it's what we know" or "it's what our last company used." Fix this by requiring evidence-backed scores on all six dimensions before the team discusses preferences. If the scores point to Kanban but the team prefers Scrum, have an explicit conversation about the gap and its implications rather than ignoring the data.
Treating the comparison as binary when a hybrid is the best fit
Correction
Teams in the 11-13 score range often force themselves into one camp because "you have to pick one." You do not. The signal is a team that adopts pure Scrum but immediately starts breaking sprint commitments because 35% of their work is unplanned, or a team that adopts pure Kanban but struggles to coordinate with stakeholders who want regular planning checkpoints. The fix is to name the specific elements you are taking from each method, write them down, and treat the hybrid as a first-class configuration rather than a failure to commit.
Ignoring organizational culture and running a method that does not fit the surrounding environment
Correction
This typically happens when a team lead reads about Kanban's benefits and implements it in a company where every status report asks about sprint velocity and story points committed. The signal is spending more time explaining your process to leadership than improving it. The fix is to score the culture dimension honestly, weight it in your decision, and when you do pick a method that differs from the organizational norm, explicitly plan how you will translate your metrics into language the organization understands.
Skipping the evaluation criteria and never revisiting the decision
Correction
Without predefined success metrics and a review date, the chosen method becomes permanent by default. The signal is a team that has been running the same process for over a year but cannot point to any data showing it works well. Teams stop comparing because the switching cost feels high. The fix is to define your three to four evaluation metrics before implementation, set a review date on the calendar, and actually hold the review.
If cycle time has not improved and stakeholder satisfaction has not increased after 8 weeks, reopen the worksheet.
Letting one loud voice override the dimensional scoring
Correction
In many teams, a senior engineer or product manager has a strong opinion about which method is "right." Their confidence causes the group to adjust dimension scores to match the predetermined conclusion. The signal is suspiciously uniform scores with thin evidence. The fix is independent scoring: each team member fills out the worksheet alone, then you compare results. Disagreements on specific dimensions, like one person scoring work predictability at 1 and another at 3, surface real information about how different roles experience the same workflow.
Comparing methods in the abstract instead of against your team's specific constraints
Correction
Generic comparison articles list pros and cons that apply to idealized versions of each method. Your team is not idealized. " without connecting to your actual work data. The fix is to anchor every dimension score in your team's numbers: your interrupt rate, your stakeholder interview answers, your deployment frequency.
The worksheet forces this, but only if you fill in the evidence column honestly.
Other Skills in This Method
Managing Projects with Kanban
How to apply Kanban principles to plan, execute, and deliver projects using pull-based scheduling and continuous delivery instead of fixed sprints.
Running Kanban Cadences and Feedback Loops
How to facilitate the seven Kanban cadences — including standups, replenishment meetings, delivery planning, and service delivery reviews — to enable continuous improvement.
Setting and Enforcing Work-in-Progress Limits
How to determine optimal WIP limits for each workflow stage to reduce bottlenecks, improve flow, and prevent team overload.
Designing Effective Kanban Boards
How to structure columns, swimlanes, and card layouts on a Kanban board to accurately visualize your team's workflow from intake to completion.
Measuring Kanban Flow Metrics
How to track and interpret lead time, cycle time, throughput, and cumulative flow diagrams to continuously improve delivery performance.
Creating Explicit Pull Policies and Workflow Rules
How to define clear entry and exit criteria for each Kanban column so the team knows exactly when and how to pull work forward through the system.
Choosing the Right Kanban Tools and Software
How to evaluate and select digital Kanban tools like Trello, Jira, and Asana based on team size, workflow complexity, and integration needs.
Related Skills from Other Methods
Frequently Asked Questions
How do I compare kanban vs scrum if my team has never used either method?
Focus on the six dimensions rather than method-specific experience. Score your work predictability, requirement stability, and the other four dimensions using your current work history, even if that history is informal. A team with no method experience and a score of 8 should start with Kanban because its lower ceremony overhead makes adoption easier for teams new to structured methods. A team scoring 16 should start with Scrum because the sprint structure provides more guidance for teams that need scaffolding.
How long should the kanban vs scrum comparison process take?
The data gathering (work history export and stakeholder interviews) takes 2-3 hours spread across a day. The scoring workshop with the team takes 45-60 minutes. Designing the specific configuration takes another 30-60 minutes. Total elapsed time is typically one day if you schedule the stakeholder interviews in advance. Do not stretch this into a multi-week analysis. The worksheet is intentionally simple because the decision should be made quickly and then validated through the 6-8 week trial period.
Should I compare kanban vs scrum before or after setting up a board?
Before. Your board structure, WIP limits, and column design all depend on which method (or hybrid) you choose. A Scrum board has a sprint backlog column and uses sprint boundaries. A Kanban board has explicit WIP limits per column and no sprint boundaries. A hybrid board combines elements of both. If you design a board first, you will likely need to redesign it after the comparison. Do the comparison, write the configuration document, then design your board using the guidance in [designing Kanban boards](/skills/designing-kanban-boards).
Why does my kanban vs scrum recommendation keep changing every time we revisit it?
This usually means your team's work mix is genuinely shifting, which is common in fast-growing companies. If your scores swing by more than 3 points between assessments, look at which specific dimensions changed and why. A team that moved from product-building to production support will see work predictability and requirement stability scores drop, naturally shifting the recommendation toward Kanban. This is the method following the work, which is correct behavior. If scores fluctuate without an obvious cause, your evidence quality may be weak. Tighten the data sources you use for scoring.
Can I use Kanban flow metrics even if I choose Scrum?
Yes, and you should. Cycle time, throughput, and cumulative flow diagrams provide information that sprint velocity does not. Velocity tells you how much you completed in a sprint. Cycle time tells you how long individual items took. A Scrum team with consistent velocity but wildly variable cycle times has a hidden bottleneck. Adding Kanban flow metrics to a Scrum implementation is one of the most common hybrid configurations and is a natural stepping stone if you later decide to migrate more fully toward Kanban. See [measuring flow metrics](/skills/measuring-kanban-flow-metrics) for implementation details.
How do I handle a team where half the members want Kanban and half want Scrum?
Use the independent scoring approach from Step 9: have each person fill out the worksheet alone, then compare results. Disagreements on specific dimensions reveal valuable information. If one person scores work predictability at 1 and another at 3, they are experiencing different aspects of the work. The discussion about why they scored differently is more productive than debating method merits in the abstract. Often the resolution is a hybrid that addresses both camps' concerns: the Scrum advocates get the planning rhythm they want, and the Kanban advocates get the flow flexibility they need.
What if my organization mandates Scrum but my scores clearly favor Kanban?
Start with Scrum's ceremonies (sprint planning, review, retrospective) to meet organizational expectations, then introduce Kanban practices within that structure. Add WIP limits to your sprint board, track cycle time alongside velocity, and use cumulative flow diagrams in your retrospectives. Over time, present the flow data to leadership as evidence that certain Scrum constraints (like fixed sprint commitments) are hurting rather than helping. This gradual approach is more effective than asking for an exemption because you are showing results, not arguing theory. Many teams have successfully migrated from Scrum to Kanban this way over 3-6 months.