The 12 Agile Principles

Behind the four values of the Agile Manifesto sit twelve principles. They are the practical part: what Agile teams actually try to do. Here they are in plain words, each with an example of what it looks like in a real team.

8 min read·Updated 4 October 2026

The four values

The principles grew from four values, which the Manifesto states in four short pairs:

The authors add that the items on the right still have value; the items on the left are valued more. What each value means in practice.

Value for customers

• 1
  Principle 1: Put useful software in customers’ hands early, and keep doing it.In practice: Release a simple first version of checkout in the second sprint, instead of the complete one in month six.
• 2
  Principle 2: Treat a change of direction as new information, even late on. It can give customers an edge.In practice: A competitor launches a cheaper plan; the Product Owner moves the pricing work to the top, and the team picks it up next sprint.
• 3
  Principle 3: Ship working software on a short, steady rhythm. Every couple of weeks beats every couple of months.In practice: Two-week sprints, each ending with an increment that could be released.

People and collaboration

• 4
  Principle 4: Day after day, the builders and the people with business knowledge solve problems side by side.In practice: The Product Owner joins refinement and answers questions on work items the same day.
• 5
  Principle 5: Form teams of people who care about the work, back them with what they ask for, and let them decide how to do it.In practice: The team decides how to build a feature; the manager’s job is to clear the blockers it raises.
• 6
  Principle 6: When people need to understand each other, a real conversation beats a long document or a chain of messages.In practice: A ten-minute call instead of a thirty-message thread, with the decision written on the work item afterwards.

Progress and pace

• 7
  Principle 7: Measure progress by what works, not by what has been written or started.In practice: A story counts when it meets the Definition of Done, not when it is “90% done”.
• 8
  Principle 8: Plan for a rhythm the whole group could hold month after month, not a sprint to burnout followed by a crash.In practice: Plan each sprint from the team’s capacity and recent velocity, not from overtime.

Quality and simplicity

• 9
  Principle 9: Steady attention to good engineering and good design makes it easier to change course.In practice: Tests and refactoring are part of the Definition of Done, not a separate “clean-up sprint”.
• 10
  Principle 10: Keep it simple: the work you do not need to do is the cheapest work of all.In practice: Usage shows nobody exports reports to PDF, so the team drops the PDF export story.

Teams that improve

• 11
  Principle 11: Teams left to organise their own work tend to produce better designs and plans than teams directed from outside.In practice: At Sprint Planning the Developers split the work into tasks and choose who does what.
• 12
  Principle 12: Stop regularly to look at how the team works, then change something.In practice: Every retrospective ends with one or two action items with an owner, checked at the next one.

Using the principles

The principles are most useful as questions. At your next retrospective, pick one and ask: where did we live up to this in the last sprint, and where didn’t we? Then choose one small change to try.