Kanban vs Scrum vs Scrumban: The Complete Framework Comparison Guide

Choosing between Kanban, Scrum, and Scrumban can make or break your team's productivity, yet 65% of organizations struggle with this decision.

Kanban vs Scrum vs Scrumban represents three distinct approaches to Agile workflow management, each with unique strengths for different team contexts.

The wrong framework choice costs teams months of frustration and lost productivity. The right choice transforms delivery predictability and team satisfaction.

This guide provides a comprehensive comparison of Kanban, Scrum, and Scrumban, including decision frameworks, implementation strategies, and real-world scenarios to help you choose confidently.

You'll learn the fundamental differences, when each framework excels, and how to implement your chosen approach successfully.

Understanding the Three Frameworks

The Agile landscape offers multiple frameworks, but Kanban, Scrum, and Scrumban dominate for good reasons.

Each framework emerged to solve specific workflow challenges. Understanding their origins helps clarify when each excels.

Kanban: Continuous Flow Management

Kanban originated from Toyota's manufacturing system, focusing on continuous flow and visual management.

Core Principles:

• Visualize work on a board
• Limit work in progress (WIP)
• Manage flow continuously
• Make process policies explicit
• Implement feedback loops
• Improve collaboratively

Key Characteristics:

• No prescribed roles or ceremonies
• Continuous delivery without iterations
• Pull-based work system
• Flexible prioritization
• Flow efficiency focus

Kanban excels when work items vary in size and priority changes frequently.

Learn more about Kanban practices and their implementation.

Scrum: Iterative Sprint Framework

Scrum provides a structured framework with defined roles, events, and artifacts for iterative development.

Core Components:

• Fixed-length sprints (1-4 weeks)
• Three defined roles (Product Owner, Scrum Master, Development Team)
• Five ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Sprint Refinement)
• Three artifacts (Product Backlog, Sprint Backlog, Product Increment)

Key Characteristics:

• Time-boxed iterations
• Prescribed team structure
• Regular inspect-and-adapt cycles
• Sprint commitments
• Velocity tracking

Scrum excels with complex products requiring regular stakeholder feedback.

Explore Scrum framework fundamentals for deeper understanding.

Scrumban: The Hybrid Approach

Scrumban combines Scrum's structure with Kanban's flow principles, offering flexibility with guardrails.

Hybrid Elements:

• Optional time-boxed planning
• Kanban board with WIP limits
• Pull-based work system
• Flexible ceremonies
• Flow metrics combined with velocity

Key Characteristics:

• Adaptable structure
• Continuous improvement focus
• Flexible team roles
• Mixed metrics approach
• Evolutionary design

Scrumban excels for teams transitioning between frameworks or needing both structure and flexibility.

Core Framework Comparison

Understanding fundamental differences helps teams make informed framework choices.

Structure and Time Boxing

Framework Structure Comparison:

Framework	Time Boxing	Work Planning	Delivery Cadence
Kanban	None	Continuous replenishment	Continuous
Scrum	Fixed sprints	Sprint planning	End of sprint
Scrumban	Optional	On-demand planning	Flexible

Kanban's Continuous Flow: No iterations or sprints. Work flows continuously through the system.

Teams pull new work when capacity allows, maintaining steady throughput.

Scrum's Sprint Structure: Fixed-length iterations create predictable rhythm. Each sprint is a mini-project with planning, execution, and review.

Time boxing forces prioritization and creates delivery momentum.

Scrumban's Flexibility: Teams choose their time boxing approach. Some use planning triggers, others maintain sprint-like cadences.

The hybrid allows adaptation to changing needs.

Roles and Responsibilities

Role Structure Comparison:

Framework	Prescribed Roles	Team Structure	Leadership Model
Kanban	None required	Self-organizing	Emergent leadership
Scrum	Three specific roles	Defined team structure	Distributed accountability
Scrumban	Flexible roles	Adaptive structure	Hybrid leadership

Kanban Roles: No prescribed roles allow teams to define their own structure.

Existing organizational roles continue. Some teams add Service Delivery Managers or Flow Masters.

Scrum Roles:

• Product Owner: Maximizes product value and manages backlog
• Scrum Master: Facilitates Scrum process and removes impediments
• Development Team: Self-organizing professionals delivering increments

Each role has specific accountabilities that cannot be combined.

