Agile working is totally new to you?

You can't make head or tail, when others talk of review, incremental and Sprint Goal?
In agile talk, when it's a question of creating transparency and constantly improving processes, communication is the be-all and end-all. That makes it all the more important to speak the same language within the teams.

We have put together the most important terminology for you so that when it comes to sharing agile, you'll be an ace before you know it.

We name it the AYKEYwords.

Agile gobbledygook

Do you already know what you're looking for?


Scrum defines three specific responsibilities – so-called accountabilities – within scrum teams: the developers, the Product Owner and the Scrum Master.

Third pillar of Scrum:
The empirical process asserts that teams also become active following knowledge gained through transparency and inspection

The Agile Manifesto is the basis for agile project management and was published in 2001 by Kent Beck, Ken Schwaber, Jeff Sutherland, Alistair Cockburn and 13 other authors. It comprises four principles:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan 

The four principles defined in the Agile Manifesto are executed more extensively as per twelve principles. They describe by which values companies and their employees and teams are guided in agile work.   

Agility is the ability of an organisation, to work both flexibly (in the sense of reactively) and proactively as well as anticipate the increasingly changing framework conditions in the corporate environment and to take the initiative in order to introduce necessary changes and adapt to ever changing markets.

Scrum artefacts help the Scrum framework run smoothly, since they ensure and guarantee a gapless and continual exchange of information and an optimum degree of transparency regarding work carried out. In the Scrum Guide there are 3 Artefacts: Sprint Backlog, Product Backlog and the created Product Increment

THAT'S WHO WE ARE - Respectful, courageous, open, committed, focused. We move your company forward. 


Collections of topics to be processed. The best well known are Product Backlog and Sprint Backlog.

An entry in the backlog is described as a Backlog Item. This corresponds to an individual  implementation requirement. In agile practice it is often called the User Story.  

The checking and improving of contents in the Backlog. Procedure is mostly systematic and an entire Backlog is checked and improved.

A procedure, method or tool, which has proven itself to be especially well suited in use. This exists only in the simple domain (see Cynefin Framwork).

A graphic, which shows how much is completed within one time unit (within a Timebox). The Story Points are usually shown each day within a Sprint


The Scrum Team makes a group commitment to reach its goals for the current Sprint and to support each other. Since each team member makes a commitment, there is a greater chance that plans made are actually realised. 

The Scrum Team should be courageous in developing its own ideas and acting independently

Cross-functional teams are like super hero teams in which various persons with diverse, unique skills work together towards a common goal. That means that the team unites all necessary skills needed in order to develop a specific product.

The customer is the one who the product is developed for (in Scrum); hence he is also a (specific) stakeholder

The Cynefin Framework is a model for classifying tasks in terms of complexity, problems and situations and supports decision making and strategy planning in further procedure towards providing solutions. 
Classification is in five areas: "simple, complicated, complex, chaotic and in turmoil". Various recommended actions are added to each of these, . 


At the Daily (Scrum) the Development Team meets in order to present what individuals are working on, what the current challenges are and what the plan is for the following day. As the name indicates, this meeting takes place daily. It is usually restricted to 15 minutes. 

This describes in advance when a User Story is considered finished with regard to generally applicable quality criteria. The DoD is defined by the Scrum Team, fixed in writing, made available to everyone and can be sharpened in the retrospective.

Once the User Story has been written it should also be realised. In order to guarantee a certain quality which allows the Development Team to realise this without too much effort, a Definition of Ready (DoR) is used which is cross functional for all User Stories. Rules determine which specifications a User Story must follow. 

The Development Team is made up of experts, who work together in the course of a Sprint on part of a product. The team organises itself and is responsible for the result of its work. It decides completely autonomously how much work it takes from the Product Backlog. It also self determines which tasks it takes on. While the Product Owner decides on the “What“, the  Development Team decides on the “How“.


An Epic is a big Feature, which can be completed over several Sprints. An Epic itself can also be a User Story. One which is so big that it has to be split up into several smaller User Stories. In a project, an Epic is designed to summarise certain requirements and functions.  

