Agile glossary.

This is a list of terms that you might see or hear at Co-op.

Browse by letter:
A, B, C, D, E, F, G, H, I, J, K, L, M, O, P, Q, R, S, T, U, V, W.

The list includes activities, job roles, meetings and words linked to Co-op ways of working.

The definitions set out what things are and an overview of how and when you might use them.

It does not provide details of how to do activities. You can find full activities including guidance and steps on the activities page.


Acceptance criteria

Acceptance criteria is the minimum outcome that your team’s product must achieve before you progress.

Teams use acceptance criteria to describe what your team needs to do to complete a task.

Your team sets out acceptance criteria and standards together. You can use your team’s user stories to help you do this.

It’s important that your team and stakeholders all have a shared understanding of the acceptance criteria that you are working towards.

See definition of done.


Building products and services that anyone can use, including people:

  • who have a disability or condition
  • with English as their second language
  • with low literacy
  • who are not confident using digital technology

This means designing content that people can understand and navigation that everyone can use. Co-op has an accessibility policy and accessibility guidelines.

Everyone at Co-op is responsible for making products and services accessible.


Agile is a way of working which helps teams to achieve outcomes and focus on the user.

It is an approach to project management that helps teams to deliver value to customers faster and with fewer headaches.

An agile team delivers work in small increments. Agile is different to a waterfall way of working which sets out the detail of a project before it begins and delivers everything together in a big launch.

Agile focuses on collaboration and team members are empowered to govern and reflect on their progress as a team.

The idea is to:

  • break down work into smaller tasks with clear goals
  • work together as a team
  • test simple versions of ideas with users
  • use feedback loops to develop the product or service
  • adapt and change direction when you need to

Agile is not only about having stand-ups and using post-its or Trello. It’s important to have the right team roles and a collaborative working culture place.

The most valuable part of working in an agile way is working to agile principles and the agile manifesto. The 4 values of agile:

  • Individuals and interactions over processes and tools
  • Working products or services over excess documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Agile activities

Tools, methods or activities which help teams to:

  • create shared understanding
  • use insights from users to inform decisions about what to focus on next

Co-op's activities for agile stages include guidance on how to prepare and step-by-step instructions on how to do the activity. You can adapt these activities for the problems that you are working on in your team.

We do not have activities for everything but we’re working on it. You can also use our resource list.

Agile principles

Agile ways of working are rooted in 12 principles:

  • Deliver value to users early
  • Embrace change
  • Deliver frequently
  • Work in cross-functional teams
  • Support and trust your people
  • Communicate face-to-face
  • Measure progress by what you deliver
  • Maintain a sustainable pace
  • Keep a focus on quality and excellence
  • Keep it simple
  • Self-organise for best results
  • Inspect and adapt

There are different ways of doing agile like Scrum, Sprints, Kanban and Test-Driven Development (TDD). Ways of working are only agile if your team is doing all the things in the 12 principles.

Align thinking

Making sure that everyone has a shared understanding of what the team is doing or trying to achieve.

Teams do this through communication methods called ceremonies. The main ones are stand-up and retros but aligning thinking is part of all agile activities.


To move your project from discovery to alpha stage you must have:

  • budget approved by leaders
  • a product owner and team
  • a space for your team to work and support from the business

In an alpha you should:

  • understand what users need
  • work collaboratively
  • create early proofs of concept
  • research it with users
  • learn from it
  • decide if it’s worth developing further

The product or service may only have minimal features at this point. The idea is to test whether the concept works for the user before spending time and money developing it.

Alpha comes after the Discovery stage and before the Beta stage.


Something you assume to be true about your users or product. Often you test this in research.

Assumption mapping

An activity to work out what you do and do not know about your users.

You can use your team’s hypothesis to write down assumptions and map them on a 4-way matrix of:

  • known to unknown
  • important to not imporatant

This helps you to decide what to focus on next when you do research.

Back to top.



To move from an alpha to a beta phase, you must have:

  • a Co-op business area committed to sponsor all, or part of, the service
  • budget approved by leaders
  • measures of success agreed between you and the business
  • regular funding and performance reviews set up
  • a clear way to make it a fully operating part of Co-op

In a Beta you should:

  • learn how to build and run your product or service
  • make it scalable
  • get users to try it
  • test real data securely
  • learn from users
  • integrate it with the existing service
  • meet Co-op service quality guidelines

