Agile Methodology: What It Is, How It Works, Principles & Examples

What Is Agile Methodology?

Agile methodology is an approach to project and product work that delivers results in short cycles and treats the plan as something to update, not defend. Each cycle produces something usable, such as a working feature, a campaign or a revised process, and the team uses what it learns to shape the next cycle. Applied to projects, this is usually called agile project management.

The clearest way to understand it is to compare two ways of delivering a project:

• Sequential delivery (often called Waterfall) completes one phase at a time: gather all requirements, design everything, build everything, test everything, then release. Feedback from real users arrives at the very end.
• Iterative delivery repeats a short plan-build-review cycle many times. Each pass refines the product using what the previous pass revealed.
• Incremental delivery means each cycle adds a usable slice of value. Agile combines both: the team iterates on the product while delivering it in increments.

Several ideas hold Agile together. Customers or stakeholders give continuous feedback rather than signing off once at the start. Requirements are allowed to change as the team learns more about the problem. Business people and the delivery team collaborate closely, and the team regularly reviews its own way of working to improve continuously.

Agile is best understood as a set of values and principles rather than one rigid method. Teams apply those principles through frameworks such as Scrum, Kanban, Extreme Programming (XP) and Lean, which add specific roles, events and practices. That is why you will hear about Agile "methodologies" in the plural.

Two misconceptions are worth clearing up early. Agile does not mean "no planning": Agile teams plan constantly, at the level of the product, the release and each cycle. Nor does it mean "no documentation": teams write the documents that help people build, use, support and govern the product, and skip the ones nobody reads.

Where Did Agile Methodology Come From?

In the 1990s, many software projects followed heavy, document-driven processes. Requirements were fixed early, development took months or years, and by the time software was delivered, the business need had often moved on. Several lighter approaches emerged in response, including Scrum, Extreme Programming, DSDM and Crystal.

In February 2001, 17 software practitioners who championed these approaches met in Snowbird, Utah, and wrote the Agile Manifesto, formally the Manifesto for Agile Software Development. They wanted to describe what their methods had in common: delivering working software frequently, collaborating closely with customers and adapting to change. The manifesto set out four values and twelve principles that still define Agile today. You can read the fuller story in our history of Agile.

Although Agile originated in software development, its ideas have since spread to product management, marketing, operations, HR and wider business transformation.

The 4 Core Values of the Agile Manifesto

The Agile Manifesto established four core values. Each one compares two things that both matter and states which one Agile teams prioritise when they conflict. The items on the right are not worthless; they are simply less important than the items on the left.

Individuals and Interactions Over Processes and Tools

Agile puts communication and collaboration first because most project problems are solved by people talking to each other, not by filling in the right form. Processes and tools still matter: a good backlog tool or a clear change process saves time. The point is that teams should not follow a process blindly when a conversation would solve the problem faster.

For example, a developer who is unsure what a requirement means could raise a formal change request and wait three days for a reply. In an Agile team, they walk over (or message) the product owner, agree the answer in five minutes and record the decision on the backlog item.

Working Software/Solutions Over Comprehensive Documentation

In its original software context, this value means that working software is the best evidence of progress. A 200-page specification tells you what someone intends to build; a working feature tells you what has actually been built and whether it works.

Outside software, read it as "working product" or "working solution": a campaign that is live, a process that is running, a design that users have tried. Agile prioritises usable outcomes over excessive paperwork, but it does not eliminate documentation. Documentation is still needed where it serves a purpose, for example user guides, API references, architecture decisions, compliance records, contracts and handover notes for support teams.

Customer Collaboration Over Contract Negotiation

Agile teams involve customers or their representatives throughout the work, not just at the start and the end. Requirements often evolve after work begins: customers see an early version and realise what they actually need, or the market changes. Regular collaboration catches these shifts early.

Contracts still matter, and many Agile projects run under clear commercial agreements. The difference is that the contract supports an ongoing working relationship rather than replacing it. Continuous collaboration reduces the risk of delivering, exactly to specification, something the customer no longer needs.

Responding to Change Over Following a Plan

Agile expects change. New information arrives all the time: customer feedback, a competitor's launch, a new regulation, a technical problem that makes one approach far more expensive than expected. Any of these can change what the most valuable next piece of work is.

Agile teams still create plans, often at several levels: a product vision, a roadmap, a release plan and a plan for each cycle. The difference from traditional approaches is the willingness to update those plans when conditions change, instead of treating the original plan as a promise that must be kept regardless of what the team learns.

