The acceptance criteria are a prioritized list of attributes that the project product should have when complete. This is agreed between the customer and supplier in the very first process – the starting up a project process, and is therefore linked to the project product description. Acceptance criteria are commonly used in agile for assessing whether a user story has been completed.
These are behaviours such being collaborative, self-organizing, customer-focused, empowered, trusting not blaming.
Agile plans may show a list of products or features (or sets of features) in their order and dependencies and perhaps show who will carry out the work. Agile plans tend to be informal and visual. Product-based planning can still be used at all levels of the project (including product delivery).
This is a PRINCE2 Agile term. The PRINCE2 Agile manual states the the Agilometer is a tool that assesses the level of risk associated with using agile in combination with PRINCE2 but not sure if this is used much.
A list of new features (or products) for the main project product. The list may be made up of user stories which are structured in a way that describes who wants the feature and why. A backlog is also an accumulation of uncompleted work or matters needing to be dealt with.
A unit of work and 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. It should be small enough to be completed by a team in one Sprint iteration
Reference levels against which an entity is monitored and controlled or a point of time for a product against which the product 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). See email benefits interview with Dmitry Ilenko
Benefits management approach:
An approach that defines the benefits management actions and benefits reviews that will be put in place to ensure that the project’s outcomes are achieved and to confirm that the project’s benefits are realized. It is created in IP process and is used during and after the project.
A general technique that helps a team to generate ideas. It is best not to review ideas in detail 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 are shown with one or more lines that are updated regularly or daily. A burn chart in an information radiator
- A burn-down chart is a run chart of outstanding work. See also burn chart. burn-up chart
- A burn-up chart is a run chart of completed work. See also burn chart.
A role in DSDM (AgileBusiness) 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. See AgilePM.wiki for more information.
This is a document that explains the reasons for the project, in terms of cost, risks, and benefits. It explains in detail why the project should be done and why the final outcome is desired. During the project lifetime, whenever a risk appears, the odds should be weighed against the business case to check if the benefits still exist within the expected time and cost constraints. This is an example of a business case for a P3X sample project.
Change authority is a person or group to which the project board may delegate responsibility for the consideration of requests for change or off-specifications, and this role is part of the project management team. The change authority may be given a change budget and can approve changes within that budget. See Change Authority role on PRINCE2.wiki
Change control approach:
A description of how and by whom the project’s products will be controlled and protected. This is one of the five approach documents created in the IP process by the project manager. Link to Change Control Approach template
A progress report of the information gathered at a checkpoint which provides reporting data as defined in the work package. Checkpoint reports are created regularly by the team manager to keep the project manager informed on the progress of the work packages. Link to Checkpoint Template
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 approach A description of the means and frequency of communication between the project and its stakeholders.
Configuration item An entity that is subject to configuration management. The entity 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. Click here for a configuration item record template
Configuration management Technical and administrative activities concerned with the controlled change of a product.
Constraints: The restrictions or limitations by which a project is bound.
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).
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 product (and its components) is understood and is 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.
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 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. 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 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. empirical/empiricism Evidence-based decision-making instead of 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 broken down into several user stories or requirements. exception A situation where it can be forecast that there will be a deviation beyond the tolerance levels agreed between the project manager and the project board (or between the project board and corporate, programme management or the customer).
executive The 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 to 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 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’.
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. It is more applicable in the context of project management than agile delivery.
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.
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’.
Highlight report A time-driven report from the project manager to the project board on management stage progress. Click here for highlight report template
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 can be any concern, query, request for change, suggestion or off-specification raised during a project. Project issues can be about anything to do with the project. Click here to view the issue register template, Click here for issue report template
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 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.
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 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.
Lean An approach that focuses on improving processes by maximizing value through eliminating waste (such as wasted time and wasted effort).
Lean Startup Originally an approach to creating and managing start-up companies, but now applied to any business, to help them deliver products to customers quickly.
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. Click here for lessons log template.
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 (e.g. 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.
MoSCoW 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.
Plan-Do-Check-Act (PDCA) 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.
Planning horizon The period of time for which it is possible to plan accurately.
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.
Product-based planning An approach for developing a comprehensive plan based on the creation and delivery of required outputs. The approach considers prerequisite products, quality requirements and the dependencies between products.
Programme 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 related to the organization’s strategic objectives. A programme is likely to have a life that spans several years.
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 A statement that describes the purpose, cost, time and performance requirements, and constraints for a project. It is created before the project begins, during the starting up a project process, and is used during the initiating a project process to create the PID and its components. It is superseded by the PID and not maintained. Click here to access the project brief template
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 that conveys the information to all concerned with the project. Click here to view the project Initiation documentation template
Project kick-off 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.
Project management 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.
Project manager The person given the authority and responsibility to manage the project on a day-to-day basis to deliver the required products within the constraints agreed with 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 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 the acceptance criteria for the project. Click here to view the project product description template
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 A planned and systematic process that provides confidence that outputs will match their defined quality criteria when tested under quality control. It is carried out independently of the project team.
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 (QRT) A technique with defined roles and a specific structure, designed to assess whether a product in the form of a document (or similar, such as 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 model used to help define roles and responsibilities. RACI stands for ‘responsible, accountable, consulted and informed’.
Release 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.
Requirement- User 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 management approach An approach describing the goals of applying risk management, as well as the procedure that will be adopted, roles and responsibilities, risk tolerances, the timing of risk management interventions, the tools and techniques that will be used, and the reporting requirements. Click here to view the risk management approach template
Risk register A record of identified risks relating to an initiative, including their status and history. Click here for the risk register template
SAFe (Scaled Agile Framework) Large-scale application of agile across an organization.
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.
Scrum 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’ (The Scrum Guide by Ken Schwaber and Jeff Sutherland, updated November 2017).
Scrum master 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.
Scrumban The application of Kanban or the Kanban method in the context of an existing implementation of 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 (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.
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 section of the project that a project manager is managing on behalf of the project board at any one time, at the end of which the project board will wish to review progress to date, the state of the project plan, the business case and risks and the next stage plan, in order to decide whether to continue with the project (PRINCE2). In agile terms, 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 management stage.
Stand-up meeting 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 product (and its components). Also referred to as the supplier SME.
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 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, 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.
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.
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. Click here to view the work package template
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.