Beta is the stage of a project when you build on a minimal product or service.

Beta comes after Alpha and before the Live stage.

Business optimisation

The ongoing and gradual improvement of products, services or processes as a way of life for the team.

Also known as continuous improvement.

Back to top.


Capability cluster

See multi-disciplinary team.


Team activities which help you communicate, keep up-to-date and reflect on how you are working as a team. These include Stand-ups, Retros, Show and tells.

Collaborative working

A way of working that allows the team to work together at the same time. Team time focuses on doing the work, not meetings to discuss progress.

In agile and service design, teams discuss progress and how they are working in stand-ups and retros.

Community of practice (CoP)

A group of people who are interested in improving practice around their job role together. At Co-op there are CoPs for content design, service design, research, interactive design, delivery, engineering.

Members of the CoP take turns to run the sessions and all members are equal. CoPs are safe environments where members can test ideas and contribute without worrying about criticism.

Communities of practice (CoP)s meet regularly, often fortnightly, and stay in touch through messaging in between.

Also known as job family.

Content designer

A content designer creates content that:

  • meets the user needs
  • is accessible to everyone
  • everyone can understand

You can use the content guidelines and glossary to make sure that you are using the right approach.

Day-to-day content designers do things like create content for websites, forms, apps or presentations, check the accessibility of content and create a content strategy for a product or service.

Content designers are not usually responsible for interactive design or graphic design in the team.

Content designers work collaboratively in agile teams and may support the team with service design, user research and interactive design if they have skills in that area.

Content crit

See crits.

Continuous improvement

Continuous improvement can mean different things. At Co-op it’s always about making things better. It could be continuing to test and improve a product or service after it goes live. It could be continuing to improve the way the team works together.

The important thing is that team makes decisions on what to improve together after considering all of evidence. It’s not based on one person’s opinion or request.

Also known as business optimisation.

Crazy eights

A way to generate lots of ideas to solve a problem in a short space of time. The method involves generating 8 ideas in 8 minutes.


Team members share ideas early in the process so that they can use the group’s feedback to improve it before showing it to users. The person that created the work usually leads the crit.

A crit is not sharing a document for people to comment individually or pass onto someone else for the next version. The value of crits is that everyone responds to the design or content together, learns from comments and agrees what the next version should be in real time.

Sharing early versions of design and content saves time and money because:

  • you don’t spend time finessing content or design which was never going to work
  • you make decisions on the content together in one meeting, not by waiting for several people to have time look at one after the other
  • you share learning and avoid repeating mistakes across different teams

Also known as content crits and design crits.

Cross-team working

Members of different teams working together on projects to share skills and ideas.

Cross-working can help people to learn skills from each other. It can also help teams to bring different perspectives to help solve a problem.

For example, a team member from the Ecommerce team could work with a team member from Membership. They could share what they have learned about accessibility from user research from their products.

Cross-functional working

Teams that include people with different roles working together on a product or service. This might include content designers, service designers, interaction designers, researchers, delivery managers, front end developers, business analysts.

Also known as multi-disciplinary working.

Back to top.



Information that we collect and store.

This could include:

  • users' information including contacts
  • information about teams
  • facts and figures about product performance
  • notes and recordings from quantitative and qualitative research sessions
  • demographic and other information from third parties

The team analyses and uses data to do things like:

  • show how the product is performing
  • inform design decisions
  • put research findings together
  • analyse users’ profile and behaviours

Data includes anything recorded in text, audio or video. It must be collected and stored according to GDPR (General Data Protection Regulations). If you need help with how to store data speak to your team or contact Data Governance.

Definition of done

A sentence that describes what you need to do to complete a task or create an outcome.

Delivery manager

Delivery managers use skills in agile and lean practices to maintain team health and support delivery. They help the team to:

  • focus on delivering value for users and Co-op
  • continually reflect and improve how they are working together collaboratively
  • remove distractions and blockers that prevent the team from delivering

The delivery manager works with the team to build trust, manage team dynamics and motivate people.

Day-to-day tasks might include facilitating stand-up, creating delivery plans, setting up and monitoring OKRs and checking progress against weekly goals.

Delivery metrics

Product or service goals that help teams to reflect on progress. They help you make data-driven and user research-driven decisions.

Agile delivery metrics always focus on outcome not output.

Delivery plan

A delivery plan includes the team’s current priorities.

The team review priorities through stand-ups, retros, weekly planning sessions, research and data.

