Adapting Planning Poker for Kanban Teams: When and How to Estimate in Continuous Flow

Planning poker is traditionally linked with Scrum teams and sprint-based planning. But what about Kanban teams operating in continuous flow?

Conventional wisdom says Kanban teams don't need estimation. Reality? More complex. Many Kanban teams discover that understanding work size becomes critical for decision-making, capacity planning, and stakeholder conversations.

This guide shows when Kanban teams benefit from estimation, how to adapt planning poker for continuous flow, and how to maintain Kanban's core principles while gaining predictability.

Why Planning Poker and Kanban Seem Incompatible

Scrum's Time-Boxed World

Scrum teams use planning poker during sprint planning to estimate work within fixed time-boxes. The estimation serves multiple purposes:

• Prevents sprint overcommitment
• Creates shared understanding of complexity
• Tracks velocity for long-term planning
• Surfaces dependencies and technical risks early

Estimation happens at discrete intervals—typically sprint start—with clear work boundaries.

Kanban's Flow-Based Reality

Kanban teams work differently. Work flows continuously without time boundaries. Instead of estimating upfront, they measure actual flow:

• Cycle time: Actual completion duration
• Lead time: Request to delivery duration
• Throughput: Items completed per period
• WIP limits: Constraints optimizing flow

This empirical approach tracks what happened rather than predicting what will. For many practitioners, this eliminates estimation needs.

The Estimation Paradox

Yet real-world Kanban teams face situations where sizing adds value:

• Stakeholders asking "When will this ship?"
• Capacity planning during vacations or onboarding
• Deciding whether to split large items
• Setting WIP limits that account for work size
• Balancing different work types with varying complexity

The paradox: How do you gain predictability without compromising flow principles?

When Kanban Teams Need Estimation

Not every Kanban team needs estimation. But specific situations make sizing valuable:

Forecasting Delivery Dates

Historical data doesn't always suffice when stakeholders want reliable forecasts:

• New work types without precedent
• Technical changes altering typical cycle times
• Hard deadlines or external dependencies
• Portfolio-level planning across teams

Combining lightweight estimation with flow metrics creates more accurate forecasts than either alone.

Setting Intelligent WIP Limits

How do you set effective WIP limits when work items vary dramatically?

A WIP limit of 3 items becomes meaningless when one item is a simple config change and another is architectural refactoring. Estimation helps by:

• Creating size-based WIP limits ("max 13 story points in progress")
• Identifying items needing breakdown before start
• Balancing different work types intelligently
• Preventing large items from hiding in WIP

Capacity Planning

Kanban teams still plan for vacations, onboarding, and resource allocation:

• Can we handle this project with current capacity?
• Should we hire more team members?
• How do we balance maintenance with new features?

Estimation provides common language for these conversations, especially combined with throughput data.

Managing Stakeholder Expectations

Stakeholders think in scope and deadlines. While educating them about flow metrics helps, sometimes you meet them where they are. Estimation sessions can:

• Communicate relative complexity to non-technical stakeholders
• Enable trade-off decisions about scope versus time
• Prioritize work based on effort versus value
• Build trust through improved predictability

Adapting Planning Poker for Continuous Flow

How do you adapt a sprint-based technique for continuous flow? Focus on adaptation, not wholesale adoption.

Lightweight, Just-in-Time Estimation

Skip estimating the entire backlog. Estimate just-in-time:

Pull-Based Approach: Estimate items only when they're about to enter workflow:

• During weekly or bi-weekly refinement sessions
• When items reach "Ready for Development"
• On-demand when pulling new work

This respects Kanban's pull principle while providing estimation benefits when they matter.

Quick Sessions: Ditch lengthy planning meetings. Run focused 15-minute sessions:

1. Pick 3-5 next-in-queue items
2. Quick discussion per item
3. Simultaneous card reveal
4. Brief conversation if estimates diverge significantly
5. Record estimate, move on

The goal: shared understanding and rough sizing, not perfect accuracy.

Size-Based Swim Lanes

Combine estimation with visual management. Create swim lanes on your Kanban board by work size:

• Expedite: Urgent items (typically small)
• Small (1-3 points): Quick wins, bug fixes
• Medium (5-8 points): Standard features
• Large (13+ points): Needs breakdown or special handling

