Creating an Agile Glossary: The Unsung Hero of Clear Communication

Someone says a feature is “done”. A developer means the code is written. A tester means the checks have passed. A stakeholder assumes customers can already use it. Everyone leaves the meeting with a different expectation.

A project glossary gives your team a shared place to explain the words it uses. It can include delivery terms, technical abbreviations and business language. The aim is to make everyday conversations clearer and decisions easier to follow.

This guide shows you what to include, how to agree useful definitions and how to keep a glossary relevant without creating another document nobody opens.

Why shared language matters

Agile is an approach shaped by values and principles, rather than a single method everyone follows identically. The Agile Manifesto values collaboration and responding to change. A small, useful glossary can support those conversations, provided the team actually uses it.

Scrum is one framework used by Agile teams. Its terms have defined meanings, while other expressions may be specific to your product or organisation. A glossary should make that distinction visible.

Clearer requirements: people can check what a word means before building or testing something.
Easier onboarding: a new colleague has a starting point for unfamiliar language.
More useful discussions: the team can spot a difference in interpretation before debating a solution.
More accessible participation: people can contribute without having to guess what an abbreviation stands for.

A glossary cannot resolve every disagreement. It can help you discover whether people are disagreeing about the work itself or using the same word for different things. You still need a conversation and, where necessary, a decision.

What belongs in your glossary?

Start with language that affects how people understand the work. You do not need to catalogue every word used in technology.

Framework terms: Sprint, Product Backlog, Sprint Goal and Definition of Done, if your team uses Scrum.
Working terms: acceptance criteria, blocker, release and any labels used on your work board.
Product and business terms: customer, active account, completed order or any phrase that changes a requirement or metric.
Abbreviations: write out the full name, explain its purpose and give an example where useful.

For framework terms, link to the official definition and explain how it applies in your context. For local terms, record the meaning your team has agreed. Avoid changing a recognised framework definition to fit a habit that contradicts it.

Five steps to create a useful glossary

1. Collect the words causing confusion

Purpose: Solve a real communication problem.

Look at recent questions, requirements, meeting notes and handovers. Which words needed explaining? Where did two people interpret a label differently? Start with five to ten terms that would help your team now.

2. Agree definitions across roles

Purpose: Make assumptions visible.

Invite the people who use the terms, including product, development, testing and relevant business colleagues. Ask each person what a term means and what decision they would make based on it.

If the answers differ, work through a concrete example. Record the agreed meaning, or mark the entry as awaiting a decision. A glossary should show uncertainty rather than make an unresolved question look settled.

3. Use plain language and an example

Purpose: Make the meaning usable.

Write a short definition that someone new to the team can understand. Explain unfamiliar words instead of replacing one piece of jargon with another. Add an example and, where useful, a boundary: what does this term exclude?

4. Keep one accessible version

Purpose: Help people find the answer when they need it.

Use a shared location your team already visits, such as its documentation space or a shared document. Link to it from onboarding notes and relevant work items. Make entries searchable and explain how people can suggest a correction.

Where a definition has an authoritative source, link to it. For example, the glossary can summarise your Definition of Done and link to the full quality standard rather than maintaining a competing copy.

5. Give it an owner and review it in use

Purpose: Keep the glossary connected to the work.

Agree who will keep the page organised and bring proposed changes to the right people. That person does not need to decide every definition alone. Business terms may need agreement from a product or subject specialist.

Update an entry when a conversation exposes ambiguity, a process changes or a new term becomes useful. A brief review during onboarding or after a release can also help. Remove obsolete entries or label them clearly so they are not mistaken for current practice.

A worked example: what does “done” mean?

Imagine a team reviewing a new password reset feature. A board item has moved to “Done”, but a stakeholder asks why customers cannot use it yet. This is an illustrative scenario, not a reported project result.

The team discovers that it has been using one label for several different states. Its glossary needs to distinguish the following terms:

Definition of Done

In Scrum, the Definition of Done describes the quality state an Increment must meet. An Increment is a usable addition to the product. Link your glossary entry to the actual quality standard used by the team.

Acceptance criteria

Acceptance criteria describe the expected behaviour or conditions for a particular piece of work. For the password reset feature, they might explain how a valid reset link behaves and what happens when it expires.

Released

Agree what released means for your product. For this example, it means the feature is available to its intended customers in the live service.

Once the terms are clear, check whether your board labels and stakeholder updates reflect them. Writing a definition is useful; applying it to the next conversation is what makes it valuable.

Use this format for each entry

Keep the structure simple enough that people will maintain it. This example shows the level of detail you could use for a locally agreed term.

Term: Released
Plain-language definition: Available to the intended customers in the live service.
Example: Customers can use the new password reset flow on the live website.
Does not mean: Code merged, testing complete or deployed with customer access disabled.
Source or context: Local release agreement. Link to the relevant release process.
Maintained by: Product and delivery colleagues, as agreed by the team.
Review trigger: The release process or the intended audience changes.

Start with a 20-minute conversation

Choose three terms from a recent meeting that could have been interpreted differently. You can try this with your team, or practise using a course exercise or sample project.

First 5 minutes: ask people to write what each term means before comparing answers.
Next 10 minutes: discuss the differences and agree a short definition with an example. Flag anything that needs a separate decision.
Final 5 minutes: save the entries, share the link and agree who will keep them current.

At the next relevant discussion, check whether the definitions help people understand the work. If they still leave room for confusion, improve them.

You can also use the existing Agile Glossary PDF as a starting point for discussion. Check any definitions against your framework and your team’s context before adopting them.

You do not need a perfect dictionary to begin. Start with the words that affect a real decision, agree what they mean and make it easy for the next person to find the answer.

References: Manifesto for Agile Software Development and The Scrum Guide, November 2020, by Ken Schwaber and Jeff Sutherland. A glossary is an optional working practice, not a prescribed Scrum artefact. The entry format, exercise and local definitions are practical suggestions.