Agile glossary

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

The definitions include 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 guidelines for activities on our activities page.

A

Acceptance criteria

Acceptance criteria are a short list of conditions that a task or user story must meet before it is complete. Each task or user story will have its own list of acceptance criteria, created and agreed by the team before the work gets done.

For example, when working on an online shopping site, one user story might be: “as a shopper, I want to choose a delivery slot, so that I know the delivery will arrive when I’m at home to receive it.”

Acceptance criteria for this might be that:

• the page displays a list of available slots
• the user can select one slot from the list
• when the user books a slot, a confirmation message appears

Acceptance criteria help create a shared understanding of what the user story will cover and what completing the user story means.

Acceptance criteria are specific to individual tasks or user stories. A definition of done lists the standards we need to meet for every task or user story.

Accessibility

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

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

This means designing products and services 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

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.

Alpha

There are four main stages to agile product development: discovery, alpha, beta and live. This is one way of organising and releasing new product developments.

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

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.

To move your product or service from discovery to alpha stage you typically have:

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

Assumption

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.

B

Backlog

See product backlog.

Beta

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.

C

Ceremonies

Another name for 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.

Check-in

We use check-in activities at the start of a meeting or workshop. Check-ins are a way for the group to introduce themselves to each other and find out how people are feeling that day.

View our guide to doing a check-in.

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.

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.

Converge

Divergent and convergent thinking are two different stages of problem solving.

Creating lots of ideas (diverging) at the same time as judging which ones are good (converging) can be confusing.

People tend to get better outcomes by doing divergent and convergent tasks separately.

Examples of using divergent and convergent tasks together include:

• diverging by asking everyone to write lots of possible next steps for a project, then converging by using priority mapping to agree which to work on first
• diverging using rapid eights to generate lots of ideas, then converging using dot voting to agree which of those to develop further

Crits

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-team 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 e-commerce team could work with a team member from Membership. They could share what they have learned about accessibility from user research on 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.

D

Data

Data is any information that we collect and store.

This could include:

• user 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

Teams analyse and use data to do things like:

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

Data includes anything recorded in text, audio or video. It must be collected and stored according to law and regulations. If you need help with how to store data speak to your team or contact the data owner.

Definition of done

Definition of done is a list of conditions that any task or user story must meet before it is considered complete.

The team will agree this list. Some examples could be:

• work has been tested and any defects corrected
• work meets our accessibility guidelines
• work has been shown to the product manager and stakeholders and has been accepted

Having a definition of done helps make sure things are not forgotten.

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
• 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:

• architecture design
• content design
• service design
• product design
• visual 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.

Discovery

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.

Diverge

Divergent and convergent thinking are two different stages of problem solving.

Creating lots of ideas (diverging) at the same time as judging which ones are good (converging) can be confusing.

People tend to get better outcomes by doing divergent and convergent tasks separately.

Examples of using divergent and convergent tasks together include:

• diverging by asking everyone to write lots of possible next steps for a project, then converging by using priority mapping to agree which to work on first
• diverging using rapid eights to generate lots of ideas, then converging using dot voting to agree which of those to develop further

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.

E

Experimentation

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.

F

Facilitator

A facilitator runs a workshop or session, creating an environment for people to contribute freely and equally. There is help for facilitators on the ways of working page of this site.

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

Back to top.

G

Goal

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

See OKRs, vision, metric.

Governance

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:

• Trello or Kanban
• fortnightly retros
• week notes
• show and tells
• sharing information with Community or Practices and other cross-working groups
• looking at team work on walls or through online platforms like Miro

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.

H

How might we

A statement that helps teams think about problems to produce ideas for possible solutions.

The team creates and prioritises the statements together to understand:

• which ideas to focus on next
• why they are working on them

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

View our guide to doing a how might we activity.

Hypothesis

A statement that helps teams address problems.

The format is:

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

