Agile, Scrum and Kanban Explained: Differences and How to Choose

Agile is an approach to development in which a team ships the product in small increments, gets feedback often and adjusts the plan as it goes. Scrum and Kanban are the two most common ways to work according to this approach: Scrum organizes work around short sprints with fixed roles and events, while Kanban organizes it around a continuous flow of tasks on a board with a cap on work in progress.

This article is for founders, managers and team leads of IT teams in Kazakhstan who want to understand what’s behind these words and choose a working model for their team. We’ll cover Agile principles, how Scrum and Kanban work, how they differ, the Scrumban hybrid, how it all gets set up in a task tracker, and where teams usually stumble during implementation.

Agile: values, not a methodology

Agile emerged in 2001 as a response to long projects in which a team worked for months to a detailed plan, only to discover at the end that the client needed something else. A group of developers wrote the Agile Manifesto, built on four values:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The values come with twelve principles. A few matter most for a manager: deliver working software frequently, from a couple of weeks to a couple of months; welcome changing requirements, even late in development; measure progress by working software, not reports; regularly stop and improve your own process.

The key thing to understand: Agile doesn’t tell you how many meetings to hold or which columns to draw on the board. It’s a set of values. The specific rules come from the frameworks and methods built on top of it, primarily Scrum and Kanban. That’s why the phrase “we do Agile” by itself says nothing about how a team’s work is actually organized.

A common misconception is that Agile means working without plans or deadlines. It doesn’t. There is a plan, but it’s short and reviewed regularly, while long-term goals live in the product roadmap. There are deadlines too: a team that works in steady iterations forecasts them more accurately, because it relies on the actual velocity of past iterations rather than an estimate made six months ago.

Scrum: roles, the sprint, events and artifacts

Scrum is the most formalized of the Agile approaches. Its rules are described in the Scrum Guide; the current edition was published in 2020. The team works in sprints of no more than a month, in practice usually one to two weeks. At the end of each sprint, there should be a usable result.

Roles. The Scrum Guide calls them accountabilities. A team usually has no more than ten people.

Role	Responsible for	Typical mistake
Product Owner	Product value, backlog order, the product goal	The role is given to a director who has no time for it
Scrum Master	A working process, removing impediments, coaching the team	Turns into a secretary who takes minutes
Developers	Creating the increment, the sprint plan, quality	Wait for a detailed spec instead of taking part in planning

Events. The sprint is the container for the other four.

Event	Duration per the Scrum Guide	Purpose
Sprint planning	Up to 8 hours for a one-month sprint, less for a two-week one	Choose the goal and tasks for the sprint
Daily Scrum (daily)	15 minutes	Check progress toward the sprint goal and impediments
Sprint review (demo)	Up to 4 hours for a one-month sprint	Show the result to the customer, update the backlog
Retrospective	Up to 3 hours for a one-month sprint	Find what to improve in how the team works

Artifacts and their commitments: the product backlog with the product goal, the sprint backlog with the sprint goal, and the increment with the Definition of Done. The sprint goal is often skipped, and that’s a mistake: without it, the sprint becomes a to-do list, and at the first urgent request nobody knows what can be postponed.

We explained in detail how to run sprints in a tracker day by day in our article on sprints and Agile delivery in Plane.

Kanban: flow, the board and WIP limits

Kanban came to software development from the Toyota Production System. Unlike Scrum, it has no roles, sprints or mandatory meetings. The Kanban Guide, whose latest edition was published in May 2025, describes three practices:

1. Visualize the workflow. Map out the stages a task goes through and show each task as a card on the board.
2. Actively manage work in progress. Cap it with WIP limits and make sure tasks don’t get stuck.
3. Improve the workflow. Regularly look at the metrics and change the process.

The WIP limit is Kanban’s central idea. It caps the number of tasks that can be at a stage or with one person at the same time. For example, no more than two tasks “In Progress” per developer and no more than three tasks in “Review” per team. When the limit is reached, nobody picks up a new task: first you help finish what’s already started. It sounds counterintuitive, but this is exactly how the time from starting a task to delivering it gets shorter.

What a kanban board looks like

A kanban board for an IT team usually has five or six columns: “Inbox,” “To Do,” “In Progress,” “Review,” “Testing,” “Done.” The headers of working columns show the limit, for example “In Progress (4).” The “Inbox” column has no limit; everything new lands there, and once a day or once a week the team decides what moves to “To Do” and in what order.

A useful technique is horizontal swimlanes. The top lane is reserved for urgent tasks, like a production outage, and has its own small limit, for example one task per team. All other work goes in the regular lane. That way, urgent work doesn’t get lost, but it doesn’t eat up the team’s entire capacity either. If cards pile up before “Review” or “Testing,” that’s your bottleneck, visible without any reports.

The Kanban Guide suggests tracking four flow metrics: work in progress (WIP), throughput (how many tasks are finished per period), work item age and cycle time (how long a task took from start to done). For a manager, the last one is the most intuitive: it answers the client’s question “when will it be ready?”

Scrum vs Kanban: the differences

Criterion	Scrum	Kanban
Cadence	Fixed-length sprints	Continuous flow
Planning	At the start of each sprint	As capacity frees up
Roles	Product Owner, Scrum Master, Developers	Not defined, existing roles are used
Mandatory meetings	Planning, daily, review, retrospective	None, the team decides
Changes to the work	Sprint scope is kept stable where possible	A new task can be picked up at any time
Limiting work	By sprint scope	By WIP limits at each stage
Key metrics	Sprint goal achievement, team velocity	Cycle time, throughput
Best for	Product development with regular releases	Support, DevOps, a stream of requests and bugs