This helps teams:

• Balance WIP across sizes
• Spot large items blocking flow
• Make pull decisions based on capacity
• Track cycle time by size category

Modified Planning Poker Process

Adapt traditional planning poker for continuous flow:

Frequency: Weekly or bi-weekly cadence instead of per sprint. Estimate enough to keep the pipeline flowing.

Scope: Only items likely pulled in 1-2 weeks. Skip estimating the entire backlog.

Scale: Use simplified scales. T-shirt sizes (XS, S, M, L, XL) often beat Fibonacci for flow-based teams.

Speed: Keep it fast. Discussion past 2-3 minutes per item? Table it for research.

Purpose: Frame as "understanding complexity" not "committing to delivery."

Integrating Estimates with Flow Metrics

Real power comes from combining estimation with Kanban's flow metrics:

Cycle Time by Size: Track how long different sizes actually take to refine forecasting:

• Small items (1-3 pts): 2 days average
• Medium items (5-8 pts): 5 days average
• Large items (13+ pts): 12 days average

Throughput Patterns: Monitor weekly points throughput. Creates velocity-like metrics while maintaining flow focus.

Estimate vs. Actual: Review accuracy periodically—not as a performance metric. Use it to improve understanding and identify uncertainty areas.

Practical Strategies for Kanban Teams

Five proven strategies for making planning poker work with continuous flow:

Strategy 1: The Bucketing Approach

Use planning poker to bucket work into broad categories instead of precise numbers:

• Tiny: Under half a day
• Small: Half day to 2 days
• Medium: 3-5 days
• Large: 5-10 days
• Too Large: Needs breakdown

Run quick sessions with these categories. More than one "Too Large" vote? Item returns for refinement.

This respects that Kanban teams care more about identifying outliers than precision.

Strategy 2: Reference Item Comparison

Maintain reference items at different sizes:

• Keep a visual board with past item examples at each size
• When estimating, ask: "Bigger or smaller than X?"
• Use planning poker cards to vote on the comparison
• Update references as work evolves

Works especially well for new teams or fluctuating membership.

Strategy 3: Risk-Based Estimation

Focus on uncertainty instead of effort. Use planning poker to assess:

• Technical risk: Unknown complexity level?
• Dependency risk: External factors count?
• Knowledge risk: Do we grasp requirements?

Higher risk items get broken down or receive special WIP allocation. Lower risk items flow through standard limits.

Strategy 4: Partial Team Estimation

Not everyone estimates everything. For specialized work:

• Backend developers estimate backend work
• Frontend developers estimate frontend work
• DevOps estimates infrastructure

Run mini sessions with relevant members only. Speeds estimation while keeping multiple perspectives.

Strategy 5: Estimation on Demand

Some teams skip regular sessions and estimate only when:

• An item seems unusually large or complex
• Stakeholders request a forecast
• The team debates whether to pull an item
• WIP limits are approached

Use planning-poker.app for ad-hoc sessions. Quick votes without formal meetings.

Maintaining Kanban Principles While Estimating

The biggest risk: undermining the principles that make Kanban effective.

Preserve Flow Focus

Estimation should support flow, never replace it:

• Never create artificial deadlines from estimates
• Always track actual cycle time alongside estimates
• Regularly review whether estimation helps or hinders flow
• Adjust based on what data shows

Estimation feeling like overhead? Reduce frequency or scope.

Avoid Commitment-Based Thinking

Scrum teams commit to sprint goals. Kanban teams optimize for flow. This distinction matters:

• Frame estimates as "current understanding" not "guaranteed delivery"
• Estimates inform pulling decisions, not binding agreements
• Use probability ranges instead of single-point estimates
• Explain this difference to stakeholders early

Respect WIP Limits Above All

When estimation conflicts with WIP limits, limits win:

• Don't pull extra work just because estimates suggest capacity
• Don't hold work back if WIP allows it, even if estimates seem high
• Use estimates to inform WIP limit adjustments, not override them
• WIP limits are policies; estimates are data points

Emphasize Empiricism

Kanban thrives on empirical observation. Ensure estimation enhances this:

• Compare estimates to actuals regularly
• Identify accuracy patterns
• Use discrepancies to spark improvement conversations
• Celebrate when flow metrics alone suffice

