In this article · 9 sections
Anyone commissioning or building software hears these words constantly: Agile, Scrum, Kanban, sprints, backlogs, stand-ups. They are often used loosely and sometimes interchangeably, which creates confusion. In fact they sit at different levels. Agile is a mindset, while Scrum and Kanban are specific ways of putting it into practice.
This guide explains each in plain language and helps you choose.
Agile: the mindset
Agile came from the 2001 Manifesto for Agile Software Development, written by practitioners frustrated with heavyweight, plan-everything-upfront methods. It 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 items on the right still matter, but those on the left matter more. In practice, Agile means delivering in small increments, getting feedback early and adapting as you learn, because requirements almost always change once real users get involved.
Agile is not a specific process. Many frameworks are Agile, and some teams claim to be Agile without being so.
Scrum
Scrum is the most widely used Agile framework. It organises work into fixed-length cycles called sprints, typically one to four weeks, each producing a usable increment of the product.
Roles
According to the Scrum Guide, a Scrum team has three accountabilities:
- Product Owner: responsible for maximising the product’s value and managing the product backlog
- Scrum Master: helps the team understand and apply Scrum and removes obstacles
- Developers: the people who do the work of building the product, including designers, engineers and testers as needed
Events
- Sprint: the container for all other events, with a fixed length
- Sprint Planning: the team chooses what to deliver and how
- Daily Scrum: a short daily check-in to align and adjust the plan
- Sprint Review: the team shows what was built and gathers feedback
- Sprint Retrospective: the team reflects on how it works and agrees improvements
Artefacts
- Product Backlog: an ordered list of everything the product might need
- Sprint Backlog: the items selected for this sprint, plus the plan
- Increment: the usable result, meeting the team’s agreed definition of done
When Scrum works well
- Products with evolving requirements and frequent stakeholder feedback
- Teams of a manageable size who can commit to a cadence
- Work that can be broken into small, deliverable pieces
Potential downsides
- Ceremonies can become empty rituals
- Fixed sprints can feel rigid for interrupt-driven work such as support
- It needs a genuinely empowered Product Owner
Kanban
Kanban comes from lean manufacturing. Instead of time-boxed sprints, work flows continuously across a visual board.
Core practices
- Visualise the workflow with columns such as To Do, In Progress, Review and Done
- Limit work in progress (WIP) so the team finishes things before starting new ones
- Manage flow, looking for bottlenecks and aiming to reduce the time items take to move through
- Make policies explicit, such as what “done” means for each column
- Improve continuously using data and regular reviews
Useful measures
- Cycle time: how long an item takes from start to finish
- Throughput: how many items are completed over a period
- WIP: how many items are in progress at once
When Kanban works well
- Maintenance, support and operations work with unpredictable incoming tasks
- Teams that want to start from their current process and improve gradually
- Situations where priorities change often
Potential downsides
- Without a cadence, teams can lose focus on regular feedback and reflection
- WIP limits require discipline
Scrum vs Kanban at a glance
| Aspect | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed-length sprints | Continuous flow |
| Roles | Product Owner, Scrum Master, Developers | No prescribed roles |
| Planning | At the start of each sprint | Continuous, as capacity frees up |
| Change mid-cycle | Generally avoided within a sprint | Welcome at any time |
| Key metric | Sprint goal and increment | Cycle time and throughput |
| Work limits | Capacity per sprint | Explicit WIP limits |
| Best for | Product development with evolving scope | Support, maintenance and flow-based work |
Some teams blend the two, often called Scrumban, using sprints for planning and WIP limits for flow.
Choosing an approach
Ask:
- Is the work project-like with evolving scope (Scrum), or continuous and interrupt-driven (Kanban)?
- Can stakeholders give feedback regularly?
- How predictable is incoming work?
- How experienced is the team with Agile practices?
- Do you need a fixed cadence for coordination with other teams?
Start simple. Adopt the practices that solve your actual problems, then adjust.
Practical tips for any approach
- Define “done.” Agree what makes an item truly finished, including tests and review.
- Write small, clear items. Use user stories with acceptance criteria. A good PRD provides the context.
- Keep the backlog ordered and groomed, with the next items ready.
- Demo frequently to real stakeholders.
- Measure outcomes such as user impact, not just output. See which events to track.
- Run honest retrospectives and act on them.
- Protect focus. Limit interruptions and multitasking.
- Adapt for remote teams with strong written habits. See async communication.
Common mistakes
- “Agile” as an excuse for no planning or documentation
- Cargo-cult ceremonies without understanding their purpose
- Overloaded sprints and no slack
- Product Owner who is absent or lacks authority
- No WIP limits on a Kanban board
- Never changing the process after retrospectives
Checklist
- Team understands the Agile principles behind the process
- Framework chosen to match the type of work
- Clear roles and decision-making
- Ordered, well-described backlog
- Shared definition of done
- Regular demos and feedback
- Retrospectives leading to real changes
- Metrics focus on outcomes and flow
Final thoughts
Agile is about learning quickly and responding to reality. Scrum and Kanban are tools to help. Pick the one that fits, keep what works and drop what does not. When choosing external help, ask any partner how they plan, deliver and communicate. See our guide on choosing a development partner, or read how our process works.