A short rule of thumb. If the team can plan two weeks ahead and there isn’t much urgent work, Scrum will give it rhythm and predictability. If more than half of the work arrives unexpectedly and can’t wait for the next sprint, Kanban is more honest: it doesn’t pretend a plan exists.

Neither approach is better overall. Different teams in the same company can work differently: product development in sprints, support and DevOps with Kanban. What matters is that within one team the rules are consistent and clear to everyone, and that the manager sees both pictures in one tracker.

Scrumban: when you need a hybrid

In practice, many teams end up with a mix of the two approaches, called Scrumban. From Scrum, they take regular planning, reviews and retrospectives. From Kanban, a continuous flow of tasks and WIP limits.

Scrumban works well in three situations:

• The development team also supports the product and gets urgent bugs every day.
• An IT agency runs several client projects, and priorities change more often than every two weeks.
• The team is moving from Scrum to Kanban or vice versa and doesn’t want to break everything at once.

A typical setup: once a week or every two weeks, the team holds a short planning session and refills the “To Do” column, tasks are pulled according to WIP limits, urgent work gets a separate lane on the board with its own limit, and the retrospective happens on schedule. We covered how to set up a flow of bugs and urgent tasks with priorities and SLAs in our article on bug tracking and workflow.

What it looks like in a task tracker

You can run Agile on a wall of sticky notes, but as soon as the team works remotely or there’s more than one project, you need a tracker. Below is how the concepts map in the two systems IT teams in Kazakhstan choose most often.

Concept	Jira	Plane
Product backlog	Project backlog	Project backlog
Sprint	Sprint on a Scrum board	Cycle
Large feature	Epic	Epic as a work item type, Module
Kanban board	Project Kanban board	“Board” layout
WIP limit	Column constraints on the board	A team rule, monitored through views
Reports	Burndown, velocity, cumulative flow diagram	Cycle progress, dashboards
Search and filters	JQL	PQL

Setup starts the same way in both: four or five statuses that reflect real stages, one backlog and clear work item types. The mistake is trying to configure everything the tool can do right away. For a comparison of Jira and Plane on other criteria, see our article Plane or Jira in 2026.

Typical implementation mistakes in Kazakhstan IT teams

In our implementation experience, teams stumble not over theory but over habits.

• Scrum for Scrum’s sake. The company introduces all the events but doesn’t change how decisions are made. The daily becomes a status report to the manager, the retrospective a formality with no changes.
• A Product Owner without authority. The role formally exists, but the founder still changes priorities in private messages with developers.
• A sprint without a goal. Everything that has piled up gets thrown into the sprint, and half the tasks are closed by the end.
• The backlog lives in several places. Some tasks are in the tracker, some in a chat with the client, some in the team lead’s head.
• Kanban without limits. The team calls its board kanban, but everyone has six tasks “In Progress” and none of them gets finished.
• Retros without actions. Problems are discussed every two weeks but no changes are made. Two months later, the team stops holding retros.

Kazakhstan context. A strong WhatsApp culture breaks Agile more often than anything else. A client or manager messages a developer directly, the task goes into work bypassing the backlog, and the sprint plan stops meaning anything. A working rule: any request from a messenger becomes a task in the tracker, and the Product Owner decides whether to take it into the current sprint. The second local nuance is teams distributed between Almaty, Astana and remote work, plus bilingualism: it’s best to hold dailies and retros in a single video channel on a schedule and agree in advance on the language for tasks in the tracker, so the descriptions are clear to everyone.

Where to start: a plan for the first month

Week	What we do	Outcome
1	Collect all tasks into one backlog, choose Scrum or Kanban, agree on statuses	One backlog, 4–5 statuses, a Product Owner assigned
2	First sprint or launch of a kanban board with WIP limits	The team works only from the tracker
3	15-minute dailies, the rule “chat requests only through a task”	Urgent work is visible on the board, not in messages
4	Demo of results and the first retrospective, one or two process changes	Clear what works and what to change

Don’t try to implement everything at once. One team, one backlog and one month of honest work will give you more than a three-day methodology training for the whole company. We described the overall path from tasks in messengers to a proper system in our article how to implement a task tracker in a company.

How we do it

We start with a diagnostic: what kind of work comes into the team, how much of it is urgent, who makes priority decisions and where tasks live today. Based on that, we propose a model (Scrum, Kanban or Scrumban) and a minimal tracker setup for it, usually in Jira or Plane. Then we run a pilot with one team for two or three sprints or a month of Kanban, hold the first planning sessions and retrospectives together with the team, and only then roll the approach out to the other teams.

If you want to build your Agile process together with the tracker rather than separately from it, see our Jira and Plane task tracker implementation page: it describes the process, timelines and what’s included in the deliverables.

---

Sources. Agile Manifesto: agilemanifesto.org. Scrum Guide 2020: scrumguides.org. Kanban Guide 2025: kanbanguides.org. Plane repository: github.com/makeplane/plane.

Terms in plain words

Agile

A set of development values and principles: short iterations, frequent feedback, willingness to change the plan. Not a methodology but a way of thinking.

Scrum

A framework for working in short sprints with three roles, five events and three artifacts. It gives the team a rhythm for planning and releases.

Kanban

A method for managing the flow of work: visualizing stages on a board, limiting work in progress and continuously improving the process.

Sprint

A period of work of no more than a month, usually one to two weeks, with a goal and a set of tasks. At the end, the team shows the result.

Product Owner

The person responsible for the product’s value and the order of items in the backlog. Decides what the team works on first.

WIP limit

A cap on the number of tasks in progress at the same time. It forces the team to finish what it started and exposes process bottlenecks.

Retrospective

A meeting at the end of a sprint where the team discusses what got in the way and picks one or two changes for the next sprint.

Scrumban

A hybrid of Scrum and Kanban: regular planning and retrospectives plus a continuous flow of tasks with WIP limits.