Understand Scrum roles in detail.

Scrumban Roles: Teams adapt Scrum roles to their context. Product Owners may exist with lighter responsibilities.

Flow management may replace traditional Scrum Master duties.

Planning and Prioritization

Planning Approach Comparison:

Framework	Planning Frequency	Prioritization Method	Backlog Management
Kanban	On-demand	Continuous	Dynamic prioritization
Scrum	Each sprint	Sprint Planning	Product Backlog refinement
Scrumban	Trigger-based	Hybrid approach	Flexible backlog

Kanban Planning: Replenishment meetings occur when work drops below threshold. Teams pull highest priority items continuously.

Priority can change anytime without disrupting sprint commitments.

Scrum Planning: Sprint Planning happens at each sprint start. Team commits to Sprint Goal and selected backlog items.

Changes require Product Owner and team agreement.

Scrumban Planning: Planning triggers (WIP thresholds, time intervals, or both) determine when planning occurs.

Provides structure without rigid sprint boundaries.

Meetings and Ceremonies

Meeting Structure Comparison:

Framework	Daily Meeting	Planning	Review	Retrospective
Kanban	Optional standup	As needed	Optional	Regular
Scrum	Daily Scrum (15 min)	Sprint Planning	Sprint Review	Sprint Retrospective
Scrumban	Daily standup	Trigger-based	Optional	Regular

Kanban Meetings: No prescribed ceremonies. Many teams adopt daily standups focused on flow.

Regular retrospectives drive continuous improvement.

Scrum Ceremonies: Five ceremonies structure the sprint:

• Sprint Planning: Define sprint work
• Daily Scrum: Synchronize daily
• Sprint Review: Demonstrate increment
• Sprint Retrospective: Improve process
• Backlog Refinement: Prepare future work

Each ceremony has specific time boxes and purposes.

Scrumban Meetings: Teams adopt beneficial ceremonies from both frameworks. Common pattern: daily standups plus periodic retrospectives.

Planning meetings occur based on triggers rather than fixed schedule.

Metrics and Measurement

Metrics Comparison:

Framework	Primary Metrics	Success Indicators	Improvement Focus
Kanban	Cycle time, throughput, flow efficiency	Predictable delivery	Flow optimization
Scrum	Velocity, sprint burndown, completed stories	Sprint goal achievement	Team capacity
Scrumban	Hybrid metrics	Balanced delivery	System optimization

Kanban Metrics: Flow metrics provide predictability without velocity. Cycle time and throughput track system performance.

Kanban metrics drive continuous flow optimization.

Scrum Metrics: Velocity tracks team capacity over sprints. Burndown charts show sprint progress.

Sprint completion percentage indicates commitment reliability.

Scrumban Metrics: Teams combine flow metrics with capacity tracking. Provides comprehensive performance view.

Flexibility allows metric evolution as team matures.

When to Choose Kanban

Kanban thrives in specific contexts where continuous flow provides maximum value.

Ideal Team Characteristics

Team Profiles for Kanban:

Mature Self-Organizing Teams: Experienced teams comfortable with autonomy. No need for prescribed structure.

Support and Maintenance Teams: Work arrives unpredictably. Continuous flow handles varied priorities.

Multi-Skilled Teams: Cross-functional capabilities enable smooth work flow. No specialist bottlenecks.

Distributed Teams: Asynchronous work benefits from continuous flow. No ceremony coordination complexity.

Perfect Work Types

Work Characteristics:

Varied Size and Complexity: Work items range from minutes to weeks. WIP limits handle variability better than sprint commitments.

Unpredictable Arrival: New work arrives continuously. Cannot batch into sprint boundaries.

Operational Work: Bug fixes, customer support, infrastructure maintenance. Immediate response more important than sprint completion.

Knowledge Work: Research, analysis, architectural decisions. Hard to estimate and plan in sprints.

Explore when Kanban beats Scrum for specific scenarios.

Organizational Context

Favorable Conditions:

Minimal Stakeholder Structure: Low ceremony overhead preferred. Teams deliver continuously without review meetings.

High Change Frequency: Priorities shift daily or weekly. Sprint commitments become obstacles.

Service-Oriented Model: SLA-driven work with response time requirements. Continuous flow ensures responsiveness.

