Agile Dictionary of Terms for Prince2

A - Z Dictionary of terms for Prince2 Agile edition. This is the official Dictionary of terms for the Agile prince 2 method. PRINCE2® is a registered trade mark of AXELOS Limited. See glossaries for Managing Successful Programmes (MSP), Project Office Dictionary (P30), PRINCE2, ITIL and Risk Management. See also the Project Management Dictionary.

A - acceptance critera to Agilometer | B - backlog to business case | C - change authority to customer subject matter expert | D - definition of 'done' to Dynamic Systems Development Method | E - early adopter to experiment | F - G - feature to Glad! Sad! Mad! | H - I - higlight report to issue | K - Kaizen to Kano | L - lead time to Little's Law | M - manage by exception to MoSCoW | P - Plan-Do-Check-Act to push system | Q - quality assurance to quality tolerance | R - RACI to risk register | S - SAFe to supplier subject matter expert | T - team dynamics to transparency | U - V - user story to visioning | W - Waterfall method to workshop

F to G - Feature to Glad Mad Sad

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. It is a technique that is more applicable to the project management context than to agile delivery. Read more on Gantt charts.

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'.

Support stakeholdermap.com
If you liked this page, feel free to recommend us!