Estimations of expenses for functionalities to be developed (Features, User Stories) according to complexity (and not in person days). There are various possibilities for estimating  e.g. Planning Poker, Magic Estimation, T‑Shirt Sizes etc.


Features designate the features or functions (as requested by users) of the product to be created.

The (Scrum-) Fibonacci Sequence is used in Backlog Refinement, in order to assess Backlog Items with Story Points. The adapted sequence is: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. 

The value "Focus" signals that the Scrum Team is focussed on the Sprint Goal and is not at the same time trying to deal with as many other issues as possible. 


A procedure, method or tool, which has been proven to work very well. This exists only in the complicated domain (see Cynefin Framwork).


An Impediment handicaps the team in its work. It's the task of the Scrum Master to support the team in removing the impediment (help for self-help). These can be chartered in the Backlog and discussed in the Sprint Retrospective

With an incremental process the product is developed and delivered in individual parts. Each of these parts – so-called increments – represents an individual and complete functionality of the end product. Incremental is generally defined by a process built on previous findings. This follows the goal of an ongoing product enhancement. 

Second pillar of Scrum: 
The progress and results attained are regularly checked to see whether they meet the Sprint Goals

Iterative describes a project process, which happens in repeated phases and cycles – so-called iterations. Improvements are made on the product step by step, until the results match the Definition of Done and a deliverable Increment can be delivered. 


LeSS is a Framework for the scaling of Scrum in several teams who work together on a product. The LeSS framework aims to use the principles and ideals of Scrum in a broad corporate context as simply as possible through defined rules and directions. 


An MVP, i.e. a "minimally viable product“, is the first minimally functionable Iteration of a product which serves to learn as fast as possible from user feedback and hence avoid undesirable developments in connection with user demands.  


Thoughts, ideas and topics are openly shared in the team in the spirit of "Transparency". Hegemonic knowledge or secrets are kept as minimal as possible.  Mistakes are dealt with openly. 


Methodology for estimating User Stories according to complexity by the Development Team in Sprint Planning with the help of “Poker cards”. Each team member evaluates the User Stories for the current Sprint with the help of Story Points, which are displayed as Fibonacci Sequence on Planning Poker Cards. The highest and lowest estimator discuss the expense for so many rounds until they reach consensus on the estimate. This helps the Development Team to check whether or not too many stories have been included in the Sprint. Additionally, the velocity of the teams can be measured in terms of the Story Points

The Product Backlog is a list of all functions, which is designed to feature the end product. The functions in the Product Backlog are termed in Scrum as a Backlog Item. They are ordered in the sequence according to priority and can be extended any time by the Scrum Team. They may mature or change, as and when new findings are made. The Product Owner is responsible for maintaining the Product Backlog. The Sprint Backlog is compiled from the highest prioritised Product Backlog Items at the start of a Sprint (in Sprint Planning). 

The Product Owner is responsible for the "What" and hence responsible for maximising the value of the product. Additionally he acts as interface between internal and external stakeholders and the Scrum Team. He manages the Product Backlog, defines the requirements and acceptance criteria, writes and prioritises the Product BacklogItems and is responsible for economic success. 


The Scrum Team communicates respectfully with each other and acts accordingly. Its strength lies in the cooperation among themselves.


The Sprint and the four meetings (Sprint Planning, Daily Scrum, Sprint Retrospective, Sprint Review) are summarised in the Scrum Guide as Scrum Events.

Authored by Ken Schwaber and Jeff Sutherland, the Scrum Guide is a continually updated manual for the Scrum agile framework. First appearing in 2010,  it has since been updated five times (most recently 2020). Although the Scrum Guide has no “binding character” it forms the basis for all Scrum literature, definitions and certificates.

The Scrum Master is responsible for seeing that the Development Team can work according to the Scrum Process. He gets rid of Impediments, encourages collaboration and monitors the methodology. 

Daily Scrum, Sprint Planning (1 + 2), Sprint Review and Sprint Retrospectives are summarily termed as meetings. Together with the Sprint, the term Scrum Events is used, as per Scrum Guide.  

The Scrum Process describes the set-up and sequence of Artefacts and events described in the Scrum Guide.  