Mature Agile Culture: Organization trusts teams without prescribed structure. Empiricism embedded.

When to Choose Scrum

Scrum excels when teams need structure, stakeholder alignment, and iterative feedback.

Team Maturity Needs

Team Profiles for Scrum:

New to Agile: Teams need prescribed structure to learn Agile principles. Scrum provides clear framework.

Unclear Roles: Organizations benefit from defined accountabilities. Three roles prevent responsibility diffusion.

Need for Discipline: Time-boxed sprints create healthy pressure. Teams learn sustainable pace.

Growing Teams: Scrum ceremonies enable effective scaling. Clear communication patterns emerge.

Project Requirements

Work Characteristics:

Complex Product Development: Regular inspection and adaptation essential. Sprint reviews provide stakeholder feedback loops.

Estimable Work: Work can be broken into sprint-sized chunks. Team velocity becomes predictable.

Feature-Driven: Clear product roadmap with planned releases. Sprint planning aligns team with strategy.

Incremental Value: Each sprint delivers usable increment. Stakeholders see regular progress.

Learn about Scrum values that enable success.

Stakeholder Expectations

Organizational Requirements:

Regular Demonstrations: Leadership expects periodic progress reviews. Sprint Reviews satisfy reporting needs.

Predictable Planning: Budget and resource allocation require forecasting. Velocity enables capacity planning.

Change Control: Mid-sprint stability preferred. Changes evaluated at sprint boundaries.

Transparent Progress: Sprint burndowns and velocity charts provide visibility. Management comfort with predictability.

When to Choose Scrumban

Scrumban offers best of both worlds for specific transition and hybrid scenarios.

Transition Scenarios

Migration Contexts:

Scrum to Kanban: Team outgrows Scrum structure but needs gradual change. Scrumban provides safe transition path.

Kanban to Scrum: Adding structure to chaotic flow. Scrumban introduces ceremonies without full Scrum rigor.

Framework Experimentation: Organization exploring optimal approach. Scrumban allows learning both paradigms.

Team Maturity Evolution: Team capabilities changing over time. Scrumban adapts to growing maturity.

Hybrid Requirements

Organizational Needs:

Mixed Work Types: Both project and operational work. Scrumban handles both effectively.

Partial Stakeholder Alignment: Some stakeholders want sprints, others want continuous flow. Hybrid satisfies both.

Geographic Distribution: Some locations prefer Scrum, others Kanban. Scrumban creates common ground.

Gradual Transformation: Large organization needs phased change. Scrumban reduces transformation resistance.

Scaling Considerations

Multi-Team Coordination:

Portfolio Management: Mix of Scrum and Kanban teams. Scrumban provides common metrics language.

Dependency Management: Some teams need sprint synchronization, others continuous delivery. Scrumban enables both.

Resource Sharing: Specialists work across teams with different frameworks. Scrumban reduces context switching.

Organizational Learning: Teams at different maturity levels. Scrumban accommodates diversity.

Detailed Feature Comparison

Deep comparison reveals nuanced differences that impact daily operations.

Flexibility vs Structure

Adaptability Spectrum:

Aspect	Kanban	Scrum	Scrumban
Change Response	Immediate	Sprint boundary	Configurable
Process Prescription	Minimal	High	Medium
Role Definition	Flexible	Strict	Adaptable
Ceremony Requirements	Optional	Mandatory	Selective

Kanban Flexibility: Change happens continuously. No sprint boundaries constrain responsiveness.

Process evolves organically as team learns optimal patterns.

Scrum Structure: Sprint commitment provides stability. Changes negotiated at planning.

Prescribed ceremonies ensure regular inspection and adaptation.

Scrumban Balance: Teams configure their structure. Add Scrum elements where valuable.

Remove constraints that don't serve team needs.

Change Management

Priority Change Handling:

Kanban Approach: New work enters queue based on priority. Highest value work always next.

No disruption to in-progress items. Smooth continuous prioritization.

Scrum Approach: Sprint backlog protected from changes. New requests wait for next sprint.

Product Owner manages stakeholder expectations. Team maintains focus.

Scrumban Approach: Change policies defined by team. Some use sprint-like boundaries, others continuous flow.

Flexibility reduces stakeholder friction while protecting team focus.

Team Autonomy

Self-Organization Levels:

