AXELOS PRINCE2® Agile - Glossary (EN)

acceptance criteria :  A prioritized list of criteria that the project product must meet before the customer will accept it, i.e. measurable definitions of the attributes required for the set of products to be acceptable to key stakeholders (PRINCE2 definition).
The term is commonly used in Agile for assessing whether a user story has been completed.
agilometer :  The Agilometer is a tool that assesses the level of risk associated with using Agile in combination with PRINCE2. This allows PRINCE2 to be tailored in such a way that best mitigates the level of risk. The Agilometer should evolve to suit the needs of each organization.
backlog :  A list of new features for a product. The list may be made up of user stories which are structured in a way that describes who wants the feature and why.
backlog item :  An entry in a backlog. This may be in the form of a user story or task and may be held in many forms such as in a spreadsheet or displayed on a whiteboard.
baseline :  A reference level against which an entity is monitored and controlled.
benefit :  The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders, and which contributes towards one or more organizational objective(s).
benefits review plan :  A plan that defines how and when a measurement of the achievement of the project's benefits can be made. If the project is being managed within a programme, this information may be created and maintained at the programme level.
brainstorming :  A technique that helps a team to generate ideas. Ideas are not reviewed during the brainstorming session, but
at a later stage. Brainstorming is often used by problem management to identify possible causes.
burn chart :  A technique for showing progress (e.g. such as with a timebox) where work that is completed and work still to do is shown with one or more lines that are updated regularly/daily.
business ambassador :  A role in DSDM that is the pivotal role (but not the only role) in understanding the business view of a project.
business case :  The justification for an organizational activity (strategic, programme, project or operational) which typically contains costs, benefits, risks and timescales, and against which continuing viability is tested.
change authority :  A person or group to which the project board may delegate responsibility for the consideration of requests for change or off-specifications. The change authority may be given a change budget and can approve changes within that budget.
checkpoint report :  A progress report of the information gathered at a checkpoint, which is given by a team to the project manager and which provides reporting data as defined in the work package.
class of service :  Broadly defined category for different types of work. The classes influence selection decisions, in that different classes of service are typically associated with qualitatively different risk profiles, especially with regard to schedule risk and the cost of delay. Four generic classes of service are widely recognized: 'standard', 'fixed date', 'expedite' and 'intangible'.
communication management strategy :  A description of the means and frequency of communication between the project and the project's stakeholders.
configuration item :  An entity (asset) that is subject to configuration management. The entity (asset) may be a component of a product, a product or a set of products in a release.
configuration item record :  A record that describes the status, version and variant of a configuration item, and any details of important relationships between them. See configuration item.
configuration management :  Technical and administrative activities concerned with the creation, maintenance and controlled change of configuration throughout the life of a product.
configuration management strategy :  A description of how and by whom the project's products will be controlled and protected.
constraint :  A restriction or limitation that a project is bound by. It may be challenged during an MoV study.
contingency :  Something that is held in reserve, typically to handle time and cost variances, or risks. PRINCE2 does not advocate the use of contingency because estimating variances is managed by setting tolerances, and risks are managed through appropriate risk responses (including the fallback response that is contingent on the risk occurring).
definition of 'done' :  A set of criteria that is used to determine if a piece of work or a collection of work items are completed. Something is either 'done' or it is 'not done'
definition of 'ready' :  A set of criteria that is used to determine if a piece of work is ready to be started.
demonstration (demo) :  Short for 'demonstration' this is an event where a product or interim product, in whatever state of readiness, is shown to a person or group (e.g. to a customer) in order to get feedback and show progress. The product being 'demoed' could be static (e.g. a paper design) or dynamic (e.g. a working prototype).
DevOps :  DevOps is a movement, inspired by Lean methodology and Agile development practices, which aims to achieve seamless workflow for product synchronization between all possible organizational functions - especially development and operations groups. A DevOps approach tries to reconcile the different priorities and processes of these groups, all for the purpose of facilitating greater business agility and delivering more value to the end user.
discovery (phase) :  See sprint zero.
disruptive :  A widely used term that has more than one definition but in general terms refers to situations where there are high degrees of uncertainty (e.g. with product innovation) and the product being developed will significantly disrupt (intentionally or accidentally) the existing environment or marketplace (e.g. 3D printing).
Dynamic Systems Development Method (DSDM) :  An Agile project delivery framework developed and owned by the DSDM consortium.
early adopter :  A term given to a customer who is one of the first to buy or use a product. They typically may like innovative products and therefore may expect to pay more for them although these products may not be to a level of quality that later customers will receive. This type of customer is very useful for early feedback on the product.
emergent :  A concept in Agile that refers to creating solutions and making decisions in a way that gradually converges on an accurate solution and doesn't involve a lot of upfront work. The opposite would be to spend time and try to predict how things will happen. An example would be 'emergent architecture' whereby a lot of work could be done in advance to decide how the product will be built, or work could be started on the product and then the best architecture would emerge as the product develops.
empirical/empiricism :  Using evidence to make decisions as opposed to reasoning or intuition.
epic :  A high-level definition of a requirement that has not been sufficiently refined or understood yet. Eventually, an epic will be refined and be broken down in to several user stories/requirements.
exception :  A situation where it can be forecast that there will be a deviation beyond the tolerance levels agreed between project manager and project board (or between project board and corporate or programme management).
executive :  The single individual with overall responsibility for ensuring that a project meets its objectives and delivers the projected benefits. This individual should ensure that the project maintains its business focus, that it has clear authority and that the work, including risks, is actively managed. The executive is the chair of the project board. He or she represents the customer and is responsible for the business case.
experiment :  An investigation into something that is carried out in a series of specific steps (which may involve research) in order to prove or disprove a theory or idea. This can be used to validate an idea or to try and improve something such as the way a team is working.
feature :  A generic term that is widely used to describe something a product does, or the way it does something. A feature can be at any level of detail (e.g. it is waterproof, it makes a tone when switched off) and can relate to a specific requirement, user story or epic. Another similar term is 'function'.
flow-based :  This avoids the use of partitioning work into timeboxes and manages work by using a queue. Work is then continually pulled into the system (which may itself be a high-level timebox) and moves through various work states until it is done.
Gantt chart :  A commonly used technique for planning work activities against time in the form of horizontal lines or bars showing when the activities start and end. This can then be used to schedule dependencies between the activities. This is unlikely to be of use for a timebox or sprint where time is fixed and the work is ordered dynamically by the team.
gap analysis :  An activity that compares two sets of data and identifies the differences. Gap analysis is commonly used to compare a set of requirements with actual delivery.
highlight report :  A time-driven report from the project manager to the project board on stage progress.
information radiator :  A general term used to describe the use of walls or boards containing information that can be readily accessed by people working on the project. It can contain any information, although it would typically show such things as work to do and how work is progressing
issue :  A relevant event that has happened, was not planned and requires management action. It could be a problem, benefit, query, concern, change request or risk that has occurred.
iteration/iterate :  This term takes many forms in Agile and is perhaps best avoided when using PRINCE2 Agile as it may be a source of confusion. To some it refers to a form of low-level timebox like a sprint. To others it is either an aggregated timebox or a section of a timebox.
Kaizen :  A Japanese philosophy that literally means 'good change' but is widely understood to refer to continual improvement. It involves everyone contributing on a regular basis to make many small beneficial changes that build up over time to improve the efficiency of the way a team or organization works.
Kanban :  A term that often carries multiple meanings at the same time. Written in kanji (Chinese characters), it means 'sign' or 'large visual board.' Written in hiragana (Japanese characters) it means 'signal cards' (singular or plural). In technical presentations of the mechanics of Kanban systems it usually means the latter. Used informally, it refers to the use of Kanban systems (visual or otherwise) and the Kanban method.
Kanban board :  A tool used in Kanban to visually display the work in the system (or timebox). It is usually made up of a series of columns and possibly rows where work items move from left to right as they move through various states in order to be completed.
Kanban method :  An evolutionary approach to change described by David J. Anderson in Six Core Practices and Four Foundational Principles.
Kanban system :  A 'pull system' implemented by limiting the number of Kanban (cards) in circulation.
Kano :  A model, developed by Noriaki Kano, which is used to help understand customer preferences. The Kano model considers attributes of an IT service grouped into areas such as basic factors, excitement factors and performance factors.
lead time/cycle time :  Interpreted differently by many in the Kanban community (some see these two terms as representing different
things) but in simple terms it refers to how long a work item takes to go through the system or timebox.
Lean :  A management process aimed at eliminating waste in the supply chain.
lessons report :  A report that documents any lessons that can be usefully applied to other projects. The purpose of the report is to provoke action so that the positive lessons from a project become embedded in the organization's way of working and the organization is able to avoid the negative lessons on future projects.
level of quality :  The overall quality level of a product as defined by the project product description (customer's quality expectations and acceptance criteria).
manage by exception :  A technique by which variances from plan that exceed a pre-set control limit are escalated for action - for example, where spends exceed budget by 10%.
minimum viable product (MVP) :  In a PRINCE2 Agile context the term MVP broadly aligns with the Lean Startup view that it is a 'version of the final product which allows the maximum amount of validated learning with the least effort'. This should not be confused with the viability of the project as a whole. Typically, an MVP would be delivered as early as possible during the project.
It is important to note that an MVP is about learning and may not go into operational use; it may be in the form of a simple experiment or prototype.
Plan-Do-Check-Act (PDCA) :  A four-stage cycle for process management, attributed to Edward Deming. Plan-Do-Check-Act is also called
the Deming Cycle. Plan - design or revise processes that support the IT services; Do - implement the plan
and manage the processes; Check - measure the processes and IT services, compare with objectives and
produce reports; Act - plan and implement changes to improve the processes.
planning horizon :  The period of time for which it is possible to plan accurately.
product-based planning :  A technique leading to a comprehensive plan based on the creation and delivery of required outputs. The technique considers prerequisite products, quality requirements and the dependencies between products.
product description :  A description of a product's purpose, composition, derivation and quality criteria. It is produced at planning time, as soon as possible after the need for the product is identified.
product owner :  The role assigned to managing the product backlog in order to get the most value from it by ordering and prioritizing it.
product roadmap :  A diagram or document that shows the intended development path for a product. This would typically be a long-range plan that may cover several months if not years. It exists outside a project context but could be used to trigger project work.
project :  A temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case.
project assurance :  The project board's responsibilities to assure itself that the project is being conducted correctly. The project board members each have a specific area of focus for project assurance, namely business assurance for the executive, user assurance for the senior user(s), and supplier assurance for the senior supplier(s).
project brief :  Statement that describes the purpose, cost, time and performance requirements, and the constraints for a project. It is created pre-project during the Starting up a Project process and is used during the Initiating a Project process to create the project initiation documentation and its components. It is superseded by the project initiation documentation and not maintained.
project initiation documentation (PID) :  A logical set of documents that brings together the key information needed to start the project on a sound basis and conveys the information to all concerned with the project.
project kick-off :  Usually, a single event to start off a project where visioning may take place and the team comes together of he first time. These events can be run as workshops and require preparation to ensure that time is used as effectively as possible.
project manager :  The person with authority and responsibility to manage a project on a day-to-day basis to deliver the required products within the constraints agreed by the project board.
project plan :  A high-level plan showing the major products of the project, when they will be delivered and at what cost. An initial project plan is presented as part of the project initiation documentation. This is revised as information on actual progress appears. It is a major control document for the project board to measure actual progress against expectations.
project product description :  A special type of product description used to gain agreement from the user on the project's scope and requirements, to define the customer's quality expectations, and to define the acceptance criteria for the project.
project support :  An administrative role in the project management team. Project support can be in the form of advice and help with project management tools, guidance, administrative services such as filing, and the collection of actual data.
prototype :  Something created to help prove or disprove an idea, or to help to improve the general understanding of a situation (e.g. the customer's needs). It could be something that evolves into a real product or is thrown away.
pull system :  A way of working in which work is started or 'pulled' from upstream, but only as capacity becomes available. Kanban systems are pull systems. The availability of capacity and the ability to pull work is indicated by the gap between current work in progress and the corresponding limit. See also push system.
push system :  The act of placing work into a system or activity without due regard to its available capacity. See also pull system.
quality assurance :  The planned systematic process that will be used to provide confidence that outputs match their defined quality criteria.
quality criteria :  A description of the quality specification that the product must meet, and the quality measurements that will be applied by those inspecting the finished product.
quality review technique :  A quality inspection technique with defined roles and a specific structure. It is designed to assess whether a product that takes the form of a document (or similar, e.g. a presentation) is complete, adheres to standards and meets the quality criteria agreed for it in the relevant product description. The participants are drawn from those with the necessary competence to evaluate its fitness for purpose.
quality tolerance :  The tolerance identified for a product for a quality criterion defining an acceptable range of values. Quality tolerance is documented in the project product description (for the project-level quality tolerance) and in the product description for each product to be delivered.
RACI :  A widely used technique to define who is responsible for what on a project, or with a process. RACI typically stands for (who is) 'responsible, accountable, consulted and informed' with respect to certain deliverables or steps in a process. There are many variations of RACI that can be used instead.
release :  The set of products in a handover. The contents of a release are managed, tested and deployed as a single entity.
requirement :  A term to describe what a product does and/or how it will do it. A requirement can be written in the form of a user story if desired and will exist with other requirements in the form of a list.
retrospective :  A regular event that looks at how the process of doing work can be improved. In keeping with the Agile concept of 'inspect and adapt' these events help teams to continually improve their working practices, little by little, over time.
risk :  An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives.
risk log :  See risk register.
risk management strategy :  Describes the goals of applying risk management to the activity, the process that will be adopted, the roles and responsibilities, risk thresholds, the timing of risk management interventions, the deliverables, the tools and techniques that will be used, and the reporting requirements. It may also describe how the process will be coordinated with other management activities.
risk register :  A record of all identified risks relating to an initiative, including their status and history. Also called a risk log.
safe-to-fail :  A safe-to-fail experiment is one that is designed to have only limited impact on the system or the plan in the event of failure.
Scrumban :  The application of Kanban or the Kanban method in the context of an existing implementation of Scrum. In simple terms, it is Kanban, when the 'what you do now' is Scrum.
senior user :  The project board role accountable for ensuring that user needs are specified correctly and that the solution meets those needs.
sensitivity analysis :  A technique for testing the robustness of a calculation or model by assessing the impact of varying the input, to reflect the risk that the calculation or model might not be accurate.
spike/spiking :  A temporary piece of work used to understand more about a given situation. It may take the form of a prototype or some research and is often used to reduce uncertainty from a technical or customer viewpoint. Experiments are similar.
sprint :  A fixed timeframe (typically of 2-4 weeks) for creating selected features from the backlog.
sprint zero :  A specific sprint at the beginning of a piece of work in order to address many upfront activities (e.g. forming a team, visioning, defining the architecture). Also referred to as iteration zero or (the) discovery (phase).
stage (management stage) :  A PRINCE2 term that describes a section of the project that a project manager is managing at any one point in time. It is in effect a high-level timebox and will usually contain one or more lower-level timeboxes such as releases or sprints. The concept of a PRINCE2 stage does not have an exact equivalent commonly used in Agile.
stage plan :  A detailed plan used as the basis for project management control throughout a stage.
stand-up meeting :  A short meeting to assess progress. Typically lasting 15 minutes or less, they involve describing work that has been done, will be done and any problems being encountered.
SWOT analysis :  Acronym for 'strengths, weaknesses, opportunities and threats'. A technique to determine favourable and unfavourable factors in relation to business change or current state.
team dynamics :  The interpersonal interactions between the individuals on a team. This relates to the culture and attitudes of the people in the team and needs to be managed carefully as it can be a very positive and powerful force when it is working well, but it can be destructive when it breaks down.
team manager :  The person responsible for the production of those products allocated by the project manager (as defined in a work package) to an appropriate quality, timescale and at a cost acceptable to the project board. This role reports to, and takes direction from, the project manager. If a team manager is not assigned, then the project manager undertakes the responsibilities of the team manager role.
test-driven :  The concept of writing tests or quality checks before building the product or sub-product as opposed to after.
timebox :  A finite period of time where work is carried out to achieve a goal or meet an objective. The deadline should not be moved, as the method of managing a timebox is to prioritize the work inside it. At a low level a timebox will be a matter of days or weeks (e.g. a sprint). Higher-level timeboxes act as aggregated timeboxes and contain lower-level timeboxes (e.g. stages).
tolerance :  The permissible deviation above and below a plan's target for time and cost without escalating the deviation to the next level of management. There may also be tolerance levels for quality, scope, benefit and risk. Tolerance is applied at project, stage and team levels.
trading (or swapping) :  The act of handling change by replacing one or more requirements (or features or user stories) with others of
a similar size in terms of effort.
transparency :  A fundamental Agile behaviour which involves making as many things visible as possible in order to help the way people work. This can involve displaying progress on a wall or the frequent delivery of products. Importantly, transparency also covers areas such as openness and honesty.
user story :  A tool used to write a requirement in the form of who, what and why.
validated learning :  The idea of learning through the use of experiments carried out in a scientific way: i.e. using a series of carefully designed steps and using measures to prove the success or otherwise of the experiment.
value :  The benefits delivered in proportion to the resources put into acquiring them.
velocity :  A description of the rate of progress a team is making. For example, if a team is completing 20 user stories per week then this their velocity and it can be used to empirically forecast their future rate of progress (assuming that the conditions remain the same).
vision :  The annunciation of a desired future state.
visioning or project kick-off :  An exercise or phase that aims to understand the overarching goal of something (e.g. a project). It would try to answer questions such as: Why is this work taking place? Who is it for? What might it look like?
Waterfall method :  A development approach that is linear and sequential, with distinct goals for each phase of development. Once a phase of development is completed, the development proceeds to the next phase and earlier phases are not revisited (hence the analogy that water flowing down a mountain cannot go back).
work in progress (WIP) :  A status that means activities have started but are not yet complete. It is commonly used as a status for incidents, problems, changes etc.
work-in-progress (WIP) limit :  A constraint on the amount of WIP allowed in a given part (or column) of the system at any one time. Typically expressed as a number (i.e. the maximum number of work items allowed), it creates the concept of a pull system.
work package :  The set of information relevant to the creation of one or more products. It will contain a description of the work, the product description(s), details of any constraints on production, and confirmation of the agreement between the project manager and the person or team manager who is to implement the work package that the work can be done within the constraints.
workshop :  An event where people come together in a room to achieve an objective (e.g. to create a list of requirements or solve a problem) by using interaction and creativity in order to work quickly and accurately. It is not related to light engineering.