The Scrum Team consists of the Product Owner, the Development Team and the Scrum Master. Since the Development Team should, as per Scrum Guide, ideally consist of 3 to 9 persons, this makes a group size of 3 to 11 persons.

The five Scrum Values are, as per Scrum Guide: courage, commitment, focus, openness, and respect. They form the basis of successful working with Scrum.

Self organisation is an indispensable character of the Development Team. The team thus decides independently how upcoming tasks, challenges and obstacles can be dealt with without external intervention.  

Sprint is defined as the timeboxed period in which a cycle is processed in a Scrum. It is an event with a fixed length of a month or less. The Sprint length is fixed before the project begins and should then not be changed. The goal of each Sprint is to develop a functionable Increment.

The Sprint Backlog is a plan by and for the developers. It is an easily visible real-time picture of the work, which the developers plan to do during the Sprint in order to achieve the Sprint Goal. As a result, the Sprint Backlog is updated during the Sprint as and when new knowledge is gained. 

Cancellation of the Sprint, in order to start it again from scratch. The Sprint Cancellation is meant to be an exception and can only be ordered by the Product Owner. Typical reasons are completely wrong estimations, wrong estimations for the cost of realisation, or massive disharmony in the Development Team

The result which should be achieved in a Sprint. The Sprint Goal is fixed by the Scrum Team at the start of the Sprint

A meeting in Scrum, at the start of which planning for the Sprint can be carried out. Can be subdivided into Sprint Planning 1 (strategic, rough) and Sprint Planning 2 (tactical, detailed). In Sprint Planning the Sprint Goal is also fixed. 

A Scrum meeting which concludes each Sprint. The team reviews the Sprint with regards to methodology, interactions and processes and works on improvements

The aim of the Sprint Review is to assess the Sprint and determine future adaptations. The Scrum Team presents to the Stakeholders the most important results of their work and the progress in relation to the product goal is discussed. During the event the Scrum Team and the Stakeholders inspect the outcome of the Sprint and what has changed in their environment. On the basis of this information the participants collaborate on what is to be done next. 

Stakeholder is the term used for all who are not part of the Scrum Team, yet are interested in the development of the product or gaining necessary knowledge of the product. 

Stakeholder Management is designed to determine the needs of the most important interest groups and take these into consideration when planning and carrying out the project, in order to steer it clear of dangers. In Scrum the Product Owner is responsible for the Stakeholder Management. 

Each User Story (chosen for a Sprint) is written on a Story Card. The Story Card carries a rough description of the functionality and delivery criteria, from which the test cases and the estimated Story Points can be derived. The Story Card to be used in a Sprint is hung on the Task Board.

The effort for implementing the User Stories is estimated by the Development Team in Story Points. This is used to calculate the Velocity of the Development Team, so that  the Product Owner knows the respective value and can prioritise the Backlog


Scrum uses tasks in order to identify small tasks which are then carried out by a member of the Scrum Team during the Sprint. In order to make these tasks more visual, they are written on a card or a post-it and organised on a Task Board

The status (mostly To Do, In Progress, Done) of a task (Task, User Story) is visualised on the Task Board. This is mostly a whiteboard, onto which the tasks on cards are pinned.

Fixed period/fixed Timebox. All events in the Scrum are timeboxed — hence the length of the Sprint is always the same (1-4 weeks), and the Daily Scrum always 15 minutes etc. 

First pillar of Scrum: 
All information relevant for the result of the product development must be transparent for all involved. 

Rough, comparative estimation scale on the basis of T-Shirt Sizes: S — M — L (three levels) or XS — S — M — L — XL (five levels)


The person or group, which uses or will use the planned product (or Feature). 

A User Story describes a requirement in a project which can be summarised in short simple sentence. This sentence is formulated in such a way that everyone can understand and hence contains no technical information: As (role) I would like (aim/wish), in order to (use). User Stories are usually stored in the Product Backlog and, in turn, broken down into Tasks for the Sprint in the Sprint Backlog.


Velocity is a measurement for the (implementation) speed, at which a Development Team implements the contents of the Backlog. It is given in Story Points.


In classic project management, the project is divided into several phases of differing contents. One phase follows the other – a phase can only begin when the previous phase is finished. The product or the project result is delivered after the final phase is completed.