Kanban, Scrum or Scrumban: how to choose for your team
Three ways to organize a team's work: a continuous board, fixed sprints, or a mix. How they differ, how to choose between them, and how Prior supports each.
Kanban, Scrum and Scrumban are three ways to organize the work of a team. Kanban moves work across a board one item at a time. Scrum works in fixed rounds called sprints. Scrumban takes parts of both. The right one depends on how your work arrives and how much of it you can plan.
Where they come from
Kanban comes from Toyota. Taiichi Ohno used cards, called kanban in Japanese (a signboard or signal card), to tell each step of a production line when to make more. Work was pulled when there was room for it instead of pushed. David J. Anderson adapted the idea to software and knowledge work in Kanban: Successful Evolutionary Change for Your Technology Business (2010). Two of its core practices are to visualize the work on a board and to limit how much is in progress at once.
Scrum was written down by Ken Schwaber and Jeff Sutherland. The current Scrum Guide is dated November 2020. A Scrum team has a Product Owner, a Scrum Master and Developers. Work happens in sprints of one month or less. Each sprint contains Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. The team commits to a Sprint Goal, and the Developers who will do the work size the items.
Scrumban was described by Corey Ladas in his book Scrumban: Essays on Kanban Systems for Lean Software Development. It has no single definition. A common version is a board with limits on work in progress plus some Scrum habits, such as a regular review. Scrum.org also publishes a Kanban Guide for Scrum Teams for teams that want to bring flow practices into Scrum.
How they differ
| Kanban | Scrum | Scrumban | |
|---|---|---|---|
| Rhythm | Continuous | Fixed sprints | Board plus a regular review |
| Planning | When there is room | At the start of a sprint | Often when the board runs low |
| Change mid-way | Any time | Limited by the Sprint Goal | Usually flexible |
| Roles | None required | Product Owner, Scrum Master, Developers | Up to you |
| Estimates | Optional | Common, often story points | Optional |
| Key rule | Limit work in progress | Commit to a Sprint Goal | Both |
Limits on work in progress matter more than they look. Little's law, from queueing theory, says that in a stable process the average time an item spends in progress equals the average number of items in progress divided by the rate at which they finish. If your output stays the same and you start more items, each one takes longer.
How to choose
Ask three questions.
- How does work arrive? If it is unpredictable (support requests, bugs, urgent asks), a continuous board fits. If you can plan a few weeks ahead, sprints fit.
- Can the team commit to a goal for a period? If someone can change the priorities every day, a sprint is hard to protect. Choose Kanban.
- Do you want a regular pause to look back? Scrum builds that in. In Kanban you add it yourself.
Some examples. A support team answering requests: Kanban. A product team shipping a feature set every two weeks: Scrum. A small team that builds features and also handles a stream of bugs: Scrumban. One person with a list of projects: Kanban, or a plain list.
Switching is possible. Teams often start with a board, see what is stuck, and add sprints later when planning starts to matter.
Mistakes to avoid
- A board with no limits. Without a limit on work in progress, a Kanban board is a to-do list in columns.
- Sprints without a goal. A sprint that is only a bucket of tasks loses the point of the round.
- Rituals for their own sake. If a meeting never changes a decision, shorten it or drop it.
- Planning poker for everything. Estimate what you need to plan.
- Using velocity or burn charts to judge people. They are for the team's own planning.
- Changing methods mid-sprint. Wait for a natural break.
When they are the wrong tool
- For one person. A list with a clear next action is enough.
- When the order is fixed by dependencies. A construction plan or a launch checklist needs a timeline, not a board.
- When work is a single large deliverable. A thesis is not a flow of items.
- When nobody owns priorities. Scrum needs someone who decides what comes first.
In Prior
Prior supports the three through the Project type of a project. Choose it when you create or edit a project.
| Type | What you get | Plan |
|---|---|---|
| Standard | Tasks and notes with statuses and priorities | Free |
| Agile · Kanban | A backlog and a board where work flows through columns | Free |
| Agile · Scrum | Sprints, story points and Planning Poker for the team | Pro |
| Agile · Scrumban | A continuous board with story points and Planning Poker | Pro |
- The board. Agile projects have a Board tab beside Issues, Overview, Notes and Activity. Columns follow the project's statuses, and each shows how many cards it holds. Drag a card to another column, or open its menu and choose Move to a column. On a phone, columns are pills above the board.
- Kanban. The board is the center of it. Prior does not enforce limits on work in progress, so keep your own limit and watch the count at the top of each column. All tasks has a Kanban layout too, which can group by status, priority, project or due date.
- Scrum. The Cycles become Sprints. You get a sprint filter on the board and issues (Active sprint, All, Backlog), points progress and velocity on the Sprints tab, a burn chart, and the Planning Poker tab.
- Scrumban. It keeps Cycles, without burn charts, and adds story points. Planning Poker is available through Add a view.
- Changing your mind. Changing the type keeps your tasks. Points, sprints and the earlier setup stay stored, so switching back restores them.
Read more in Agile projects and Kanban, Scrum and Scrumban. For sizing, see story points and planning poker.