Scrum vs Kanban

Scrum and Kanban are the two agile methods teams compare most often. Both make work visible and both aim to deliver in small pieces. They differ in how they pace the work: Scrum plans in fixed time boxes, Kanban pulls work continuously and limits how much is in progress at once.

This page compares the two. For the wider family, including XP and Lean, see What is Agile Development?.

Scrum in brief

Scrum organizes work into sprints — fixed time boxes, usually one to four weeks. Each sprint starts with sprint planning, where the team picks the work it expects to finish, and ends with a review of what was built and a retrospective on how the team worked.

Scrum names three roles:

• Product Owner — owns the product backlog and its order.
• Scrum Master — coaches the team on the process and removes obstacles.
• Developers — build the increment.

The main measure is velocity: how much work the team finishes per sprint, which feeds the next sprint’s plan. See What is velocity?.

Kanban in brief

Kanban starts from the workflow the team already has. Work items move across a board of columns that represent stages (for example To do → In progress → Review → Done). Three ideas carry the method:

• Visualize the workflow — every item and every stage is on the board.
• Limit work in progress (WIP) — each column has a cap; a new item enters only when one leaves.
• Manage flow — the team measures how long items take (cycle time, lead time) and removes the bottlenecks.

Kanban has no time boxes and prescribes no roles. Planning happens whenever the queue needs refilling.

Side by side

	Scrum	Kanban
Cadence	Fixed sprints (1–4 weeks)	Continuous flow
Commitment	Work planned for the sprint	No batch commitment; pull when there is capacity
Roles	Product Owner, Scrum Master, Developers	None prescribed
Change mid-cycle	Discouraged inside a sprint	Allowed at any time
Limiting work	The sprint’s capacity	WIP limit per column
Main metrics	Velocity, burndown	Cycle time, lead time, throughput
Board	Reset each sprint	Persistent

Choosing between them

Neither method is better in general. Scrum suits teams that want a regular planning rhythm and a forecast built from past sprints, such as product teams shipping features on a schedule. Kanban suits work that arrives unpredictably and must be handled as it comes, such as support, operations, or maintenance.

Many teams mix the two (“Scrumban”): they keep a planning cadence and also keep an eye on how much is in progress.

How East Agile Tracker fits

East Agile Tracker is iteration-based, which places it closer to Scrum and to eXtreme Programming than to Kanban. It uses its own terms for some of the concepts above:

• Sprints are called iterations. Each project sets an iteration length of 1–4 weeks. Iterations are created automatically; there is no sprint to open or close. See Iterations.
• The backlog is a single ordered list. The product owner keeps it in strict priority order, and the Backlog projects the upcoming iterations from velocity. See User stories and iteration planning.
• Velocity sizes the plan. With auto-plan iterations on, the current iteration fills to your velocity and no further. See Planning an iteration.
• Each story carries its own state. A story moves through Unstarted → Started → Finished → Delivered → Accepted, shown on the card, rather than through board columns. See the state machine.

There are no WIP limits and no iteration-free flow mode. The Kanban ideas that do carry over are visibility (every story and its state is on one board) and flow metrics: the Metrics page shows the velocity trend, the burndown, and the stories carried over between iterations.

Further reading

• What is Agile Development? — the manifesto and the family of methods.
• What is velocity? — how velocity is calculated and used.
• What are story points? — relative estimation.