Home / Insights / Dedicated Teams and Outsourcing
Dedicated Teams and Outsourcing
Kanban or Scrum? Choosing a Delivery Model for Your Team
Scrum organises work in fixed sprints with defined roles and events; Kanban manages continuous flow with work-in-progress limits. This guide compares them on the decisions that matter, explains flow metrics, and shows when to choose each or combine them.
TopicsDedicated Teams and OutsourcingQA and Software TestingProduct Design and Discovery
Key takeaways
- Scrum uses fixed sprints of one month or less, a product goal, defined accountabilities and events; it suits product development where regular inspection and adaptation drive the plan.
- Kanban visualises work, limits work in progress and manages flow continuously; it suits support, maintenance, operations and teams with unpredictable incoming work.
- Flow metrics — cycle time, throughput, work-item age and work in progress — are useful for both and make forecasting more honest.
- Many teams use hybrids: Scrum events with Kanban flow practices, or Kanban with regular review and planning cadences.
- With outsourced or dedicated teams, agree cadence, reporting, definition of done and decision rights before choosing labels.
On this page
- Scrum in brief
- Kanban in brief
- Side-by-side comparison
- Flow metrics everyone should know
- When to choose Scrum
- When to choose Kanban
- Hybrids that work
- Worked example: a product team with support load
- Setting WIP limits that help
- Making the meetings worth attending
- Common anti-patterns
- Running either model with an outsourced or dedicated team
- Switching between models
- Frequently asked questions
- Sources and methodology
Scrum and Kanban are the two most widely used agile approaches in software teams. They share values — transparency, frequent delivery, continuous improvement — but organise work differently. Choosing well depends on the kind of work, how predictable it is and how stakeholders want to engage.
This guide compares them practically. For a comparison of Scrum with Feature-Driven Development, see our guide to FDD versus Scrum.
Scrum in brief
- Cadence: fixed-length sprints of one month or less, according to the Scrum Guide; most teams use one or two weeks.
- Accountabilities: product owner (maximises value, owns the product backlog), Scrum Master (helps the team and organisation use Scrum effectively) and developers.
- Events: sprint planning, daily scrum, sprint review and sprint retrospective, within the sprint.
- Artefacts: product backlog with a product goal, sprint backlog with a sprint goal, and an increment that meets the definition of done.
- Planning: the team selects work for the sprint and aims to deliver a usable increment by the end.
Kanban in brief
- Visualise the workflow on a board with columns reflecting real stages, such as ready, in development, in review, testing and done.
- Limit work in progress (WIP) per stage or for the whole system, so the team finishes work before starting more.
- Manage flow: monitor how work moves, find bottlenecks and improve.
- Make policies explicit: definitions of ready and done for each stage, and how work is prioritised.
- Improve continuously through regular reviews of flow and process.
Kanban does not prescribe roles or fixed iterations. Teams add planning, review and retrospective cadences that suit them.
Side-by-side comparison
| Aspect | Scrum | Kanban |
|---|---|---|
| — | — | — |
| Cadence | Fixed sprints | Continuous flow, with chosen review cadences |
| Commitment | Sprint goal for a time box | WIP limits and service-level expectations |
| Roles | Product owner, Scrum Master, developers | No required roles; existing roles continue |
| Changing priorities mid-cycle | Discouraged within a sprint unless the goal becomes obsolete | Allowed when capacity frees up |
| Releases | At least one usable increment per sprint; can release more often | Any time an item is done |
| Core metrics | Sprint goal achievement, velocity (team-internal), burndown | Cycle time, throughput, work-item age, WIP |
| Best for | Product development with regular stakeholder feedback | Support, operations, maintenance, unpredictable demand |
Both work with continuous delivery; the difference is how work is planned and limited.
Flow metrics everyone should know
- Work in progress: items started but not finished.
- Cycle time: time from start to done for an item.
- Throughput: items completed per period.
- Work-item age: how long current items have been in progress — the earliest warning of stuck work.
These metrics are connected: on average, more work in progress means longer cycle times for the same throughput. Limiting WIP is therefore one of the most effective ways to speed delivery. Throughput history also supports probabilistic forecasting — “85% likely within six weeks” — which is more honest than single dates. Our guide to predictive project management shows how teams use this.
When to choose Scrum
- A new or evolving product where stakeholders need to see and steer increments regularly.
- A stable, cross-functional team working mainly on one product.
- An organisation that benefits from a regular planning and review rhythm.
- Teams that need structure to focus and protect themselves from constant interruptions.
When to choose Kanban
- Support, maintenance and operations teams with unpredictable incoming work.
- Teams handling many small items of different types.
- Mature teams already delivering continuously.
- Situations where fixed sprints would be artificial, such as a platform team serving many internal customers.
Hybrids that work
- Scrumban: keep sprints, reviews and retrospectives, add a Kanban board with WIP limits and flow metrics.
- Kanban with cadences: continuous flow plus fortnightly replenishment, monthly stakeholder reviews and regular retrospectives.
- Split by work type: product features in Scrum; incidents and small requests through a Kanban lane with explicit capacity.
Worked example: a product team with support load
A hypothetical team of seven runs two-week sprints but loses a third of its capacity to production issues and customer requests, so sprint goals are rarely met.
They change three things:
- A separate expedite lane on the board for incidents, with a limit of one at a time and a rotating on-call developer.
- WIP limits on development and review, which exposes a review bottleneck.
- Reporting cycle time and throughput alongside sprint goals.
Within a few sprints, sprint goals become realistic because unplanned work is visible and capped, and stakeholders get honest forecasts instead of repeated slippage.
Setting WIP limits that help
- Start from current reality: count items in each stage today and set limits slightly lower.
- Limit review and testing stages, where queues usually form unnoticed.
- Treat a full column as a signal to help, not to start something new: developers pair on reviews or help testing.
- Adjust gradually based on cycle time and team feedback; limits that are never reached are too high, limits constantly broken are too low or ignored.
Making the meetings worth attending
| Meeting | Purpose | Common failure | Fix |
|---|---|---|---|
| — | — | — | — |
| Planning or replenishment | Agree what to pull next and why | Overloading the plan | Plan to historical throughput, leave capacity for unplanned work |
| Daily stand-up | Coordinate to move work forward | Status reports to a manager | Walk the board right to left, focusing on blocked and ageing items |
| Review or demo | Inspect working software with stakeholders | Slides instead of software | Demonstrate only done work; collect feedback |
| Retrospective | Improve the way of working | Same complaints, no actions | One or two concrete experiments with owners |
Keep meetings short and purposeful; cancel ones that no longer add value.
Common anti-patterns
- Mini-waterfall sprints: design in week one, build in week two, test in the next sprint.
- Kanban without limits: a board that visualises work but never constrains it.
- Carry-over as normal: most sprint items rolling into the next sprint without discussion.
- Velocity targets: pressure to increase story points, which inflates estimates rather than output.
- Ignoring ageing work: items stuck for weeks without anyone asking why.
Running either model with an outsourced or dedicated team
| Agreement | Questions |
|---|---|
| — | — |
| Cadence | When are demos, planning and reviews, across which time zones? |
| Prioritisation | Who orders the backlog, and how quickly are decisions made? |
| Definition of done | Which tests, reviews, documentation and deployments are required? |
| Reporting | Which metrics does the client see weekly — sprint goals, cycle time, throughput, risks? |
| Availability | How is support work handled alongside planned work? |
| Escalation | How are blockers and risks raised and resolved? |
Agree these in the first week; they matter more than the method name.
Our guide to preparing for a dedicated team covers the wider set-up.
Switching between models
- From Scrum to Kanban: keep retrospectives and regular stakeholder reviews; introduce WIP limits and flow metrics before removing sprints.
- From Kanban to Scrum: appoint a product owner, define a product goal and start with short sprints while keeping the board.
- Either way: change one thing at a time and review after a few weeks.
Frequently asked questions
Is Kanban less disciplined than Scrum?
No. Kanban requires discipline in WIP limits, explicit policies and flow management; it simply does not use time-boxed sprints.
Can Kanban teams estimate?
They can, but many rely on throughput and cycle-time history instead of story points, which reduces estimation overhead.
Should we use velocity to compare teams?
No. Velocity is a team-internal planning aid and is not comparable between teams.
Which is better for fixed-scope projects?
Either can work. What matters is transparent progress against scope, honest forecasting and early discussion of trade-offs.
Sources and methodology
Facts in this article were checked against the sources below on 6 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
- Scrum.org (8 February 2023): How long should a Sprint be? — accessed 6 November 2026. Scrum Guide 2020: sprints are fixed-length events of one month or less
Related reading
Continue your research
Setting up or resetting a delivery process?
Tell us about your team, product and stakeholders. We will help you choose Scrum, Kanban or a hybrid, and set up the metrics and rituals that make it work.