Delivery plans include:

  • tasks that the team will work on
  • who will work together on tasks
  • definition of done for tasks
  • decisions about new work that comes up

The delivery plan has more details of tasks than the product roadmap which covers the long-term team vision.

Design crits

See crits.

Design and design thinking

There are lots of different kinds of design. At Co-op you might hear people talk about:

  • product design
  • visual design
  • architecture design
  • service design

Design thinking provides a solution-based approach to problems. It’s a way of thinking and working as well as a collection of hands-on methods.

Teams aim to understand the user, challenge assumptions, and define problems. By working in this way teams can find solutions quickly and can change direction if they need to.


The discovery is the first stage of a project and at Co-op you must have your budget approved before you start.

The team works together to understand the problem they are trying to solve and whether Co-op can help.

In a discovery you should:

  • find out who your users are
  • find out if there’s a user need
  • learn from users and the business
  • see if and where there are opportunities to help users and the business
  • decide if it’s worth progressing further

In a discovery stage the team must decide whether the benefits of fixing the problem outweigh any costs and risks.

Discovery comes before Alpha.

Dot voting

A quick, democratic way to prioritise and refine lots of ideas using dots.

Double diamond

The Double Diamond design model was launched by the Design Council in 2004.

The model includes 4 phases of product and service development. It helps teams to:

  • make sure they understand the problems they are working on
  • use evidence to make decisions
  • test early versions of solutions in the user’s environment

Back to top.



A quick way to test an assumption or idea using a simple prototype.

You can also use experimentation to describe an approach to design and ways of working methods. For example, someone who uses experimentation in their work, is always trying different methods or activities to help them and their team progress.

Back to top.



A facilitator runs a workshop or session, creating a safe environment for people to contribute freely and equally. There is help for facilitators in the ‘guidance’ part of the activities.

Feedback culture

A working culture that encourages people to ask colleagues for feedback. It’s important that feedback is welcome and you provide feedback in a way that someone is comfortable with.

Your team needs to talk about which ways you want to set-up feedback to work. It could be through:

  • regular 1-to-1 catch ups
  • thank-you boards
  • retros
  • anything else that suits your team


An approach, structure or methodology for working in an agile way. There are lots of different frameworks but all involve delivering value in small changes gradually.

Back to top.



What the team wants to achieve. Team goals should align with the team vision.

See OKRs, vision, metric.


How we make sure that we are working in the right way and according to Co-op governance principles. Governance is about the way a team works together as well as how you record what you do.

Day-to-day governance includes:

  • setting regular goals, reviewing them and refining them if you need to
  • making sure goals have outcomes that meet your user need
  • agreeing how you will measure your progress
  • designers and delivery team members working collaboratively
  • reflecting on team progress
  • observing or carrying out user research

Tools and activities that you can use to help your team with governance are:

Agile governance is not about throwing away reports and records. It’s about making the work that you do count and allowing the team to adapt to meet your user needs.

Everyone involved in the project, including stakeholders, are responsible for governance. This includes attending show and tells and other team sessions, asking constructive questions about progress and sharing ideas about how to improve.

Governance principles

Co-op agile governance principles include:

  • Outcomes are better than deliverables
  • Measure the right things at the right times
  • Teams are the unit of delivery
  • Networks of teams beats hierarchy
  • Everyone is responsible for quality
  • Everyone is responsible for accessibility
  • Assure as you go
  • Behaviour matters more than documents
  • See delivery for yourself

See governance for details of how the governance principles work in day-to-day team life.

Back to top.


How might we

A statement that helps teams think about problems to produce ideas for user research.

The team creates and prioritises the statements together to understand which ideas to focus on next and why they are working on them.

How might we sessions are good preparation for a sketching session.


A statement that helps teams address problems.

The format is:

We believe that... (assumption of the user’s behaviour)

So if we do... (action in terms of how we can help the user)

Then we will see (a result or measure of success)

Using hypotheses helps teams to think about the impact of solutions and risks before they take any action.

Back to top.



A series of activities that a team do together before starting a new piece of work.

The purpose is to:

During an inception the team creates the product roadmap and a list of tasks for the delivery plan.


An in-depth understanding of why users behave in certain ways. The insight helps the team to make decisions on how they develop the product or service.

An example of an insight could be:

  • People don’t know what a co-operative is, so the concept of paying for a share is difficult for them to understand.
  • Colleagues often struggle to understand and talk about organisational change due to conflicting messages. Colleagues need consistency so that they can work together effectively.