What Are the 12 Principles of Agile?

Behind the four values sit twelve Agile principles. Rather than restating them one by one, it helps to group them by what they mean in day-to-day work. Our Agile Manifesto guide covers each principle individually.

• Satisfy the customer through early and continuous delivery. The highest priority is getting valuable results into customers' hands early and keeping them coming. In practice, teams release small improvements regularly instead of saving everything for one big launch.
• Welcome changing requirements, even late. Agile teams treat change as a chance to give the customer a competitive advantage, not as a failure of planning. They keep work in small pieces so that changing direction is cheap.
• Deliver frequently, in short timescales. Shorter cycles, from a couple of weeks to a couple of months, give more opportunities for feedback and reduce the cost of getting something wrong.
• Business people and developers work together daily. Decisions are faster and better when the people who understand the need and the people building the solution are in constant contact.
• Build projects around motivated individuals. Give people the environment and support they need, then trust them to get the job done instead of micromanaging.
• Favour face-to-face conversation. The original principle names face-to-face conversation as the most effective way to share information. For remote teams, that translates into video calls and real-time discussion over long email chains.
• Working outcomes are the primary measure of progress. A team is not 80% done because 80% of the documents exist. Progress is measured by what actually works and can be used.
• Maintain a sustainable pace. Sponsors, teams and users should be able to keep the same pace indefinitely. Repeated overtime leads to burnout, mistakes and slower delivery over time.
• Pay continuous attention to technical excellence and good design. Quality is what keeps change cheap. Messy work slows every future cycle down, a problem known in software as technical debt.
• Simplicity: maximise the work not done. The best teams deliberately avoid building features, reports and processes that nobody needs.
• Self-organising teams produce the best results. The people closest to the work decide how to do it, which is why Agile favours small, cross-functional teams with real autonomy.
• Reflect regularly and adjust. At regular intervals, the team examines how it works and makes changes. This is the principle behind the retrospective.

Taken together, the principles describe a way of working built on customer value, frequent delivery, collaboration, quality, sustainable effort, simplicity and continuous improvement. Frameworks and ceremonies are only useful to the extent that they serve these ideas.

How Does Agile Methodology Work?

The agile methodology process is a repeating cycle rather than a single linear path. A simple version of the agile lifecycle looks like this:

Plan → Prioritise → Develop → Test → Review → Gather feedback → Improve → Repeat

Each pass through the loop is short, so the team gets real feedback many times during a project. The sections below explain each stage.

Project or Product Vision

Agile still needs a clear direction. Before the first cycle, the team and stakeholders agree what problem is being solved, who the user or customer is, what outcomes would count as success and which broad priorities matter most. A good vision is short enough to remember and specific enough to say no to things. Without it, frequent change turns into drift.

Create and Prioritise the Backlog

