Below you will find an overview of the most important terms of Scrum and Agile Project Management, which I used on my website and in my books. These are aligned with the Scrum Guide 2020.
Accountable – Responsible is the person who is expected or required to do a work. Accountable is the person who ensures that the work is done and done correctly.
Agile Manifesto – The Manifesto defined in 2001 is the basis of all agile approaches and describes the core agile values.
Agile Principles – The Agile Manifesto is based on 12 principles, which every user of agile methods is committed to adhere to.
Agile Values – These are the essential basic values for successful, agile project management. In summary: More flexibility, fewer structures, more productive cooperation. (see also Agile Manifesto).
Acceptance Criteria – Each backlog item (user story) has acceptance criteria. These are part of the completion criteria (Definition of Done) and are used by the Product Owner in the review of the finished user story.
Artifact – Artifacts are the results of activities in the software development process. Central Scrum artifacts are: Product Backlog, Sprint Backlog and the (shippable) Product Increment.
Burndown-/Burnup-Chart – A chart with which the Developers visualize the remaining work in the Sprint in relation to the remaining time in the Sprint. It shows the Sprint progress. It can be used at project, release and Sprint level.
Business Value – It is the (usually financial) value of a backlog item for a company or the customer. The Product Backlog is usually sorted so that items with the highest business value are developed first.
Commitment – In Sprint Planning, the Developers are commited providing a “forecast” of which backlog items will be implemented in the next Sprint. But commitment also includes commitment to the team, to quality, to cooperation and to learning. Commit to doing the best I can—every day.
Chief Product Owner (CPO) – Is the scaled role of the Product Owner in Scrum@Scale. He is responsible for the overall product, the product vision and the overall Product Backlog of the project. The CPO coordinates priorities among Product Owners who work with individual teams in the Meta Scrum.
Daily Scrum – Is a 15-minute meeting where the Developers synchronize its activities and works on planning for the next 24 hours. It is often held as a stand-up meeting.
DEEP – According to Mike Cohen, a good Product Backlog is DEEP. This means: Detailed, Estimated, Emergent, Prioritized.
Definition of Done (DoD) – Is the agreement of an agile team on what needs to be done in order for a feature to be considered completed. The DoD is a list of completion criteria.
Definition of Ready (DoR) – A list of criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration. In contrast to the DoD, the Product Owner is responsible for compliance with the DoR.
Developers – The Developers carry out all work to convert the requirements into a usable Product Increment. They work self-managed.
DevOps – Close collaboration between development and operations in an agile environment and automation throughout the lifecycle enables releases to be delivered faster, of higher quality, at lower cost and at lower risk.
Documentation – This is also necessary and helpful in agile projects. However, the principles of the Agile Manifesto take precedence (Working software over comprehensive documentation).
Done – In Scrum it is strictly distinguished between “not finished” and “finished”. A backlog item is considered “Done” when all tasks are completed and the criteria of the Definition of Done are fulfilled.
Epic – Is a coarse granular requirement (large user story) that is too large or too complex to be implemented in a Sprint. Later, when the customer requirements are clearer and more details are known, it is divided into user stories in the Product Backlog.
Estimation – This usually means estimating the effort of Product Backlog items or user stories. Estimation methods are usually Planning Poker and Magic Estimation.
Estimation Meeting – The Estimation Meeting (also called Backlog Refinement) is the planning meeting with the Product Owner to get clarity for the next Sprint. The aim here is to clarify details, estimate effort and check the prioritization.
Event – See Scrum Event.
Extreme Programming – This is an agile software development method, which was mainly developed by Kent Beck. It follows the five central agile values: communication, simplicity, respect, feedback and courage.
Feature – Is a functional property of the product to be developed.
Forecast – The Developers provide a forecast in Sprint planning which backlog items it will implement in the next Sprint.
Impediment – Are problems of any kind that hinder the Developers in the effective execution of their work.
Impediment Backlog – Is a public work list of the Product Owner hanging in the team room with all impediments.
Increment – An increment is part of a whole. A Product Increment in Scrum is the result of a Sprint, as a finished part of the whole product.
Inspect & Adapt – A principle of continuous improvement. The own work is checked at regular intervals and, if necessary, the work processes are adapted in the next iteration.
INVEST – Good user stories meet INVEST criteria. They are: (I) Independent, (N) Negotiable, (V) Valuable, (E) Estimable, (S) Small, (T) Testable.
Iteration – A period of time during a Product Increment is developed. In Scrum this is called “Sprint”, which always has the same duration.
Iterative incremental – In Scrum, this technique is used to create software through short feedback cycles. Iterative (in individual Sprints), increments (finished product parts) are supplied.
Customer – Is the person/company who orders the product result (the client, project sponsor) and also pays for it. He determines what the product should achieve.
Lean Management – Is a management philosophy that includes thinking principles, methods and procedures for the efficient design of the entire product value chain.
Magic Estimation – Similar effort estimation method for user stories like Planning Poker®, but much more efficient.
Manager – (Line) managers are also important stakeholders in Scrum projects. They can support the project and remove obstacles, but also create an environment in which agile principles and projects can develop.
MetaScrum – In Scrum@Scale, this is the scaled version of the Backlog Refinement Meeting of the Product Owners. The PO’s coordinate a backlog themselves, which then feeds a Scrum of Scrums (SoS). For each SoS there is an associated MetaScrum.
Minimal Marketable Feature (MMF) – The smallest possible number of functions that can be marketed on their own. Software that has only one of these features has a benefit for the user for whom he would pay.
Minimal Viable Product (MVP) – The Minimal Viable Product is the minimum number of features that are necessary to find out what a customer wants. It is a strategy to get quick and broad feedback from the customer without working out the product to market maturity.
MuSCoW – The MuSCoW method is a prioritization technique for classifying backlog items roughly into four categories: Must have, Should have, Could have, Won’t have.
PBI – Product Backlog Item. An element in the Product Backlog
PDCA Cycle – Is a four-step management process used for continuous improvement in software development: Plan (P), Do (D), Check (C) Act (A).
Planning – see Sprint Planning
Planning Poker® – Is a technique for estimating backlog items in Estimation Meetings. It is particularly important that the size of a feature is estimated and not the effort involved.
Product Backlog – The Product Backlog is a list of requirements (or user stories) that will be implemented in the current project. The Product Owner makes it available, prioritizes, takes responsibility for it and maintains it together with the Developers.
Product Increment – Is executable, tested and documented software that implements requirements from the Product Backlog. The Product Increment is the result of a Sprint.
Product Owner – The Product Owner is responsible for the economic success and the “What” in the Scrum project. He plans and controls the development in Scrum. He is the owner of the Product Backlog, prioritizes it and determines which features are implemented when.
Product Owner Team – A group of Product Owners who need to coordinate a shared Product Backlog that feeds a network of teams. For each SoS there is an associated Product Owner Team which aligns the teams’ priorities along a single path.
Product Backlog Item (PBI) – This is a requirement usually described in a user story. It is a work unit small enough for the Scrum Team to complete it in a Sprint.
Product Backlog Refinement – This is how the ongoing maintenance of the Product Backlog is called (see also Estimation Meeting).
Product Vision – The product vision is created by the Product Owner before the first Sprint. It leads the Scrum in the right direction and is an overarching goal that everyone must share, the Scrum Team, the customer and the stakeholders. The vision describes why the project is being undertaken and what the desired final state is.
Release – Is a software version that can be used productively by the user. One or more releases are the result of the Scrum project.
Release-Burndown-Chart – This is a burndown chart that shows how many story points still need to be implemented until the end of each release.
Release Planning – Is the medium-term planning of the project and gives the customer an overview when he will receive which functionalities.
Requirements – Requirements are usually defined in a user story in Scrum. This is why most people talk about user stories and not about requirements.
Requirements list – see Product Backlog
Scaled Daily Scrum (SDS) – Is an event of Scrum@Scale. For large projects, the SDS event reflects the Daily Scrum by optimizing the collaboration and performance of the network of Scrum Teams.
Scrum Events – There are five events in Scrum. Four are meetings of the Scrum Team: Sprint Planning, Daily Scrum, Sprint Review, Sprint-Retrospective and the fifth is the Sprint itself.
Scrum Guide – Published and regularly updated by Ken Schwaber and Jeff Sutherland and describes the official Scrum basics.
Scrum@ScaleTM Guide – Published by Jeff Sutherland and Scrum Inc. and describes how Scrum can be easily scaled. The first version was released in February 2018.
Scrum Master – The Scrum Master is a Scrum role. He helps to apply Scrum correctly, supports the team and ensures optimal cooperation between Product Owner and the Developers. The Scrum Master removes impediments and helps the team to continuously increase its maturity and productivity.
Scrum of Scrums (SoS) – Is a team of Scrum Masters and other necessary skills of the involved Scrum subprojects. An SoS acts as a release team and must be able to directly deliver value to the customer.
Scrum of Scrums Master (SoSM) – Is a role of Scrum@Scale. The Scrum of Scrums Master (SoSM) is accountable for the release of the joint teams’ effort.
Scrum-Roles – These are: Product Owner, Scrum Master, Developers.
Scrum-Team – Consists of the three Scrum roles: Product Owner, Scrum Master, Developers.
Scrum-Values – Scrum is based on five values: commitment, courage, focus, openness and respect. When these values are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection and adaptation come alive and build trust among all participants.
Self-managing – Is an essential characteristic of Scrum Teams. The team organizes its work by itself. Decisions are made in the team, the team agrees on team-internal rules and working methods. Only the achievement of the Sprint goal is a yardstick for the team.
Selected Product Backlog – see Sprint Backlog.
Servant Leadership –The Scrum Master is a leader who serves the Scrum Team. This means that although he has influence, he has no authority over the organization of work in the team. He acts as coach and change agent.
Sprint – In Scrum iterations are called Sprint. A Sprint has a fixed duration in which the Developers converts the customer’s requirements into functional software.
Sprint Backlog – In Sprint Planning 1, the Developers decide how many of the highest prioritized backlog items it wants to implement in the following Sprint. The selected items (Selected Product Backlog) are then the Sprint Backlog for the upcoming Sprint. The Sprint Backlog corresponds to the forecast of the Developers, what they want to achieve together in the upcoming Sprint.
Sprint Burndown Chart – see Burndown Chart
Sprint Planning Meeting – The Sprint Planning Meeting takes place at the beginning of a Sprint and consists of two parts. Both meetings last a maximum of four hours each for a 4-week Sprint.
In the first part, the Scrum Team defines the Sprint Backlog, which means WHAT it wants to do in the next Sprint. In the second part, the implementation details, the HOW, are clarified. At the end of the Sprint planning all user stories (WHAT) and the corresponding tasks are displayed on the taskboard.
Sprint Retrospective – Is performed after each Sprint Review. The Sprint and the events are analyzed and actions for the next Sprints are defined with the aim of constantly learning and improving.
Sprint Review – Takes place at the end of each Sprint with the aim of presenting the results to the Product Owner, the customer and the stakeholders in order to receive feedback. The Product Owner checks whether the Developers have implemented all user stories according to the forecast.
Sprint Cancellation – The Product Owner can cancel a Sprint if he sees that the Sprint goal cannot be reached or no longer makes sense. In this case, a Sprint Review is performed and all completed “Done” Product Backlog entries are reviewed and, if useful, approved by the Product Owner.
Sprint Goal – The Sprint goal is defined by the Product Owner and describes the Product Increment to be delivered—preferably in one sentence. This is what the Product Owner wants to deliver to the customer at the end of the Sprint.
Stakeholder – Stakeholders are people who are affected by or interested in the project result but do not actively participate in the project, e.g. users, customers, sales, marketing, managers.
Sprint 0 – This is often referred to as an initial Sprint. It is usually shorter than a normal Sprint and produces no business value. Here, for example, the product backlog is prepared, the infrastructure set up, architecture questions clarified, and rules defined as to how the Scrum Team works together.
Story – see User Story
Story Card – Describes a backlog item (user story) on an index card with a maximum of two sentences. On the front is also the business value and the effort in story points. On the back are e.g. the acceptance criteria and the test strategy.
Story Point – Story Points are an abstract unit used to evaluate the effort (size) of a backlog item, always relative to another story. The effort can only take certain predefined values, which usually correspond to the Fibonacci sequence.
Task – In Sprint Planning, the Developers define the tasks which are needed to implement the user stories. These are then attached to the taskboard next to the user stories.
Taskboard – The taskboard visualizes the Sprint Backlog. It shows at any time, which Product Backlog items have been selected for the Sprint, which associated tasks have to be performed, and in which completion state these tasks are.
Team – see Scrum Team
Timebox – All Scrum events have a time limit (Time Box). The event is terminated after a certain time, even if the content has not yet been completed. The aim of the timebox is to avoid waste in order to focus on the really important things in the Sprint.
User – The user is the person who uses the project result. Scrum places the delivery of functionality for a user in the foreground, not the fulfilment of tasks. It is a proven method to describe the backlog items from the user’s point of view in a user story.
User Story – Product backlog items (PBI), requirements or features, are usually described in user stories. User stories describe requirements from the user’s perspective. User stories are written in a special format: As <role> I want to <goal/wish> to achieve <benefit/reason>.
Velocity (of development) – The sum of all story points that the Scrum Team has implemented in a Sprint. Over time, the velocity levels off to a relatively stable value. Knowing the velocity is important for the Product Owner so that he can create the release plan and adjust it during the course of the project
Vision – see Product Vision
Values – see Scrum Values
Here You Can Find More Knowledge
Would you like to learn more about how to make your agile projects even more successful? My book How to Successfully Apply Agile Project Management and Scrum takes you an important step further!