Insights come from qualitative and quantitative data and research.

Interactive designers

Interactive designers help the team to:

  • create designs with are clear and accessible to the user
  • build products and services that engage with the user
  • create a user journey through a product or service

Day-to-day tasks might include:

  • creating sketches of ideas on paper or digitally
  • front-end code work to design websites, apps or parts of a service
  • adapting Co-op design patterns to create visual designs for a product or service

As a team member, interactive designers also go to research sessions and team stand-ups, planning and retro meetings.

Iterative design and development

Improving design or development in short stages with regular feedback from users.

Teams have a product roadmap and all the usual governance when they work iteratively.

It’s about building small and learning everything you can for each version. You can then decide whether to invest more resources on a product with a bigger scale or more features.

Back to top.


Job family

See Community or Practice.

Back to top.



The term Kanban comes from a Japanese manufacturing term. It helps teams improve productivity by focusing on a problem area and reducing the amount of work that a team has in progress.

People often use Kanban to mean a Kanban board.

Kanban board

A way to visualise the work that a team is doing based on the Kanban technique. It can be a physical or virtual Kanban board.

A simple Kanban board has three columns; ‘to do’, ‘doing’ and ‘done’, but there are different versions. The team decide together on which tasks to add to each column and the definition of done for each task.

The term Kanban board is often shortened to just Kanban.

The team uses the Kanban board in daily stand-ups to track progress during the working week. When people are working remotely they often use a Trello board for this.

Some teams work in Sprints instead of using Kanban or switch between the two.

Kick off

A series of team activities that they do before starting a new piece of work.

The purpose is to:

The team creates a list of tasks which work with the delivery plan and product roadmap.


A measure that helps you to evaluate progress against goals and objectives.

See OKRs, metric.

Back to top.


Lean thinking

The term Lean comes from manufacturing and the Toyota Production System. Lean focuses on minimising waste and maximising value. It focuses effort on activities that provide immediate value to the customer.

Learning culture

A learning culture encourages continuous learning and applying learning to the way team’s work day-to-day.


The stage when you embed your service in the business.

A live service is one which works for the people it’s intended to help, is run by the right people and is continuously improving.

To move your service from beta to live, you must have:

  • budget approved by the business area you’re working with
  • a service owner who’s accountable for the service
  • secure systems and processes
  • regular funding and performance reviews set up

All live services should meet Co-op service quality guidelines.

Back to top.



A way of measuring the objectives you want to achieve.

For example, if your objective is to increase engagement with your website, your metrics might be:

  • Google analytics shows an increase of website visits
  • User reseach shows that the website meets specific user needs

See OKR.


A mission statement should include:

  • what you do
  • who you do it for
  • the outcome and value of your work

It should be as clear as possible. Use 2 or 3 short sentences or bullet points, not one long complex sentence.

A mission statement is not about the tasks that the team needs to do. It is about the overall goal.

Multi-disciplinary teams

Teams that include people with different roles working together on a product or service.

Roles might include content designers, service designers, interaction designers, researchers, delivery managers, front end developers, business analysts.

Back to top.



Something seen directly in research.

Objectives, Key Results (OKR’s)

A collaborative goal-setting tool that the team uses to set challenging goals with measurable results.

It includes:

  • Objectives - what you want to achieve
  • Key results - how you are going to measure whether you meet your objectives

You use OKRs to:

  • track progress
  • create alignment
  • set motivation towards goals

You define how you deliver your objectives in planning sessions as a team.


Outcomes are the results of what you do as a team. It is not the same as outputs which are the things you produce as a team.

For example:

  • Output: A website with 5 different ways to ask for help
  • Outcome: A website which helps the user to find help when they need it
  • Output: A report which says that you have completed all 30 tasks which your annual plan set out
  • Outcome: A summary of user research which shows that all of your users can use your product or service

Your team needs to agree how they are going to know that they achieve their outcomes.

You can do this with combination of:

  • user research
  • testing the product or service
  • metrics like Google Analytics or other system statistics

Back to top.


Paper prototyping

Creating rough or hand-sketched drawings of a design to get quick feedback from users.

Teams use paper prototyping to test an idea or concept without investing too much time or effort in creating an electronic version. You need to set out what you want to learn from creating and testing with the prototype.


An online tool that helps you do your work.