Kanban Autonomy: Maximum self-organization. Teams define all practices and policies.

Service Delivery Manager may emerge but isn't required.

Scrum Autonomy: Self-organizing within framework constraints. Teams choose how to work, but Scrum structure maintained.

Scrum Master ensures framework adherence.

Scrumban Autonomy: Team chooses which constraints to adopt. High autonomy with optional structure.

Evolves as team learns optimal working patterns.

Quality Practices

Built-In Quality:

Framework	Quality Approach	Definition of Done	Technical Practices
Kanban	Explicit policies	Flow-based quality gates	Team-defined
Scrum	Done criteria per increment	Sprint-level DoD	Encouraged
Scrumban	Hybrid approach	Flexible standards	Adaptive

Kanban Quality: Process policies make quality expectations explicit. Column exit criteria ensure standards.

Quality gates can be stricter than Scrum's DoD.

Scrum Quality: Definition of Done ensures consistent increment quality. Expands as team capability grows.

Technical practices like TDD and CI/CD often adopted.

Scrumban Quality: Teams adopt quality practices from both frameworks. May use DoD with flow-based policies.

Quality evolves with team maturity.

Implementation Strategies

Successful adoption requires thoughtful implementation approaches for each framework.

Starting with Kanban

Kanban Implementation Path:

Week 1-2: Visualization

• Map current workflow states
• Create Kanban board with columns
• Add all current work items
• Begin daily standups focused on flow

Week 3-4: WIP Limits

• Measure baseline WIP in each column
• Set initial WIP limits at 80% of baseline
• Implement limit enforcement
• Monitor violations and patterns

Week 5-8: Flow Optimization

• Track cycle time and throughput
• Identify bottlenecks
• Adjust WIP limits based on data
• Implement explicit process policies

Week 9-12: Continuous Improvement

• Establish feedback loops
• Regular retrospectives
• Flow efficiency measurement
• Service level expectation (SLE) definition

Success Factors:

• Start simple, add complexity gradually
• Use data to drive decisions
• Involve whole team in design
• Focus on flow over utilization

Implementing Scrum

Scrum Implementation Path:

Week 1: Foundation

• Form Scrum Team with defined roles
• Create initial Product Backlog
• Define working agreements
• Set sprint length (start with 2 weeks)

Week 2: First Sprint

• Conduct first Sprint Planning
• Daily Scrums at same time/place
• Focus on learning Scrum mechanics
• Hold Sprint Review and Retrospective

Month 2-3: Establishing Rhythm

• Refine Product Backlog regularly
• Improve estimation accuracy
• Develop Definition of Done
• Build stakeholder engagement

Month 4-6: Optimization

• Stabilize velocity
• Enhance technical practices
• Deepen inspect-and-adapt cycles
• Scale if needed

Success Factors:

• Commit to framework for 3-6 months
• Invest in Scrum Master training
• Protect sprint boundaries initially
• Regular retrospective improvements

Adopting Scrumban

Scrumban Implementation Path:

Phase 1: Assess Current State

• Document existing practices
• Identify pain points
• Define desired outcomes
• Choose starting elements

Phase 2: Design Hybrid

• Select Scrum ceremonies to keep
• Add Kanban flow practices
• Define trigger-based planning
• Set WIP limits within structure

Phase 3: Pilot and Adjust

• Run 2-3 cycles with hybrid
• Collect team feedback
• Measure key metrics
• Adjust approach based on learning

Phase 4: Stabilize

• Document working hybrid
• Train new team members
• Share learnings across organization
• Continue evolution

Success Factors:

• Clear rationale for hybrid choices
• Avoid "worst of both worlds"
• Regular assessment of effectiveness
• Willingness to evolve approach

Common Mistakes and Solutions

Teams make predictable mistakes when choosing and implementing frameworks.

Framework Mismatches

Common Mismatches:

Forcing Scrum on Service Teams: Operations and support teams suffer under sprint constraints. Continuous flow serves them better.

Solution: Evaluate work characteristics, not just organizational preference.

Kanban for New Teams: Teams new to Agile need more structure. Pure Kanban lacks guardrails.

Solution: Start with Scrum, evolve to Kanban as maturity grows.

Scrumban Without Intention: Accidental hybrids from poor Scrum implementation. "Scrum but" becomes excuse for avoiding discipline.