Tools for Kanban Team Estimation

The right tools make continuous flow estimation effortless.

Online Planning Poker Platforms

For remote or hybrid teams, online tools offer flexibility:

• On-demand sessions: Start when needed, not on schedule
• Async voting: Members vote as they pull work
• Integration: Connect with Jira, Trello, Linear
• Speed: Quick sessions that don't interrupt flow

Planning-poker.app supports both scheduled and spontaneous sessions, fitting Kanban's flexible nature.

Kanban Board Integration

Make estimates visible on your existing board:

• Card colors or tags by size
• Swim lanes organized by estimate range
• Visual indicators when items exceed thresholds
• Cumulative flow diagrams segmented by estimate

Keeps estimation integrated with workflow, not separate.

Flow Metrics Dashboards

Combine estimation data with flow metrics:

• Cycle time by estimate size
• Throughput in story points per week
• Estimate accuracy trends
• WIP levels versus total estimated points in progress

Most Kanban tools offer custom fields and reporting for this integration.

Common Challenges and Solutions

Challenge: Team Resists Estimation

Team members see estimation as counter to Kanban principles.

Solution:

• Start with a 4-week experiment and review
• Focus on benefits they care about (forecasting, WIP limits)
• Make estimation optional for items below a size threshold
• Show data on how estimation solves specific pain points

Challenge: Estimates Feel Like Commitments

Stakeholders treat estimates as deadlines.

Solution:

• Educate stakeholders on probabilistic forecasting
• Always provide ranges, never single numbers
• Share cycle time data alongside estimates
• Use "50% confidence" language: "50% confident this takes 3-5 days"

Challenge: Estimation Slows Flow

Estimation sessions create bottlenecks.

Solution:

• Reduce frequency
• Estimate smaller batches more often
• Use asynchronous estimation for straightforward items
• Set strict time-boxes (max 2 minutes per item)

Challenge: Estimates Are Consistently Wrong

Estimates rarely match actual cycle times.

Solution:

• Review patterns to identify blind spots
• Check if work types have changed
• Improve refinement before estimation
• Acknowledge estimation might not be valuable for your team—and that's OK

Should Your Kanban Team Estimate?

Not every team needs estimation. Use this framework:

You probably need estimation if:

• Stakeholders regularly ask for delivery forecasts
• Work items vary dramatically in size
• You struggle to set effective WIP limits
• You're doing capacity planning for new projects
• Historical data doesn't provide sufficient predictability

You probably don't need estimation if:

• Work items are relatively uniform
• Cycle time data provides sufficient forecasting
• Stakeholders accept flow-based forecasts
• WIP limits work well without size considerations
• Estimation feels like pure overhead

Try a hybrid approach if:

• Only certain work types need estimation (features vs bugs)
• Some stakeholders need estimates, others don't
• Your team has mixed feelings
• You want benefits without full commitment

Conclusion: Flexibility Over Dogma

The question isn't whether planning poker and Kanban are compatible. It's whether estimation adds more value than overhead to your continuous flow.

Successful Kanban teams approach estimation pragmatically. They adapt planning poker to fit their context, maintain flow focus, and continuously evaluate whether estimation serves their goals.

Start small:

• Pick one aspect addressing a specific pain point
• Try the bucketing approach for a few weeks
• Estimate only the largest items
• Use planning poker only when WIP limits are in question

Monitor results:

• Does estimation improve forecasting?
• Do WIP limits work better?
• Do stakeholders feel more confident?
• Does the team understand work better?

If yes, expand. If no, try a different adaptation or abandon estimation. No shame in choosing pure flow metrics if they serve you better.

The goal isn't being a "perfect Kanban team" or following planning poker dogmatically. It's delivering value effectively while respecting your team's reality. Whether that includes estimation, excludes it, or lands somewhere in between depends entirely on your context.

For teams ready to experiment, planning-poker.app offers the flexibility to run sessions on your terms—scheduled refinements or on-demand sizing when pulling new work.

Kanban's greatest strength is adaptability. Use planning poker when it helps, skip it when it doesn't, and always keep optimizing for flow.

Learn more about estimation best practices and handling wrong estimates to make your approach even more effective.