Agile, Scrum, and Kanban

Expected level: Working

Agile means building software in small steps, getting feedback often and adapting the plan. Scrum and Kanban are two common ways to organise a team's work that way.

Agile in one paragraph

The Agile Manifesto values working software, collaboration with customers, individuals and interactions, and responding to change, over heavy documentation, contracts, process and rigid plans. The point is short feedback loops: build a little, show it, learn, adjust. Agile is a set of values and has no single method.

Scrum

Scrum organises work into fixed-length iterations called sprints, commonly one to four weeks. The Scrum Guide defines the framework, and teams adapt the details.

  • Roles: the Product Owner decides what to build and in what order, the Scrum Master helps the team follow the process and removes obstacles, and the Developers are everyone who builds the product.
  • The backlog is the ordered list of work. Items are often written as user stories; see Requirements and User Stories.
  • The events are sprint planning, a short daily sync (the stand-up), a sprint review to show results, and a retrospective to improve how the team works.
  • The Definition of Done is the team’s shared checklist for finished work, for example reviewed, tested and documented.

Kanban

Kanban visualises work on a board with columns such as To do, In progress and Done. Its key rule is a work-in-progress (WIP) limit: only so many items may be in a column at once. Work is pulled when there is capacity, which exposes bottlenecks and encourages finishing before starting. There are no fixed sprints, so work flows continuously.

Comparing them

Scrum Kanban
Cadence Fixed sprints Continuous flow
Commitment Sprint goal and plan WIP limits
Changes mid-cycle Usually avoided Allowed whenever capacity opens
Typical fit Product development with planned increments Support, operations, steady request streams

Many teams mix them, sometimes called Scrumban.

Working inside a team process

  • Terms such as velocity, story points, epic and spike appear in the glossary. Estimation is touched on in Estimation Basics.
  • Agile does not mean no planning or no documentation.
  • Raise blockers early, at stand-up or sooner. See Ownership and Time Management.
  • If a meeting does not help, say so in the retrospective.

Try it

Look at your team’s board or backlog. Pick one item and trace it from idea to done: who wrote it, what its acceptance criteria are, what the Definition of Done requires, and where it could wait. If you have no board, draw a three-column Kanban board for your own tasks and set a WIP limit of two.

Common mistakes

  • Treating Agile as no planning or no documentation.
  • Keeping meetings and ceremonies that no longer help, and never saying so in the retrospective.
  • Sitting on a blocker instead of raising it at stand-up or sooner.

Check yourself

  • What is a WIP limit and what does it expose?
  • Name the four Scrum events.
  • Which of Scrum and Kanban fits a steady stream of support requests better, and why?

Related topics

Terms

Further reading