A backlog is an ordered list of everything the team might work on to achieve the vision. Each entry is a backlog item: a feature, a task, a bug fix, an improvement or a user story (a short description of a need written from the user's point of view, such as "As a customer, I want to see my last ten transactions so that I can check my spending").

Items are ordered by business value, customer need, urgency, risk and effort, so the most valuable and urgent work sits at the top. The backlog is never finished: new ideas are added, low-value items are removed and priorities shift as the team learns. Regular backlog refinement keeps the top items small and clear enough to start. A free product backlog template is a simple way to begin.

Sprint or Iteration Planning

Iteration planning is where the team decides what it will deliver in the next cycle. It selects a manageable amount of work from the top of the backlog, based on its recent capacity, and agrees a clear goal for the cycle so that everyone knows what success looks like.

In Scrum, these cycles are called sprints and the planning event is Sprint Planning. Not every Agile framework uses fixed-length cycles, though. Kanban teams, for example, pull new work whenever capacity frees up and plan continuously instead. You can use our sprint planning template if you work in sprints.

Development and Collaboration

During the cycle, the team works through the prioritised items. Agile teams are usually cross-functional, meaning they have all the skills needed to finish the work (for example design, development, testing and content) without handing it off to other departments.

Frequent communication keeps the work moving. Team members share progress, ask for help and flag blockers, the problems stopping someone from progressing, as soon as they appear so they can be resolved quickly. Scrum teams do this in a short Daily Scrum; other teams may use a board review or ongoing chat. A daily standup is a common practice, not a requirement of Agile itself.

Testing and Quality Assurance

Agile teams test continuously rather than leaving testing to the end. Quality is built into the work: items are tested as they are built, and an item is only "done" when it meets the team's agreed quality standard, which Scrum calls the Definition of Done.

Testing early finds defects when they are small and cheap to fix, before other work is built on top of them. Software teams often automate repetitive tests so they can run them every time code changes, which makes frequent releases safer.

Review and Customer Feedback

At the end of a cycle, the team reviews completed work with stakeholders or customers. This is a working session, not a slide presentation: people see and try what has been built and say what is useful, what is missing and what has changed in the wider situation. Scrum calls this the Sprint Review.

Feedback goes straight into the backlog. New items are added, priorities change and some ideas are dropped. Validating assumptions early is one of Agile's biggest advantages: it is far cheaper to learn that customers do not want a feature after two weeks than after a year.

Retrospective and Continuous Improvement

A retrospective is a regular meeting where the team looks at how it worked, rather than what it built. It answers three simple questions:

• What worked well and should continue?
• What did not work and caused friction or waste?
• What will we change in the next cycle?

The team commits to one or two concrete improvements and checks next time whether they helped. This habit of continuous improvement is a core Agile behaviour: the process itself is never finished.

What Is a Sprint in Agile?

A sprint is a fixed-length period in which a team works to complete a set amount of work and produce a usable result. Sprints are most closely associated with Scrum, where they form the heartbeat of the framework.

Each sprint follows the same pattern:

• Sprint Goal: a single objective for the sprint that explains why the work matters and gives the team focus.
• Sprint Planning: the team agrees the goal and selects the backlog items it believes it can complete.
• Sprint backlog: the selected items plus the team's plan for delivering them, visible to everyone. See sprint backlog.
• A usable increment: by the end of the sprint, the team aims to deliver a working, tested piece of the product that meets the Definition of Done.
• Sprint Review: the team and stakeholders inspect the increment and decide what to do next.
• Sprint Retrospective: the team reviews its way of working and agrees improvements.

Agile itself does not require sprints. Sprints are a Scrum practice, and other Agile approaches such as Kanban work in a continuous flow without fixed iterations. Under the Scrum Guide, Sprints last one month or less. Many teams choose one or two weeks because it gives faster feedback, but two weeks is a common choice, not a universal Agile rule.

Popular Agile Methodologies and Frameworks

Agile is broader than any one framework. The frameworks below all apply Agile values and principles, but they differ in how much structure they prescribe. Teams often combine them, for example running Scrum with XP engineering practices and a Kanban board.

Scrum

Scrum is a lightweight framework for delivering complex work in sprints of one month or less. It defines three accountabilities: the Product Owner, who maximises the value of the product and orders the Product Backlog; the Scrum Master, who helps the team and organisation use Scrum effectively; and the Developers, who create the increment.

Scrum's artifacts are the Product Backlog, the Sprint Backlog and the Increment. Its events are the Sprint itself, Sprint Planning, the Daily Scrum (a 15-minute daily check on progress towards the Sprint Goal), the Sprint Review and the Sprint Retrospective. Scrum works well for product development where a dedicated team can deliver a usable increment every few weeks.

Kanban

The Kanban methodology manages work through visual flow. A Kanban board shows each work item as a card moving through columns that represent stages, such as To do, In progress, Review and Done. Teams set work-in-progress (WIP) limits on columns so that they finish work before starting more.

Kanban uses continuous flow instead of sprints: work is pulled into the system when there is capacity, rather than being pushed in according to a plan. It prescribes no specific roles or meetings, so teams can start with their current process and improve it gradually. Kanban is especially useful for support, operations, maintenance and any work that arrives unpredictably.

Extreme Programming (XP)

Extreme Programming is an Agile approach focused on software development and technical excellence. It is known for engineering practices such as pair programming (two developers working together at one workstation), test-driven development (writing an automated test before the code that makes it pass), continuous integration (merging and testing code changes many times a day), small and frequent releases, and close involvement of the customer.

XP is particularly relevant to engineering teams because it tackles the question many frameworks leave open: how to keep code quality high while requirements keep changing. Many Scrum and Kanban teams adopt XP practices alongside their chosen framework.

Lean

Lean thinking comes from manufacturing, especially the Toyota Production System. It aims to maximise customer value while eliminating waste: anything that consumes effort without adding value, such as waiting, handoffs, rework, unnecessary features and excessive work in progress.

Lean looks at the whole workflow from request to delivery, not just one team's part of it, and improves it continuously. Lean and Agile share many ideas, including small batches, fast feedback and respect for people, and Lean thinking strongly influenced Kanban. Learn more in Lean project management and value stream mapping.

Scrumban

Scrumban combines ideas from Scrum and Kanban. Teams typically keep Scrum's regular planning, reviews and retrospectives, but manage day-to-day work with a Kanban board, WIP limits and continuous pull rather than a fixed sprint commitment.

Teams often move towards Scrumban when their work mixes planned features with urgent requests, or when fixed sprint commitments keep being disrupted. It can also be a stepping stone for Scrum teams moving to Kanban, or the reverse.

SAFe

The Scaled Agile Framework (SAFe) is designed for coordinating Agile practices across larger organisations with many teams working on the same products. It adds structure such as Agile Release Trains (teams of teams aligned to a shared mission) and regular PI Planning events, where all teams plan the next increment together. SAFe brings more roles, coordination and governance than single-team frameworks, which suits some enterprises and feels heavy to others.

Agile vs Scrum: What's the Difference?

Agile and Scrum are often used as synonyms, but they are not the same thing. Agile is a set of values and principles for delivering work iteratively. Scrum is one specific framework that puts those values into practice, with defined roles, events and artifacts.

Scrum is one way to implement Agile. Teams can also be Agile using Kanban, XP, Lean or a hybrid approach. The main differences are in structure: Agile prescribes no roles, ceremonies or iteration length, while Scrum defines three accountabilities, five events and fixed-length sprints of one month or less.

Scrum is Agile, but Agile is not limited to Scrum.

Agile vs Waterfall

Waterfall is a sequential approach in which a project moves through fixed phases, typically requirements, design, build, test and deployment, with each phase completed before the next begins. Agile, by contrast, repeats short cycles that each include planning, building, testing and review.

The two approaches differ in almost every dimension. Waterfall plans in detail up front, while Agile plans continuously. Waterfall fixes requirements early, while Agile expects them to evolve. Waterfall tests at the end; Agile tests throughout. Waterfall delivers once, at the end; Agile delivers in increments. Waterfall manages change through formal change control, while Agile builds change into its regular cycle. Stakeholders in Waterfall projects are mostly involved at the start and the end; in Agile they are involved throughout. Waterfall offers more predictability of scope up front; Agile offers more predictability of cadence and earlier evidence of progress.

Neither approach is universally better. Each fits a different kind of project.

When Should You Use Agile Instead of Waterfall?

Agile may be more suitable when:

• Requirements are likely to change or are not fully known yet.
• Customer feedback is important to getting the product right.
• Early releases are possible and useful.
• The team needs to experiment and test ideas.
• Project uncertainty is high, technically or commercially.
• The product can be built and delivered in increments.

Waterfall may make more sense when:

• Requirements are fixed and unlikely to change.
• Deliverables are clearly defined from the start.
• Sequential approval is required at each stage.
• Changes are extremely costly once work has started, as in many physical construction projects.
• Regulatory or contractual requirements demand extensive upfront planning and documentation.

Many organisations use a hybrid: predictive planning for fixed elements such as contracts, budgets and regulatory milestones, and Agile delivery for the parts where learning matters most.

Benefits of Agile Methodology

The agile methodology benefits below are real, but they depend on how well Agile is implemented. Agile does not guarantee faster projects, lower costs or better results on its own.

• Greater adaptability. Because work is planned in short cycles, the team can change direction without throwing away months of effort.
• Faster response to changing requirements. New priorities go into the backlog and can be picked up in the next cycle rather than waiting for a formal re-plan.
• Earlier delivery of usable value. Customers can start using the most important features before the whole product is finished.
• More frequent customer feedback. Every review is a chance to check that the product still meets real needs.
• Better stakeholder visibility. Boards, backlogs and regular reviews make progress and problems visible to everyone, not just the project manager.
• Better prioritisation. An ordered backlog forces explicit decisions about what matters most, so the most valuable work is done first.
• Earlier identification of problems. Technical issues, misunderstandings and quality problems surface within weeks, when they are cheaper to fix.
• Continuous improvement. Retrospectives give the team a regular, structured way to fix its own process.
• Improved collaboration. Cross-functional teams and close contact with the business reduce handoffs and misunderstandings.
• Reduced risk of building the wrong thing. Frequent feedback means the team learns early if a feature misses the mark.
• Testing assumptions earlier. Teams can release a small version of an idea, measure the response and decide whether to invest further.

These benefits appear when teams deliver genuinely usable increments, stakeholders take part in reviews and leaders act on what the team learns.

Disadvantages and Challenges of Agile

Agile also has real limitations, and most failed Agile adoptions run into several of them:

• Scope creep. Welcoming change can turn into accepting every request. Without a clear vision and firm prioritisation, the backlog grows endlessly. See scope creep.
• Constantly changing priorities. If priorities change mid-cycle every few days, teams lose focus and finish very little.
• Difficult cost and timeline estimates. When scope is expected to change, it is harder to promise a final date and budget for everything at the start.
• Heavy dependence on communication. Agile replaces some documentation with conversation, so poor communication hurts more than it would in a document-driven process.
• Need for regular stakeholder participation. Reviews only work if customers or their representatives turn up and give honest feedback.
• Documentation gaps. Poorly implemented Agile can leave support teams, auditors and new joiners without the information they need.
• Scaling difficulties. Coordinating many teams working on one product adds dependencies and overhead.
• Team dependency. Small, self-organising teams rely heavily on a few people; losing one can slow delivery significantly.
• Meeting and ceremony overload. Too many or badly run meetings eat into time for actual work.
• Unclear roles. If nobody owns priorities, or the Scrum Master is just a renamed project manager, decisions stall.
• Highly regulated or fixed-scope environments. Where every change needs formal approval, the Agile feedback loop is much harder to run.

A particular risk is Agile theatre: an organisation runs standups, sprints and retrospectives and uses all the Agile vocabulary, while decisions are still made top-down, plans are fixed in advance and feedback is ignored. Adopting the ceremonies does not make an organisation Agile. What matters is whether the team delivers usable work frequently, whether feedback actually changes the plan, and whether the people doing the work have the authority to improve how they work.

Example of Agile Methodology

Imagine a bank building a new mobile banking app. Instead of specifying every feature and launching after 18 months, the team delivers in iterations, each a few weeks long. This is one of the most common agile methodology examples.

• Iteration 1: Login and account dashboard. The team builds secure login and a simple dashboard showing the customer's accounts. It tests login security, performance and accessibility. A small group of staff and invited customers try it, and their feedback shows that biometric login matters more than expected, so that item moves up the backlog.
• Iteration 2: Balance and transaction history. The team adds balances and a searchable list of recent transactions. Testing covers data accuracy against the core banking system. Beta users say they want to filter by category, so a filtering item is added, while a planned "spending insights" feature is pushed down.
• Iteration 3: Money transfers. The team builds transfers between the customer's own accounts and to saved payees, with strong testing of limits, error handling and fraud checks. Feedback reveals that adding a new payee is confusing, so the next cycle includes a redesign of that step.
• Iteration 4: Bill payments. The team adds bill payments and scheduled payments. Usage data from the beta shows that most customers pay the same few bills each month, so the team prioritises a "pay again" shortcut over a full bill-management module.
• Iteration 5: Improvements based on customer feedback. The team uses everything it has learned to polish the app: it improves the payee flow, adds transaction filters and fixes the most-reported usability issues before a wider release.

At every step, the bank has a working, tested product that real people can try. Incremental delivery reduces risk because each assumption, such as "customers want spending insights", is tested on a small scale before the bank invests heavily in it. If the market or regulations change, the next iteration can change with them.

Agile Methodology Beyond Software Development

Agile principles work outside software wherever work is uncertain and feedback is available. Our guide is Agile only for software? covers this in detail. A few examples:

• Product management: product managers use a backlog and short release cycles to test features with real users before investing in them.
• Marketing: a marketing team runs two-week campaign experiments, reviews performance data and adjusts the next campaign based on results. See Agile marketing.
• Operations: IT and operations teams use Kanban boards and WIP limits to manage incoming requests and reduce bottlenecks. See Agile in IT operations.
• HR: HR teams deliver programmes such as onboarding or performance reviews in small pilots, gather feedback from employees and refine them.
• Design: design teams test prototypes with users early and iterate before final designs are produced.
• Customer experience: CX teams make small improvements to a journey, measure satisfaction and decide what to change next.
• Business transformation: large change programmes deliver in stages, with regular reviews of what is working, rather than one big launch. See Agile transformation.

Not every software-specific practice applies directly to other departments. Test-driven development or continuous integration may have no equivalent in an HR team, for example. What transfers well are the underlying ideas: small batches, visible work, frequent feedback and regular reflection.

When Should You Use Agile Methodology?

Agile tends to suit projects with these characteristics:

• Uncertain or changing requirements, where nobody can specify the full solution up front.
• A need for frequent feedback from customers or users.
• Complex problems where the best approach only becomes clear by trying things.
• Work that can be delivered incrementally, so each cycle produces something usable.
• Cross-functional teams with the skills to deliver end to end.
• A need for experimentation, such as testing new products or channels.
• Customer-driven products whose success depends on user adoption.
• Rapidly changing markets where waiting a year to launch is a risk in itself.

When Agile May Not Be the Best Choice

Agile is not the right fit for every project. It may be a poor choice when:

• Requirements are highly fixed and well understood.
• The work has strict sequential dependencies, so little can be delivered in parallel or in increments.
• Customers or stakeholders are not available to give regular feedback.
• Changes are extremely expensive once work has started.
• The project requires extensive regulatory approval before any work can begin.
• Teams lack the autonomy to make decisions about how they work.
• Delivering in increments provides little value, for example a one-off event that only matters on the day.

In these situations a hybrid approach, combining upfront planning for fixed elements with Agile delivery where uncertainty is highest, is often more appropriate than choosing one approach exclusively.

How to Implement Agile Methodology

Adopting Agile works best as a gradual, evidence-led change. Organisations should not start by copying ceremonies. They should first understand why they are adopting Agile and what problem it is meant to solve. A practical sequence:

1. Define the problem Agile is intended to solve. For example: slow delivery, products that miss customer needs, or poor visibility of progress.
2. Identify customer and business outcomes. Decide what better looks like, such as shorter time to first release or higher customer satisfaction.
3. Choose a pilot project or team. Start with one team and one meaningful piece of work rather than the whole organisation.
4. Select an appropriate Agile framework. Scrum suits planned product work; Kanban suits continuous, unpredictable work; Scrumban suits a mix.
5. Define roles and responsibilities. Make clear who owns priorities, who facilitates and who delivers. See Scrum team roles and Agile team structures.
6. Build and prioritise the backlog. Write the work as small, valuable items and order them.
7. Work in small increments. Aim to finish usable pieces every cycle, not partially complete large ones.
8. Create a regular feedback loop. Schedule reviews with real customers or stakeholders.
9. Review outcomes frequently. Check progress against the outcomes you defined, not just activity.
10. Hold retrospectives. Give the team regular time to examine and improve its process.
11. Improve the process based on evidence. Change one or two things at a time and check whether they helped.
12. Scale gradually if the approach works. Extend to more teams once the pilot has shown results, using a scaling approach only when coordination genuinely requires it.

Our step-by-step guide on how to implement Agile goes further, and the free Agile project plan template helps you plan a first release.

Key Agile Metrics

Agile metrics help teams spot bottlenecks, improve predictability and check that they are delivering value. They should be used to improve the system of work, not as simplistic scores of individual performance.

Velocity

Velocity is the amount of work, often measured in story points, that a team completes in a sprint. It is mostly useful within the same team, to forecast how much it can take on in future sprints. It should not be used to compare teams or to measure individual productivity, because every team estimates differently.

Cycle Time

Cycle time is the time from when work on an item starts to when it is completed. Shorter, more predictable cycle times usually mean smaller items and fewer blockers.

Lead Time

Lead time is the time from when a request is made to when it is delivered. It reflects the customer's experience, including the time an item waits in the backlog.

Throughput

Throughput is the number of work items completed in a given period, such as a week. It is a simple, useful measure of delivery rate, especially for Kanban teams.

Work in Progress

Work in progress (WIP) is the number of items currently being worked on. Too much WIP slows everything down because people switch between tasks and items wait for each other. Limiting it is one of the most effective ways to speed up flow.

Sprint Burndown

A sprint burndown chart shows how much work remains in a sprint, day by day. It helps the team see early whether it is on track to meet the Sprint Goal.

Defect Rate

The defect rate is the number or rate of quality problems found, either before release or by customers. A rising defect rate is a warning that the team is moving faster than its quality practices can support.

Customer Satisfaction

Customer satisfaction shows whether delivered work creates real value. It can be measured through surveys, product usage, support requests or direct feedback in reviews. A team can hit every delivery metric and still fail if customers do not find the work useful.

Frequently asked questions