At Co-op we use things like:

  • Microsoft teams: for group or 1-2-1 video meetings like stand-ups, retros, research sessions
  • Slack: for instant messaging and updates, to check in, to post information and to say hi
  • Trello: for planning the week, for Sprint or Kanban tasks (one item per card) and to break up other information
  • Miro: for visualising things like planning, research, synthesis of user research, ideation and retros
  • Sharepoint/One Drive: For creating, commenting on and storing documents like week notes, case studies, early versions of content
  • Calendar/email: for updates from across Co-op, for calendar requests and document notifications, to contact people across Co-op
  • Confluence: for recording information about projects like team mission and purpose, roles and responsibilities and decision making
  • Jira: for capturing and tracking the progress of the work that the team is doing

Point of Departure

An activity for all the team to do at the start of a new project or piece of work as part of a Kick-off or inception. The activity helps the team to agree things about the project like:

  • purpose of the team or project
  • outcomes
  • roles and responsibilities in the team
  • tools you will use including software and technology platforms
  • how you will know if you success or fail

A Point of Departure activity is only part of a wider Kick-off event.

Principles for working together

The standards your team sets about how you want to work with each other at the beginning of a project.

Priority mapping

A visual way to prioritise work using a chart which splits the space into quarters. Your team place each piece of work on a quarter split by:

  • a vertical line of no impact to high impact
  • a horizontal line of no effort to high effort

The idea is that your team prioritise the work in the high impact/low effort quarter of the chart.

It does not mean that you do not do the work that is not in that quarter. The other work just comes later if your team decides that you need it.


An item created for sale or use. It can be a physical or digital item or service.

Product backlog

A product backlog is a list of tasks for the team. The most important items are at the top so the team knows what to work on first. You might have a delivery plan to help you do this.

The product backlog is a central view of what the team is working on. Your team all agree what you will bring forward to be ‘in progress’. You can use platforms or tools like Trello and Kanban to help with this.

Product demo

Showing how a product or service works including what informed the thinking and decisions.

Q & A sessions give you the chance to share what you’ve learned from the process and are also part of project governance.

Product lifecycle

The lifecycle of a product from idea, through design and manufacture, to service and disposal, retirement or replacement of the product.

Product manager

The product manager is responsible for aligning the team around the product vision. They prioritise the product backlog items which have the highest value to the user and to the business.

Product owner

The product owner is responsible for the return on investment (ROI) of the product development.

Product roadmap

A product roadmap is a plan for how a product or solution will develop over time. It includes:

  • why you are doing what you are working on
  • what you want to find out in research

The product roadmap sets out the context for the team's everyday work. The team adapt it to respond to changes in priorities, which might come from the business or from changes in the user’s world.

Multiple agile teams may share a single product roadmap.

The product roadmap is not the same as the delivery plan which includes more detail about what the team is doing through tasks.


A prototype is an early sample, model, or release of a product that the team uses to test a concept or process.

A prototype could be paper, clickable designs or code.

Psychological safety

Teams create trust and a safe environment so that they can work together to:

  • express opinions without being judged
  • take calculated risks with the support of the whole team
  • experiment with different ways of working/li>
  • create a culture of feedback

See safe environment.

Back to top.


Quantitative data and research

Quantitative methods usually involve large numbers of participants and focus on the ‘what’ users are doing. Quantitative data is recorded in a structured format, for example, asking people for yes or no answers and asking them to answer on a scale of 1-10.

It’s sometimes seen as more scientific and objective than qualitative research methods. This is not always the case because data can be interpreted in different ways.

Methods to collect quantitative data include:

  • online surveys
  • paper surveys
  • mobile surveys
  • kiosk surveys
  • face-to-face interviews
  • telephone interviews
  • website surveys
  • web analytics
  • online polls
  • analytics data
  • observing users in research sessions by counting actions

Qualitative data and research

Qualitative research methods usually involve interacting with people directly and focus on ‘why’ they are doing things. It involves fewer participants than quantitative research.

Qualitative data is recorded in a free format so people can answer how they like. Note takers in qualitative research sessions try and write down as close to what people say as possible.

The process of collecting qualitative data is sometimes unstructured. It can be time-consuming but leads to in-depth findings.

Methods to collect qualitative research data include:

  • 1-2-1 or group interviews
  • usability sessions
  • observing users using products or services

It is important that qualitative research leads to team research synthesis sessions so everyone understands the research findings.

Quality Assurance