Solution: If hybrid chosen, make intentional design decisions with clear rationale.

Hybrid Confusion

Problematic Hybrids:

Too Much of Everything: All Scrum ceremonies plus all Kanban practices creates overhead.

Solution: Choose elements that serve specific needs, eliminate rest.

Inconsistent Application: Different team members follow different rules.

Solution: Document hybrid clearly, ensure team alignment.

Cherry-Picking Easy Parts: Taking flexibility without discipline.

Solution: Balance freedom with accountability mechanisms.

Recovery Strategies

When Framework Fails:

Assessment Phase:

• Identify specific failure points
• Separate framework issues from execution problems
• Gather team and stakeholder input
• Analyze metrics and outcomes

Correction Approach:

• Return to framework fundamentals
• Get external coaching if needed
• Recommit or choose different framework
• Allow time for proper implementation

Success Criteria:

• Clear metrics improvement
• Team satisfaction increase
• Stakeholder confidence restoration
• Sustainable practices emergence

Real-World Case Studies

Learning from others' experiences accelerates your framework decision.

Kanban Success Story

Context: IT Support Team

Challenge: 24/7 support team handling incidents, requests, and projects simultaneously. Scrum sprints disrupted by urgent issues.

Implementation:

• Created three swim lanes: incidents, requests, projects
• WIP limits per lane based on priority
• SLAs defined per work type
• Daily standups focused on blocked items

Results:

• Response time improved 45%
• Team stress decreased significantly
• Predictable SLA achievement
• Better project progress despite interruptions

Key Learning: Kanban's flow principles perfect for interrupt-driven work.

Scrum Transformation

Context: Product Development Team

Challenge: Team struggled with ad-hoc requests disrupting feature development. No clear priorities or delivery rhythm.

Implementation:

• Adopted 2-week sprints
• Product Owner role clarified priorities
• Sprint Planning with capacity-based commitment
• Sprint Reviews created stakeholder alignment

Results:

• Velocity stabilized after 5 sprints
• Feature delivery increased 30%
• Stakeholder satisfaction improved dramatically
• Team morale increased with clear focus

Key Learning: Scrum's structure transformed chaos into predictable delivery.

Scrumban Evolution

Context: Software Maintenance Team

Challenge: Transitioning from Scrum to support mix of projects and maintenance. Pure Kanban felt too unstructured.

Implementation:

• Kept 2-week planning cycles
• Added WIP limits within sprint
• Made Sprint Review optional
• Maintained retrospectives

Results:

• Handled mixed work types effectively
• Maintained stakeholder confidence with planning rhythm
• Improved flow with WIP limits
• Team satisfaction increased with flexibility

Key Learning: Thoughtful hybrid preserved benefits while solving specific problems.

Decision Framework

Systematic approach to choosing the right framework for your context.

Assessment Criteria

Evaluation Matrix:

Criterion	Kanban Score	Scrum Score	Scrumban Score
Work predictability	Low preference	High preference	Medium
Priority stability	Low need	High need	Medium
Team maturity	High required	Medium required	High required
Stakeholder structure	Low	High	Medium
Change frequency	High	Low	Medium

Scoring Your Context:

Work Predictability (1-5):

• 1: Work arrives unpredictably → Kanban
• 5: Work planned in advance → Scrum
• 3: Mix of planned and unplanned → Scrumban

Priority Stability (1-5):

• 1: Priorities change daily → Kanban
• 5: Priorities set for weeks → Scrum
• 3: Weekly priority adjustments → Scrumban

Team Maturity (1-5):

• 1-2: New to Agile → Scrum
• 3: Comfortable with Agile → Scrumban
• 4-5: Highly mature → Kanban

Selection Process

Step-by-Step Decision:

Step 1: Assess Work Characteristics

• Document typical work items
• Analyze arrival patterns
• Evaluate size distribution
• Determine priority change frequency

Step 2: Evaluate Team Context

• Assess Agile maturity
• Understand skill distribution
• Consider team size
• Review current pain points

Step 3: Consider Organizational Factors

• Stakeholder expectations
• Reporting requirements
• Change tolerance
• Resource sharing needs

Step 4: Make Provisional Choice

• Score each framework
• Select highest-scoring option
• Document decision rationale
• Define success criteria

Step 5: Plan Implementation

