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).
Acceptance criteria are commonly used in agile for assessing whether a user story has been completed.
Those behaviours that are seen as typifying working in an agile way (e.g. being collaborative, self-organizing, customer-focused, empowered, trusting not blaming).
Agile plans may show features (or sets of features) in their order and dependencies, and are likely to have been created collaboratively by those who will carry out the planned work. Agile plans tend to be informal or low-tech at the delivery-team level and this can be highly effective even though they may be no more than to-do lists or backlogs. Product-based planning can still be used at all levels of the project (including product delivery).
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.
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. It is also a generic term that can be defined in terms of releases, sprints and products.
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.
A reference level against which an entity is monitored and controlled.
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.
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.
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.
A burn-down chart is a run chart of outstanding work. See also burn chart.
A burn-up chart is a run chart of completed work. See also burn chart.
A role in DSDM that is the pivotal role (but not the only role) in understanding the business view of a project. Sometimes known as a requirements engineer or business analyst.
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.
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.
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 because 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.
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 also configuration item.
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.
A restriction or limitation that a project is bound by. It may be challenged during an MoV study.
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).
customer subject matter expert
The role assigned to the delivery team, to act as a representative of all customer stakeholders, with a responsibility for ensuring that the project’s products are understood and are correct at the detailed level. Also referred to as customer SME.
definition of ‘done’
A set of criteria that is used to determine if a piece of work or a collection of work items is 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.
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).
A collaborative approach between development and operations aimed at creating a product or service where the two types of work and even the teams merge as much as possible.
See sprint zero.
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.
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.
A concept in agile that refers to creating solutions and making decisions in a way that gradually converges on an accurate solution and does not 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 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.
Evidence-based decision-making instead of reasoning or intuition.
A high-level definition of a requirement that has not yet been sufficiently refined or understood. Eventually, an epic will be refined and broken down into several user stories/requirements.
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).
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.
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 to improve something such as the way a team is working.
A generic term that is widely used to describe something a product does, or the way in which a product 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 be related to a specific requirement, user story or epic. Another similar term is ‘function’.
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.
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. It is more applicable in the context of project management than agile delivery.
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.
Glad! Sad! Mad!
This is a feedback technique that can be used by a team in a retrospective. Each team member writes one or more sticky notes and puts them into the appropriate column. This lets everyone else know what made them ‘glad’ during the last timebox, what made them ‘sad’ and what even made them ‘mad’.
A time-driven report from the project manager to the project board on stage progress.
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.
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.
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.
A way to improve flow and provoke system improvement through visualization and controlling work in progress. 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.
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.
An evolutionary approach to change described by David J. Anderson in Six Core Practices and Four Foundational Principles.
A ‘pull system’ implemented by limiting the number of Kanban (cards) in circulation.
A model, developed by Professor Noriaki Kano, which is used to help understand customer preferences. The Kano model considers attributes of a product or service grouped into areas such as basic factors, excitement factors and performance factors.
lead time/cycle time
These two terms are interpreted differently by many in the Kanban community (some see them as representing different things) but in simple terms they refer to how long a work item takes to go through the system or timebox. So although they are often interpreted differently, they are, in effect, the same thing.
An approach that focuses on improving processes by maximizing value through eliminating waste (such as wasted time and wasted effort).
Originally an approach to creating and managing start-up companies, but now applied to any business, to help them deliver products to customers quickly.
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).
L = ΛW
In simple terms, it is the average number of items in a system. L is equal to the average arrival rate, Λ, multiplied by the average time an item spends in the system, W (assuming that this is over a long enough period of time and the system is stable).
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 per cent.
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.
This technique is used to categorize items such as requirements or tasks into one of the four following levels of how they relate to a deadline:
- Must have
- Should have
- Could have
- Won’t have for now.
A four-stage cycle for process management, attributed to W. Edwards 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.
The period of time for which it is possible to plan accurately.
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.
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.
The role assigned to managing the product backlog in order to get the most value from it by ordering and prioritizing it.
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.
A temporary flexible organization structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits relating to an organization’s strategic objectives. A programme may have a life that spans several years.
A temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case.
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).
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 (PID) and its components. It is superseded by the PID 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.
Usually, a single event where visioning activities may take place and the team comes together for the first time. The event can be run as one or more workshops and requires preparation to ensure that time is used as effectively as possible. See also visioning.
The planning, delegating, monitoring and control of all aspects of the project, and the motivation of those involved, to achieve the project objectives within the expected performance targets for time, cost, quality, scope, benefits and risks.
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.
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 (PID). 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.
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.
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.
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.
The act of placing work into a system or activity without due regard to its available capacity. See also pull system.
An independent planned and systematic process. Quality assurance is used to provide confidence that outputs match their defined 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.
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.
A model used to help define roles and responsibilities. RACI stands for ‘responsible, accountable, consulted and informed’.
The set of products in a handover. The contents of a release are managed, tested and deployed as a single entity. In PRINCE2 Agile, a release is typically a container for more than one low-level timebox (e.g. a sprint). This is not always the case as the act of releasing features into operational use may happen more regularly (e.g. after each sprint or several times during a sprint). The term ‘deployment’ is sometimes used in agile and has a similar meaning, although it is not used in PRINCE2 Agile.
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.
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.
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.
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.
A record of all identified risks relating to an initiative, including their status and history. Also called a risk log.
SAFe (Scaled Agile Framework)
Large-scale application of agile across an organization.
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.
An iterative timeboxed approach to product delivery that is described as ‘a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value’.
This is a Scrum role that is responsible for ensuring Scrum is understood and enacted and that the Scrum team adheres to Scrum theory, practice and rules.
The application of Kanban or the Kanban method in the context of an existing implementation of Scrum.
The project board role accountable for ensuring that user needs are specified correctly and that the solution meets those needs.
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 (or 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.
A fixed timeframe (typically of 2–4 weeks) for creating selected features from the backlog.
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.
A detailed plan used as the basis for project management control throughout a stage.
A short meeting to assess progress. Typically lasting 15 minutes or less, they involve describing work that has been done, work still to be done and any problems being encountered.
supplier subject matter expert
The role assigned to the delivery team to provide the appropriate technical skills to build and initially quality-check the project’s products. Also referred to as supplier SME.
Acronym for ‘strengths, weaknesses, opportunities and threats’. A technique to determine favourable and unfavourable factors in relation to business change or current state.
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.
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.
The concept of writing tests or quality checks before building the product or sub-product as opposed to after.
A finite period of time during which 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 last a matter of days or weeks (e.g. a sprint). Higher-level timeboxes act as aggregated timeboxes and contain lower-level timeboxes.
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.
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.
A tool used to write a requirement in the form of who, what and why.
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 measures to prove whether the experiment has been successful).
The benefits delivered in proportion to the resources put into acquiring them.
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 is their velocity and it can be used to empirically forecast their future rate of progress (assuming that the conditions remain the same).
The statement of a desired future state.
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? See also project kick-off.
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)
Work that has been started but not yet delivered from the system or timebox. It can also indicate the 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.
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.
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.