🚀
DeliveryDeliver early and continuously
Small, frequent releases beat one large release at the end. It shortens the feedback loop and reduces the cost of being wrong.
How the frameworks relate, the terminology, and when to use each
Agile, Scrum, Kanban, and SAFe get used interchangeably in a lot of meetings, and that's where the confusion starts. They are not four competing options, they are four different levels of the same idea: Agile is the philosophy, Scrum and Kanban are ways a single team actually works day to day, and SAFe is how that same thinking gets coordinated across many teams at once. This handbook lays out what each one actually is, how they fit together, and which one to reach for depending on the kind of work in front of you.
Agile is not a framework, it does not have roles or ceremonies of its own, and nobody "does Agile" the way they "do Scrum." Agile is a set of values and principles from the 2001 Agile Manifesto that everything else in this handbook is built on top of. Scrum, Kanban, and SAFe are all specific ways of putting Agile thinking into practice.
| Value over | Value emphasized | What it means in practice |
|---|---|---|
| Processes and tools | Individuals and interactions | A working relationship between people beats a perfectly documented process nobody follows |
| Comprehensive documentation | Working software | A shippable increment proves progress more than a stack of specs does |
| Contract negotiation | Customer collaboration | Ongoing conversation with the people who use the thing beats a fixed contract nobody revisits |
| Following a plan | Responding to change | A plan is a starting point, not a contract with reality |
The Manifesto doesn't say the item on the left has no value, it says the item on the right matters more when the two are in tension.
Small, frequent releases beat one large release at the end. It shortens the feedback loop and reduces the cost of being wrong.
Not a weekly status meeting; ongoing, direct contact between the people building the thing and the people who need it.
Agile processes treat change as a competitive advantage, not a failure of planning.
At set intervals, the team looks at how it's working and tunes its own behavior. This is where the retrospective comes from.
Any team or organization that wants to be more adaptable and deliver value iteratively can apply Agile thinking, regardless of which specific framework it picks to execute on it. That's the layer everything below sits on.
Scrum is an Agile framework that organizes work into fixed-length iterations called Sprints, usually one to four weeks, with a defined set of roles, events, and artifacts that repeat every cycle. It's the most widely adopted Agile framework for a reason: it gives a team a concrete, repeatable rhythm instead of leaving "how do we work" undefined.
| Role | Owns |
|---|---|
| Product Owner | The Product Backlog: what gets built and in what order, based on value |
| Scrum Master | The process itself: removes blockers, protects the team from disruption, coaches Scrum practice |
| Developers | The Sprint Backlog and the actual work of turning backlog items into a done increment |
The full, ordered list of everything that might be needed in the product, owned and continually reprioritized by the Product Owner.
The subset of backlog items the team committed to for this sprint, plus the plan for delivering them.
The sum of everything completed during the sprint, meeting the team's Definition of Done, potentially shippable.
Teams with reasonably clear objectives whose work can be planned and broken down into iterations. It struggles more with highly reactive, unpredictable work where priorities shift daily, that's Kanban's strength instead.
Kanban is a method for managing work as a continuous flow instead of fixed-length iterations. There are no Sprints in Kanban; work moves through a visualized board one item at a time, and the team's main job is to keep that flow moving smoothly rather than to fill a time-boxed commitment.
Every item, wherever it is in the process, is represented on the board so the whole team can see the real state of work at a glance.
Each column gets a cap on how many items can sit in it at once, which forces the team to finish work instead of starting more of it.
The team actively watches for where items get stuck and works to smooth that flow rather than just tracking status.
The rules for moving an item between columns, what "ready" and "done" mean, are written down, not left to individual judgment.
Kanban has no built-in retrospective the way Scrum does, so teams typically add a regular review cadence on top of it.
If the In Progress limit is 4, a fifth item cannot start until one of the current four moves forward or is pulled back out.
Teams with continuous, unpredictable work and a steady stream of incoming requests: support queues, operations, DevOps. Anywhere priorities can genuinely change mid-week and forcing that work into a fixed sprint commitment would just mean replanning constantly.
SAFe (Scaled Agile Framework) coordinates multiple Agile teams, each of which can still run Scrum or Kanban internally, so they stay aligned to the same strategic objectives. It exists because Agile at the level of one team doesn't automatically solve the problem of ten or fifty teams building interdependent pieces of the same system.
| Concept | What it is |
|---|---|
| Agile Release Train (ART) | A long-lived team of Agile teams, typically 5 to 12 teams, aligned to a shared mission and cadence |
| PI Planning (Program Increment Planning) | A recurring, in-person or virtual event where every team on the ART plans a Program Increment together, usually 8 to 12 weeks of work |
| Program Increment (PI) | The scaled equivalent of a sprint, a fixed timebox made up of several team-level sprints underneath it |
| Roles at scale | Release Train Engineer (coordinates the ART, like a Scrum Master for the whole train), Product Management, System Architect |
| Alignment | Every team's backlog traces back to the same business strategy, so priorities don't drift independently team by team |
Large organizations running many teams that work on related systems and need those teams pulling in the same direction. It's a heavier framework by design, and it's overkill for a single team or a small department, it earns its complexity at real scale.
The confusion mostly comes from treating these as competing choices. They actually sit at different altitudes, and understanding that hierarchy clears up most of the terminology arguments.
Teams choose whichever of Scrum or Kanban fits how their work actually arrives; SAFe sits above both and coordinates several teams regardless of which one each has chosen.
It's a set of values, not a process you can point to on a board.
Both are concrete ways of applying Agile values day to day, picked based on how predictable the work is.
It doesn't replace Scrum or Kanban at the team level, it coordinates teams that are already running one of them.
Deliver value, improve continuously, and adapt to change, just at different organizational altitudes.
Each framework has its own rhythm. Knowing what happens, how often, and why it exists keeps a mixed-framework organization from confusing "we don't have that ceremony" with "we're not doing this right."
| Event | Cadence | Purpose |
|---|---|---|
| Sprint Planning | Start of every sprint | Define the sprint goal and select backlog items to commit to |
| Daily Scrum | Daily, 15 minutes | Sync progress and surface blockers, not a status report to the Scrum Master |
| Sprint Review | End of every sprint | Demo the increment to stakeholders and gather feedback |
| Retrospective | End of every sprint, after the review | The team inspects its own process and agrees on one or two concrete improvements |
| Backlog Refinement | Ongoing, not a fixed event | Keep upcoming backlog items estimated, clear, and ready to pull into a future sprint |
| Cadence | Frequency | Purpose |
|---|---|---|
| Replenishment meeting | As needed, often weekly | Pull new items into the Ready column when capacity allows |
| Standup | Daily | Walk the board right to left, focus on what's closest to done and what's stuck |
| Service delivery review | Periodic | Review flow metrics: cycle time, throughput, aging items |
| Operations review | Periodic | Look across multiple Kanban boards or teams for systemic bottlenecks |
| Cadence | Frequency | Purpose |
|---|---|---|
| PI Planning | Every Program Increment, roughly every 8 to 12 weeks | All teams on the ART plan the next PI together and surface cross-team dependencies |
| Scrum of Scrums | Weekly or more | Representatives from each team coordinate dependencies and blockers across the ART |
| System Demo | End of each iteration | Integrated demo of what all teams on the ART built together, not just one team's slice |
| Inspect & Adapt | End of each PI | ART-level retrospective: review metrics, demo, and problem-solve systemic issues |
The numbers worth tracking in each framework, and the fastest fix when a metric signals trouble.
Story points completed per sprint. Useful for forecasting, dangerous if used to compare teams against each other, velocity is team-relative, not a universal unit.
Remaining work in the sprint plotted against time. A flat line partway through the sprint is an early warning sign, not something to wait out.
How long an item takes from "in progress" to "done." The core health metric for flow-based work, shorter and more consistent is better than fast-but-erratic.
How many items finish per week or per month. Pairs with cycle time to forecast delivery without needing story-point estimation at all.
Stacked area chart of items per column over time. A widening band means work is piling up in that stage faster than it's being cleared.
How closely the ART's actual PI output matched its planned business value. Tracked at the Inspect & Adapt event, not per team.
| Warning sign | Fastest first move |
|---|---|
| Velocity swings wildly sprint to sprint | Check whether story sizing is consistent; re-baseline estimation with the team, don't chase the number itself |
| Cycle time creeping up on a Kanban board | Look at the column with the most aging items first, that's almost always where the bottleneck actually is |
| WIP limit constantly overridden | Either the limit is set wrong for real capacity, or the team is starting new work to avoid finishing hard items, address the real cause directly |
| Sprint goal missed two sprints in a row | Reduce sprint commitment size before adding process; overcommitment is the most common root cause |
| PI Planning surfaces the same cross-team dependency every cycle | Escalate it as a structural issue at Inspect & Adapt instead of re-solving it manually every PI |
A practical decision guide for picking the right framework for the work in front of the team, and the professional upside of understanding all four.
| Approach | Best fit |
|---|---|
| Scrum | Projects with defined objectives and incremental deliverables that can be planned in advance |
| Kanban | Continuous, unpredictable work with a steady, unplanned arrival of new items: support, operations, DevOps |
| SAFe | Many teams with real dependencies, needing coordination and shared direction across the organization |
Knowing why a ceremony exists makes it easier to see how team-level work ladders up to organizational goals.
Reading a burndown chart, a Kanban board, or a PI plan correctly means spotting risk before it becomes a missed deadline.
Picking the wrong framework for the type of work, forcing unpredictable support work into rigid sprints, for example, is a common source of avoidable churn.
Comfort moving between Scrum, Kanban, and scaled frameworks like SAFe is directly useful across IT operations, engineering, and program management roles.
Official guides and communities for going deeper on any framework covered in this handbook.
Vendor-neutral overview of Agile concepts alongside Azure DevOps and Azure Boards implementation guidance.
Open ↗The official source for SAFe, covering PI Planning, Agile Release Trains, and every role at scale.
Open ↗The current official Kanban Guide, maintained alongside the Scrum Guide by the same stewards.
Open ↗The Agile Manifesto, its twelve principles, and a large library of practitioner resources.
Open ↗The official, short definition of Scrum from its creators, Ken Schwaber and Jeff Sutherland.
Open ↗Professional Scrum training and assessments, plus a strong set of free articles on applying Scrum in practice.
Open ↗