Quality assurance is built into the way that agile teams research the product with the user.

The product or service must:

Back to top.



Retrospectives or ‘retros’ are regular sessions which help teams to reflect on the work that they have been doing. They also give the team chance to find ways to improve the way they work in future.

It is important that retros include a retrospective prime directive.

Retros happen every two weeks. When teams are working in sprints they do a retrospective at the end of each sprint.

Retrospective prime directive

A retro facilitator refers to a retro prime directive at the start of a retro to help to set expectations. It helps create a positive culture where everyone can learn and improve without using blame.

This is an example of a retrospective prime directive:

‘“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.‘ ∼ The Prime Directive, Norm Kerth

The Prime Directive, Norm Kerth

Robotic Process Automation

Robotic process automation creates processes using software robots or artificial intelligence.

Also known as software robotics or automation.

Roles and responsibilities

Teams often do an exercise to define each member's roles and responsibilities at the start of a new project. This could be part of an Inception or a Point of Departure exercise.

A team member might have an overall role, like content designer, and do some service design and research if it helps to support the project.

The team reviews roles and responsibilities regularly. It can be helpful when someone leaves or joins the team.

Back to top.


Safe environment

A working environment when people feel free to express ideas, try new ways of working and work without worrying about failure or negative criticism.


An agile way to develop, deliver, and improve products or services.

Teams use short feedback loops to test what they are working on with users and use the learning to inform what the team does next.

The aim is to keep delivering value or change gradually in small ways over a short time. Typically teams work in 2 week cycles.

Scrum includes a set of meetings, tools, and roles that help teams to structure and manage their work.

Scrum master

The scrum master is the owner and driver of the Scrum process, helping teams to adopt scrum values, make changes quickly and perform in the best way that they can.

The scrum master is a facilitator and coach. They encourage continuous improvement and remove barriers for the team.

Service design

An approach that puts the user at the centre of a product or service and focuses on meeting user needs.

It is based on design thinking which teams use to:

  • understand the end-to-end user journey
  • understanding the problem
  • create a number of possible solutions
  • use research to inform decision making
  • keep making small iterative improvements to products and services

Service design is not only about creating service maps or blueprints.

See service designer.

Service designer

A service designer helps the team to:

  • visualise the end-to-end journey of a product or service
  • create a shared understanding of the way a user uses a service to complete a goal
  • deliver a business service that benefits the user

Days-to-day a service designer might carry out user research, produce service maps, lead sessions around understanding the user and design prototypes to test.

Service designers do not work alone to understand a process or service. The team, SMEs and stakeholders all need to contribute to understanding the user journey.

As a team member, service designers work closely with the team, going to stand-ups, planning and retro meetings. They might also help the user researcher or do user research.

Service maps

Service maps show a user journey for your product or service step-by-step. Teams work out all the user’s connections with the service, including the parts that a user can and cannot see.

Teams can use service maps to help visualise an existing service and help to identify improvements. They can also use them to map out how the service could be better in future once they have user research.

Also known as service blueprints.

Show and tell

An opportunity to share your team’s progress with a wider audience. Show and tells usually have a regular slot each week, fortnight or month.

Show and tell content includes the things you've been working like live demos of the product, working prototypes or research findings. It’s also an opportunity to show what didn’t work so you can share the learning with other teams.


A demonstration of what the team has been working on to key stakeholders.

See show and tells.


SME usually means a Subject Matter Expert who is part of the project as a stakeholders.

The SME has direct experience of a product or service area. For example, if you are creating a product to explain how to carry out health and safety checks, a Co-op colleague from the Health and Safety team would be an SME.

SME do not design the product or service, but they might come to some project or service mapping sessions. They can give you insights which you can use with user research to build your product.

SME also means Small to Medium Enterprise which describes a business with between 30-250 employees.


A short, time-boxed period when a team works towards a key outcome. Sprints usually last one or 2 weeks.


Anyone with an interest in the product who is not part of the main team. These are the people who help the team fund, develop, release, support and promote the product.

Success criteria

Things that that a product must achieve before the user, customer, or group of stakeholders accept it. Success Criteria help the team make sure that the work meets the user and the business needs.

See acceptance criteria.

Stand up

Short team meetings that last between 5 – 15 minutes at the start of the day. They should happen at a time that suits the team. If people are working remotely, they can join the meeting by video call.