• Create adoption roadmap
• Identify training needs
• Set measurement approach
• Plan regular reviews

Validation Methods

Testing Your Choice:

3-Month Pilot:

• Implement framework fully
• Track defined success metrics
• Gather regular team feedback
• Assess stakeholder satisfaction

Key Validation Questions:

• Are we delivering value faster?
• Is team satisfaction improving?
• Do stakeholders feel confident?
• Are processes improving over time?

Decision Points:

• Continue with current framework
• Adjust implementation approach
• Switch to different framework
• Evolve to hybrid model

Migration Paths

Teams often need to transition between frameworks as context changes.

Kanban to Scrum

When to Migrate:

• Team grew, needs more structure
• Stakeholders requesting predictability
• Product development replacing maintenance
• New team members need framework guidance

Migration Steps:

1. Introduce sprint concept with existing flow
2. Add Sprint Planning and Review
3. Define Product Owner role
4. Implement Sprint Retrospectives
5. Add Scrum Master role
6. Full Scrum adoption

Timeline: 3-6 months for smooth transition.

Scrum to Kanban

When to Migrate:

• Team very mature, structure feels constraining
• Work became primarily maintenance
• Continuous delivery more important than sprint cadence
• Sprint boundaries causing artificial delays

Migration Steps:

1. Make sprint backlog continuous
2. Add WIP limits to sprint board
3. Make ceremonies optional
4. Reduce prescribed roles
5. Shift to flow metrics
6. Full Kanban adoption

Timeline: 2-4 months for gradual shift.

Either to Scrumban

When to Migrate:

• Pure framework not fully fitting
• Need both structure and flexibility
• Mixed work types emerging
• Team requesting hybrid approach

Migration Approach:

1. Assess current practices
2. Identify valuable elements to keep
3. Add complementary practices
4. Document hybrid design
5. Pilot for 2-3 cycles
6. Stabilize approach

Timeline: 1-3 months for intentional hybrid.

Tools and Technology

Right tools support framework implementation without constraining practices.

Framework-Specific Tools

Kanban Tools:

• Jira: Powerful WIP limits and flow metrics
• LeanKit: Designed specifically for Kanban
• Kanbanize: Advanced analytics and automation

Scrum Tools:

• Jira Software: Sprint planning and tracking
• Azure DevOps: Microsoft ecosystem integration
• Rally: Enterprise Scrum at scale

Scrumban Tools:

• Jira: Configurable for hybrid approaches
• ClickUp: Flexible views and workflows
• Monday.com: Adaptable board structures

Universal Solutions

Works for All Frameworks:

• Physical boards (for co-located teams)
• Trello (simple workflows)
• Notion (lightweight processes)
• Miro (remote collaboration)

Selection Principle: Choose tools that support your framework, don't let tools dictate your process.

Tool Selection Criteria

Evaluation Factors:

Framework Support:

• Native support for chosen framework
• Flexibility for hybrid approaches
• Customization capabilities
• Metric and reporting alignment

Team Needs:

• Distributed team support
• Integration with existing tools
• Mobile accessibility
• Collaboration features

Organizational Requirements:

• Security and compliance
• Scaling capabilities
• Cost and licensing
• Vendor support

Start Simple: Begin with basic tools, upgrade as needs become clear.

Conclusion

Choosing between Kanban, Scrum, and Scrumban is not about finding the universally "best" framework - it's about matching your team's context, maturity, and work characteristics with the right approach.

Kanban excels with mature teams handling unpredictable work requiring continuous flow and flexible prioritization.

Scrum provides essential structure for teams new to Agile, complex product development requiring stakeholder alignment, and situations demanding predictable delivery rhythms.

Scrumban offers the middle path, combining structure with flexibility for teams in transition or managing mixed work types.

Your framework choice should evolve as your team and context change. Start with one framework, give it 3-6 months to stabilize, then assess and adjust based on actual outcomes rather than opinions.

The most successful teams focus less on framework purity and more on delivering value consistently while maintaining sustainable pace and continuous improvement.

Use the decision frameworks, assessment criteria, and implementation strategies in this guide to make an informed choice - then commit to learning and adapting as you go.

Continue Reading

Frequently Asked Questions on Kanban vs Scrum vs Scrumban

Häufig gestellte Fragen (FAQs)