So if we... (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.

For example, when working on an online shopping site:

We believe that... we’re causing confusion by showing members up to 10 offers at once

So if we... reduce the number of options to 3 at any one time

Then we will see... an increase in offer selections and sales

This example gives the team a problem area to explore: “how might we make the offers more prominent?” It also gives the team a way to evaluate the hypothesis. If they try several changes to make the offers more prominent but sales don’t change, it’s likely this hypothesis is incorrect.

Back to top.

I

Inception

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

The purpose is to:

• align the team and stakeholders around a clear goal
• agree how the team will work
• build relationships
• establish a safe environment for the team to work in

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

Insight

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 that:

• 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

Insights come from qualitative and quantitative data and research.

Interaction designers

Interaction designers help the team to:

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

Day-to-day tasks might include:

• creating sketches of ideas on paper or digitally
• prototyping
• user interface design
• coding the front-end of 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, interaction 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.

J

Job family

See Community or Practice.

Back to top.

K

Kanban

Kanban is a method for:

• visualising a workflow
• managing the flow of work
• making changes to the process to improve it

The method came from manufacturing originally (the Toyota Production System) and is now used for lots of types of work.

A few key practices in kanban are to:

• make your current process visible (often using a kanban board)
• limit the amount of work in progress (WIP)
• focus on improving problem areas that slow down the flow of work

Kanban starts with your current process, letting you understand what’s working and gradually change things over time.

Find out more about kanban at the Kanban Guides site.

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: what columns to have, which checklists to include such as definition of done, other policies about the process of their work.

You can reflect on the content of the kanban board and change this over time.

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.

Key performance indicator (KPI)

KPIs are measures that help to evaluate progress against goals and objectives.

See OKRs, metric.

Kick-off

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

The purpose is to:

• align the team and stakeholders around a clear goal
• agree how the team will work
• build relationships
• establish a safe environment for the team to work in

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

View our guide to doing a kick-off activity.

A kick off is also known as an inception or point of departure.

Back to top.

L

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.

Live

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.

M

Metric

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:

• an increase of website visits, shown in Google Analytics
• user research that shows that the website meets specific user needs

See OKR.

Mission

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.

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.

O

Observation

Something seen directly in research.

Objectives and key results (OKRs)

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.

Outcome

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, data or other system statistics

Back to top.

P

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.

Point of Departure

An activity for all the team to start a new project or piece of work which came from Hyper Island. Many teams adapt the original version to suit them.

A point of departure activity is only part of a wider kick-off event.

See Kick-off or inception.

View our guide to doing a kick off activity.

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.

Product

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 tools like a Kanban board 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

At Co-op, for some new products, the lifecycle we use is:

• discovery
• alpha
• beta
• live

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.

Prototype

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.

Q

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:

• achieve the set outcomes
• meet the acceptance criteria
• work within governance guidelines and governance principles

Back to top.

R

Rapid 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.

Retrospective

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

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.

Find out more about roles and responsibilities at the Atlassian playbook site.

Back to top.

S

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.

Scrum

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 blueprints

See service maps.

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.

Showcase

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

See show and tells.

Subject matter expert [SME]

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 to 250 employees.

Sprint

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

Stakeholders

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 to 15 minutes at the start of the day. They should happen at a time that suits the team.

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

View our guide to doing a stand up activity.

Storyboards

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.

T

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

Teams

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 a number of team members come together to agree on user stories or revisit their outcomes.

It is not always 3 people and can include any team members. It is different to other cross-functional team sessions because the focus is only on user stories and outcomes.

Tools

At Co-op we use tools 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 user stories or 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 or One Drive: for creating, commenting on and storing documents like week notes, case studies, early versions of content
• Calendar or 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

Back to top.

U

Users

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...(to do this step)

So that...(achieve a goal or outcome)

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.

Back to top.

V

Value chain

A business generates income by meeting user needs. Another way to say this: by delivering value to users, they give us money.

A value chain is all the activities we do in order to meet those needs. Businesses have lots of value chains for the products and services they provide.

An example: if we meet a user’s need to have lunch, the chain might be:

1. We buy sandwiches from a supplier, which delivers them to our warehouse.
2. Our trucks drive these to a Co-op store.
3. Our store colleagues move the sandwiches out onto the shelves.
4. A customer (the user) chooses a sandwich and takes it to a till.
5. Our store colleague takes their money.

By understanding the value chain, we can look at doing steps differently in order to achieve the more value with less cost.

Velocity

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

Vision

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.

W

Waterfall

The waterfall approach to project management 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.

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.