Everyone in the team has an opportunity to say what they’re working on, share problems and ask for help. Often teams use Trello or Kanban to make sure they are focusing work on priorities and goals.


Storyboards sketch the stages of a user journey. It helps teams to visualise how their users might use a product or service.

Back to top.


Team canvas

A visual or board that shows:

  • the goals of a team
  • the skills within the team
  • the way the team works
  • the team values


Co-op teams are multi-disciplinary groups of people who are working together to deliver a product or service.

See team health, cross-working teams.

Team health

How the team works together to monitor, measure and improve performance. The focus on is developing relationships and behaviour within the team, not developing the work.

Test and learn

The team produces the simplest thing possible to learn what works and to reduce the risks of doing the wrong thing. They then apply the learning to the next version of the product or service.

Three amigos

A session where key team members come together to agree on a user story or revisit an outcome.

It always includes a:

  • product owner
  • developer
  • researcher

Designers can also help in 3 amigos sessions.

Back to top.



Groups of people who need to use the product or service that you are working on. Users could be colleagues, customers, Co-op members or the general public.

User needs

Things that users need from a product or service to get the right outcome for them. User needs help teams to make decisions when they create products or services.

You can describe user needs by writing user stories.

User research

User research helps teams make decisions by providing evidence-based insight into their users’ behaviours, experiences and needs.

User research involves gathering information directly from the people who use the product or service. It includes collecting quantitative or qualitative data or a combination of the two.

User Researcher

User researchers gather information from users about their behaviours, needs and motivations.

They help teams to:

  • make decisions based on evidence
  • keep the voice of the user in mind
  • make sure that products and services are accessible to everyone

Day-to-day a user researcher might organise research sessions, carry out research, lead research synthesis sessions and contribute to service maps.

User researchers do not do all the research alone. The team help with research sessions and synthesising research. This gives the team a better understanding of the user.

As a team member, user researchers work closely with the team, going to stand-ups, planning and retro meetings.

User research synthesis

The team goes through the research together so that everyone understands the user’s perspective.

It might involve:

  • reading through research notes together
  • each team member summarising key points and comparing them
  • looking for patterns or themes in the research
  • using themes to refine your research approach
  • using research outcomes to make decisions about the product
  • creating user personas

User stories

User stories:

  • describe what the user needs from a product or service
  • explore ideas for solutions

The format of a user story is:

As a... (description of a user situation)

I want to...

So that...

For example:

As a person who is new to Co-op ways of working

I want to understand the terms people are using

So that I can understand what people are talking about and do my job better

The team produces a number of user stories and prioritises them so that they can focus on what is most important for the user.

Back to top.


Value chain

A step-by-step business model for transforming a product or service from idea to reality.

Value chains help a business to deliver the most value for the least possible cost.


Velocity is the amount of work a team can tackle during a single Sprint and is a key metric used in Scrum.


The outline of a team’s purpose and what it wants to achieve.

A good vision statement is short, simple and easy to understand. It should be ambitious and realistic.

Back to top.



The waterfall approach breaks project activities down into linear phases. Each phase depends on the delivery of the previous one.

Projects are mapped out in detail months or years in advance. It is useful in industries like construction or when it is not possible to make major changes after a project starts.

It is different to agile ways of working. At Co-op teams sometimes combine waterfall and agile ways of working if they need to.

See agile.

Ways of working

Ways of working describes how a team works together and the processes and methods they use to get work done.

It also describes the behaviours and culture within the team.

Using a team charter is a good way for teams to agree roles, responsibilities and ways of working as a team and with your leadership team. You can use it with new people who join the team and as a part of a Kick-off or Inception.

Your team should revisit and reflect on your ways of working regularly.

Week notes

A brief description of what the team has been working on that week. It might include results from research, photos of activities and reasons for decisions.

Week notes are part of your team governance. All the team contribute to week notes if they are working that week.

Working in the open

Working in the open is one of the main principles of how we work at Co-op.

Teams communicate openly about what they’re working on and how they’re working, including successes and failures. This includes sharing what they learn from user research and how this helps them to make decisions.

Working in the open helps teams to get feedback and confidence that they are working in the right direction.

It also leads to trust with stakeholders and confidence that the team is delivering value for users. Examples include show and tells and week notes.

Back to top.


Want to know more?

Let us know if we can help you or your team apply these ways of working.

Or perhaps let us know how we can improve this website for you.

Include this if you’d like a reply.

Index version 2 Index version 3