Kanban vs Scrum: Which Suits a Small Team

Scrum and Kanban answer different questions. Scrum is a framework for delivering in fixed-length Sprints of a month or less, with three named accountabilities, five events and a goal for each Sprint. Kanban is a strategy for managing flow: you make the workflow visible, limit how much work is started but not finished, and improve the flow as you go, with no required roles or meetings. For most small teams the choice comes down to one thing: if your work can be planned a couple of weeks ahead and you benefit from a regular rhythm, Scrum suits you; if work arrives unpredictably and must be picked up as it comes, Kanban does.

What each guide actually says

Both methods have a short official guide, and both are worth reading before you choose, because much of what people call Scrum or Kanban is habit rather than method. The 2020 Scrum Guide↗ (opens in a new tab) describes a Scrum Team of one Product Owner, one Scrum Master and Developers, typically ten people or fewer. Work happens in Sprints of one month or less, and each Sprint contains Sprint Planning, a 15-minute Daily Scrum, a Sprint Review and a Sprint Retrospective. There are three artifacts, each with a commitment: the Product Backlog and its Product Goal, the Sprint Backlog and its Sprint Goal, and the Increment and its Definition of Done.

The Kanban Guide↗ (opens in a new tab) is shorter still. It defines Kanban as a strategy for optimising the flow of value through a process, built on three practices: defining and visualising a workflow, actively managing the items in it, and improving it. The people doing the work are simply “Kanban system members”. The guide names no roles and no events; it says members review active items regularly, and that there is no requirement to wait for a formal meeting at a regular cadence to change the workflow. What it does require is a definition of workflow, including how work in progress will be controlled and explicit policies for how items move.

Kanban vs Scrum, side by side

• Roles. Scrum: Product Owner, Scrum Master and Developers, each with defined accountabilities. Kanban: none required; you keep the roles you already have.
• Cadence and events. Scrum: fixed Sprints, with planning at the start, a daily check-in, and a review and retrospective at the end. Kanban: continuous flow; meetings happen when the team finds them useful.
• Planning. Scrum: at Sprint Planning the team agrees a Sprint Goal and selects work for the Sprint. Kanban: work is pulled from an ordered queue when there is capacity, one item at a time.
• Change mid-flight. Scrum: no changes are made that would endanger the Sprint Goal, though scope can be clarified and renegotiated with the Product Owner; only the Product Owner can cancel a Sprint. Kanban: the next item can change at any moment until someone starts it.
• Commitment. Scrum: the Sprint Goal is the Sprint Backlog’s commitment. Kanban: the guide asks for no goal; instead the definition of workflow includes a service level expectation, a forecast of how long an item should take from start to finish.
• Metrics. Scrum: the guide asks for empiricism and leaves the measures to the team; burn-downs and velocity are common practice rather than rules. Kanban: four flow measures are required: work in progress, throughput, work item age and cycle time.
• Boards. Scrum: the guide does not mention one; teams that use a board usually show only the current Sprint and reset it each time. Kanban: visualising the workflow is one of the three practices, so the board is central, it persists, and each column carries a limit or a policy.

The same week under each method

Take a four-person team building a booking app. On Wednesday a customer reports that confirmation emails have stopped. Under Scrum, the team asks whether the bug endangers the Sprint Goal. It is urgent, so they talk to the Product Owner, who swaps it for an item of similar size; if the goal itself is now pointless, the Product Owner can cancel the Sprint, which is rare. Under Kanban, the bug goes to the top of the queue and the next person with capacity pulls it. Nobody renegotiates anything, because nothing was promised beyond the order of the queue.

Now take a new feature that needs design, an API change and a mobile release. Scrum is at its best here: the Sprint Goal names the outcome, the team plans how to reach it together, and the review shows it working to the people who asked. Under Kanban the same feature is split into items that flow through separately, and nothing forces the team to stop and look at the whole thing together unless they choose to.

A decision guide for a small team

• Most of your work arrives unplanned (support, fixes, client requests, operations): choose Kanban. A Sprint plan that is torn up every week is worse than no plan.
• Your work is a product with a roadmap, and stakeholders want to see progress on a rhythm: choose Scrum. The Sprint Review is that rhythm.
• You are two or three people: start with Kanban. Scrum’s events and accountabilities assume enough people to fill them, and one person holding every role is doing paperwork.
• You keep starting things and not finishing them: choose Kanban, and set a work-in-progress limit before anything else.
• The team rarely agrees on what matters this fortnight: choose Scrum. Agreeing a Sprint Goal forces the conversation.
• You are regulated or client-facing and need a dated plan: either works, but Scrum’s Sprint boundary gives you a natural date to report against.

Whichever you choose, keep it for a few months before judging it. Both methods improve themselves through their own feedback loops, the Retrospective in Scrum and the regular review of the workflow in Kanban, and neither shows its value in the first fortnight.

Scrumban, in one paragraph

Scrumban is the common hybrid: Scrum’s timeboxed iterations with Kanban’s pull system, work-in-progress limits and visual board. The Agile Alliance glossary↗ (opens in a new tab) credits the term to Corey Ladas, who described it as a way for Scrum teams to add Lean flow ideas step by step. In practice teams use it two ways: Scrum teams that add WIP limits and flow metrics inside their Sprints, and Kanban teams that add a regular planning and review cadence. It is a reasonable place to end up, but it is not a shortcut; if you mix the two before you understand either, you usually keep the meetings and lose the discipline. What is Scrumban? covers it in full.

When some of the workers are AI agents

AI coding assistants and agents now pick up real work on many boards, and they fit the two methods differently. Scrum’s structure is built around people who plan together, forecast their own capacity and hold each other to a Sprint Goal. An agent does none of that. It can prepare for planning, but the Scrum Guide gives sizing and selection to the Developers, and a forecast only means something if the people who made it will be held to it. Sprint planning with AI covers what an assistant can do around those decisions without taking them over.

Kanban fits agents more naturally, because it is about the flow of items rather than the rhythm of a team: an agent can pull the next item from a queue as easily as a person can. What changes is where you put the limits and the policies. An agent will start ten things at once if nobody stops it, follows written policy literally, and cannot sign off its own work, so the limit belongs per agent and a person belongs in front of done. Kanban for AI agents goes through those changes in detail.

Either way, one rule holds: the method’s decisions stay with people. In Scrum that is the Sprint Goal and the selected work; in Kanban it is the order of the queue and the policy for when an item is finished.

Where fenbs fits

To be plain about it: fenbs is kanban-style. A board has four fixed lanes, To Do, Next Up, In Progress and Completed, and it has no sprints, no story points and no velocity chart. It also has no work-in-progress limit setting; a limit is a policy you write down, for people in the board’s AI context and for an assistant in its rules file. What it does give a Kanban team is the raw material for flow: History records every move with the lane it left, the lane it entered, the time and who moved it, whether a person or an AI assistant.

A Scrum team can still run Sprints on it, using To Do as the Product Backlog and Next Up as the Sprint; Sprint planning meeting shows how. But if your team depends on burn-down charts, story-point velocity or sprint reports generated for you, a dedicated Scrum tool will serve you better, and you should use one.