Agile is a mindset; Scrum is a framework that puts it into practice. Agile is the set of values and principles for building software in small, iterative steps with constant feedback. Scrum is the most popular framework for doing Agile — it gives you fixed-length cycles called sprints, three clear roles, five recurring events, and a few simple artifacts. If you are a founder, product owner, or engineering leader choosing how to run a software project, the practical takeaway is this: adopt the Agile mindset, then pick a framework (usually Scrum or Kanban) that fits your work.
This guide explains Agile and Scrum as they are actually practised in 2026 — including how distributed and offshore teams run sprints, where teams go wrong, and how AI-assisted delivery is compressing cycles from months into days and weeks. At MicroPyramid we have shipped 50+ products over 12+ years running exactly these ceremonies with clients across the US, UK, Europe, Australia, and Singapore, so the advice here is grounded in delivery, not theory.
Agile vs Scrum: the clear distinction
People use "Agile" and "Scrum" interchangeably, but they sit at different levels.
- Agile is a philosophy defined by the 2001 Manifesto for Agile Software Development — four values and twelve principles. It says nothing about sprints, stand-ups, or story points. It is about how you think: favour working software, customer collaboration, and responding to change over rigid plans.
- Scrum is a concrete framework that operationalises Agile. It defines specific roles, time-boxed events, and artifacts. It is opinionated and prescriptive where Agile is deliberately abstract.
Other frameworks also implement Agile — Kanban, Extreme Programming (XP), Lean, and scaling models such as SAFe and LeSS. Scrum is simply the most widely adopted.
| Agile (the mindset) | Scrum (a framework) | |
|---|---|---|
| What it is | Values & principles | A defined process |
| Source | Agile Manifesto (2001) | The Scrum Guide (latest revision 2020) |
| Prescribes roles? | No | Yes — PO, Scrum Master, Developers |
| Prescribes events? | No | Yes — Sprint, Planning, Daily, Review, Retro |
| Time-boxed? | Not required | Yes — fixed-length sprints |
| Think of it as | The "why" and "what" | The "how" |
Bottom line: you can be Agile without Scrum, but you cannot do Scrum without being Agile. Choose the mindset first, then the framework.
The three Scrum roles (accountabilities)
The 2020 Scrum Guide calls these "accountabilities" rather than roles, and there is exactly one Scrum Team made of three parts — no separate "QA team" or "management" layer inside it.
Product Owner (PO)
Owns the what and the why. The PO maximises the value the team delivers by owning and ordering the Product Backlog, articulating the product vision, and making the final call on priorities. The PO is a single, empowered person — not a committee — and is the team's main link to customers and stakeholders.
Scrum Master
A servant-leader and coach, not a project manager. The Scrum Master removes impediments, protects the team from disruption, facilitates the events, and coaches the organisation on Scrum. They own the effectiveness of the process, not the assignment of tasks.
Developers
The people who do the work of building the Increment — engineers, QA, designers, architects, analysts. In modern Scrum the term "Developers" covers everyone who builds the product, and the team is cross-functional (it has all the skills needed to deliver) and self-managing (it decides how to do the work). A healthy size is around 10 people or fewer.
The five Scrum events
Scrum runs on a heartbeat of recurring, time-boxed events. The Sprint is the container; the other four happen inside it.
The Sprint
A fixed-length cycle — typically one to four weeks, with two weeks being the most common in practice. The Sprint is the container for all other events. Its length is constant so the team can build a reliable rhythm and forecast. A new Sprint starts immediately after the previous one ends.
Sprint Planning
Held at the start of each Sprint. The team answers three questions: why is this Sprint valuable (the Sprint Goal), what can be delivered, and how will the work get done. The output is the Sprint Backlog.
Daily Scrum (stand-up)
A 15-minute daily sync for the Developers to inspect progress toward the Sprint Goal and re-plan the day. It is not a status report to a manager — it is the team coordinating with itself.
Sprint Review
Held at the end of the Sprint. The team demonstrates the working Increment to stakeholders and gathers feedback. This is a working session that may adjust the Product Backlog, not a one-way demo.
Sprint Retrospective
The last event of the Sprint. The team inspects how it worked — people, process, tools — and commits to concrete improvements for the next Sprint. Skipping retros is the fastest way to stop improving.
Backlog Refinement (grooming) is an ongoing activity, not a formal event — the team continuously splits, clarifies, estimates, and re-orders upcoming backlog items so future Sprint Planning is fast.
Scrum artifacts and "Done"
Scrum has three artifacts, each with a commitment that gives it transparency.
| Artifact | What it is | Its commitment |
|---|---|---|
| Product Backlog | The single, ordered list of everything that might be built | Product Goal |
| Sprint Backlog | What the team plans to deliver this Sprint + the plan to do it | Sprint Goal |
| Increment | The usable, working output of the Sprint | Definition of Done |
The Definition of Done is a shared, explicit checklist of what "finished" means — code reviewed, tested, documented, deployable. Work that does not meet it is simply not done. A clear Definition of Done is one of the highest-leverage things a team can agree on, because it kills the "90% complete forever" problem.
User stories
Backlog items are usually written as user stories — short descriptions of a need from the user's point of view, in the form "As a [user], I want [goal] so that [benefit]." Good stories follow the INVEST check (Independent, Negotiable, Valuable, Estimable, Small, Testable) and carry acceptance criteria that define when they pass.
Estimation: story points and velocity
Agile teams estimate relative effort, not hours.
- Story points rate the size of an item relative to others, factoring in complexity, effort, and uncertainty — often using a Fibonacci-like scale (1, 2, 3, 5, 8, 13). They deliberately avoid implying precise hours, which humans estimate badly.
- Planning Poker is a common technique where the team estimates simultaneously to surface differing assumptions before committing to a number.
- Velocity is the average number of story points a team completes per Sprint. After a few Sprints it becomes a forecasting tool — not a productivity target. Velocity is a planning aid for one team and should never be used to compare teams or as a stick to push for more output (that just inflates estimates).
A modern, healthier complement is to also track cycle time (how long an item takes from start to done) and throughput, which are harder to game than points.
Scrum vs Kanban vs Scrumban vs Waterfall
The honest answer to "which methodology?" is it depends on how predictable and how changeable your work is. Use this to decide.
| Waterfall | Scrum | Kanban | Scrumban | |
|---|---|---|---|---|
| Cadence | One long phase-gated plan | Fixed sprints (1–4 wks) | Continuous flow | Flow + light cadence |
| Roles | PM, analysts, devs, QA (siloed) | PO, Scrum Master, Developers | No mandated roles | Flexible |
| Change handling | Costly, change-controlled | Welcomed between sprints | Welcomed anytime | Welcomed anytime |
| Planning | All upfront | Per sprint | Just-in-time, pull-based | Replenish on demand |
| Key metric | % of plan complete | Velocity | Cycle time / WIP limits | Cycle time |
| Best for | Fixed scope, heavy compliance, stable requirements | Evolving products, feature delivery | Support, ops, steady streams of varied work | Maturing Scrum teams or mixed product + support |
- Scrum suits product and feature development where requirements evolve and a regular cadence helps.
- Kanban suits maintenance, support, and operations — continuous flow with work-in-progress (WIP) limits and no fixed sprints.
- Scrumban blends Scrum's structure with Kanban's pull-based flow; a good landing spot for teams that find sprint commitments too rigid but still want cadence.
- Waterfall still has a place for genuinely fixed-scope, heavily regulated work where the cost of late change is extreme.
Many teams run a hybrid in real life — Scrum for the product roadmap and a Kanban board for incoming bugs and support — and that is perfectly legitimate.
Common pitfalls and anti-patterns
Most "Agile failures" are not Agile failing — they are Scrum being misapplied. Watch for these:
- Mechanical Scrum ("zombie Scrum"). Running every ceremony but ignoring the values — feedback never changes the plan. The events become rituals with no learning.
- The Daily Scrum as a status meeting. When the stand-up becomes a report to a manager, the team stops coordinating and starts performing.
- A Product Owner who can't decide. A PO without real authority, or one who is unavailable, stalls the whole team. Priorities must be owned by one empowered person.
- No Definition of Done. Without it, "done" is negotiable and quality erodes invisibly.
- Treating velocity as a KPI. Push for higher velocity and you get inflated estimates, not more value.
- Skipping retrospectives. Drop the one event whose entire purpose is improvement and the team stops getting better.
- Over-committing each sprint. Consistently pulling in more than the team can finish destroys trust in the forecast and burns people out.
- "Mini-waterfall" sprints. Cramming analyse → build → test sequentially into a sprint so testing always slips to the last day. Integrate and test continuously instead.
- Scaling too early. Reaching for SAFe or LeSS before a single team is healthy multiplies the dysfunction.
How Agile works with distributed and offshore teams
Scrum was written for co-located teams, but in 2026 most delivery is distributed — across cities, countries, and time zones. It works well when you adapt the practices deliberately rather than copy them blindly.
- Anchor on a shared overlap window. Even a few hours of overlap is enough to run the Daily Scrum, Planning, Review, and Retro live. We schedule core ceremonies inside that window and let focused build work happen asynchronously around it.
- Make work visible by default. A shared backlog and board (Jira, Linear, GitHub/GitLab Projects) becomes the single source of truth so no one depends on hallway conversations.
- Lean into async. Recorded demos, written stand-up updates, and clear acceptance criteria let work continue across time zones — and a well-managed time difference becomes a feature: hand off at end of your day, wake up to progress.
- Over-invest in the Definition of Done and acceptance criteria. Distributed teams cannot lean on a tap-on-the-shoulder, so written clarity matters more.
This is exactly how MicroPyramid runs delivery for clients overseas: a fixed sprint cadence, ceremonies in the overlap window, everything tracked on a shared board, and continuous delivery so stakeholders see working software every sprint rather than a big reveal at the end. It is the same approach we describe in our guide to choosing a custom software development partner.
The reality: AI-assisted Agile delivery
Agile's core loop — build a small slice, get feedback, adjust — has not changed. What has changed is how fast each loop can turn.
AI now sits inside the day-to-day of a well-run team: AI coding assistants accelerate implementation and refactoring, AI-generated tests and reviews tighten the Definition of Done, and AI helps draft user stories, summarise retrospectives, and triage backlogs. The effect is shorter sprints and faster increments — work that used to take weeks or months can now ship in days to weeks, which means more feedback cycles and a higher return on each one.
Two cautions keep this honest:
- AI speeds execution, not judgement. It does not replace a clear Product Goal, a decisive Product Owner, or a real Definition of Done. Pointed at a vague backlog, AI just produces the wrong thing faster.
- Quality gates matter more, not less. When code is generated quickly, automated tests, code review, and a strong Definition of Done are what keep the Increment genuinely shippable. (See our take on why testing before delivery matters.)
At MicroPyramid we fold AI into the same Scrum cadence our clients already understand — the ceremonies and accountabilities stay; the cycle time drops. Agile and Scrum also sit inside the wider software development lifecycle, and we apply them across web and Django builds alike.
Frequently Asked Questions
What's the difference between Agile and Scrum?
Agile is a mindset — the values and principles in the 2001 Agile Manifesto for building software iteratively with constant feedback. Scrum is a specific framework that implements that mindset, with defined roles, time-boxed sprints, and a few artifacts. In short: Agile is the why and what; Scrum is one popular how. You can be Agile without Scrum, but Scrum only works if you embrace the Agile mindset.
How long should a sprint be?
Sprints are fixed-length cycles of one to four weeks, and two weeks is the most common choice. Shorter sprints give faster feedback but more ceremony overhead; longer sprints reduce overhead but slow learning. The key rule is to keep the length constant so the team builds a reliable rhythm and can forecast with velocity.
Scrum vs Kanban — which should we use?
Use Scrum for product and feature development where requirements evolve and a regular cadence helps you plan and demo. Use Kanban for support, maintenance, and operations — a continuous flow of varied work managed with WIP limits and no fixed sprints. Many teams sensibly run both: Scrum for the roadmap, Kanban for incoming bugs. Scrumban is a good middle ground when sprint commitments feel too rigid.
Does Agile work for fixed-scope, fixed-budget projects?
Yes, with the right framing. Pure Waterfall suits genuinely fixed scope, but most "fixed" projects still benefit from iterative delivery. A common pattern is a short discovery sprint to define and estimate the work, then fixed-cadence sprints to build it with regular demos — so you get Agile's visibility and quality while still committing to an outcome. The scope is fixed; how you reach it stays adaptive.
How does Agile work with an offshore or distributed team?
Very well, when adapted deliberately. Anchor the live ceremonies (Daily, Planning, Review, Retro) in a shared overlap window, make all work visible on a shared backlog and board, lean on async updates and recorded demos, and over-invest in written acceptance criteria and a clear Definition of Done. A managed time difference even becomes an advantage — work hands off at the end of one team's day and progresses overnight. This is how MicroPyramid runs sprints for clients across the US, UK, Europe, Australia, and Singapore.
What are story points and velocity?
Story points estimate the relative size of a backlog item — its complexity, effort, and uncertainty — rather than exact hours, because relative sizing is more reliable than time estimates. Velocity is the average points a team completes per sprint and is used for forecasting that team's future capacity. Velocity is a planning aid, never a productivity target or a way to compare teams — using it that way just inflates estimates.
Who does what in a Scrum team?
There are three accountabilities. The Product Owner owns the what and why — the prioritised backlog and product vision. The Scrum Master is a coach who removes blockers and protects the process — not a task assigner. The Developers are everyone who builds the Increment (engineers, QA, designers), working as one cross-functional, self-managing team of roughly ten or fewer.