AgilePM Practitioner key terms

A structured project management framework that combines an iterative, timeboxed delivery approach with defined roles, products and controls, so projects can respond to change while remaining governed and auditable.

Dynamic Systems Development Method, the underlying method that AgilePM is built on. It supplies the principles, lifecycle, roles and product set that AgilePM adapts into a full project management framework.

The AgilePM lifecycle made of pre-project, feasibility, foundations, evolutionary development, deployment and post-project phases. It shows where project-level governance and delivery-level timeboxes fit together.

The first phase of the Agile Project Framework. It establishes whether the proposed project is worth doing, confirming a business case outline, likely costs, risks and whether the Agile approach is suitable.

The phase where the project is set up properly: scope and requirements are baselined at a high level, the team and roles are formed, and plans, controls and the business case are agreed before delivery begins.

The delivery phase of the Agile Project Framework, made up of successive timeboxes in which solutions are built incrementally and refined based on feedback and learning from earlier iterations.

The phase in which the evolving solution is moved into operational use in a controlled way. It covers assembly, testing, user documentation, training and handover activities needed for a release.

The final phase that checks whether the benefits expected in the business case are actually being realised, and captures lessons that can improve future projects and the organisation's approach.

A fixed period of time, such as an iteration or a project stage, during which work is done. The end date does not move; instead scope is adjusted to fit within the time available.

A single timebox within evolutionary development in which the team analyses, designs, builds and tests a small increment of the solution, producing something demonstrable at the end.

The usable, tested portion of the solution produced by an iteration. Each increment builds on previous ones and is reviewed so that feedback can shape the next piece of work.

A ranking technique that sorts requirements into Must have, Should have, Could have and Won't have for this timebox. It protects delivery by making clear what can be dropped if time runs short.

The set of Must have requirements that must be delivered for the solution to be acceptable and usable. It defines the line below which a timebox or release cannot be considered successful.

A document describing the rationale for the project, including expected benefits, costs, risks and timescales. It is reviewed throughout so the project continues only while it remains worthwhile.

The process of confirming that the outcomes promised in the business case are actually achieved after delivery. It is assessed in the post-project phase rather than assumed at sign-off.

A product holding the requirements for the project, each with its MoSCoW priority, so the team and business can agree what is essential and what may be deferred or dropped.

The role responsible for overall project delivery and governance: managing the business case, plans, risks, resources and stakeholder communication, and escalating issues that need senior decisions.

The senior role that owns the business case, funds the project and provides strategic direction. This person makes key decisions and removes issues escalated from the project level.

The role that defines and communicates the vision of the solution and its expected business benefits, ensuring the project stays aligned with what the organisation actually needs.

The role that ensures the technical aspects of the solution are coherent and fit the organisation's architecture and standards, advising on technical risk and non-functional requirements.

The role that leads the delivery team day to day, facilitating the team's work, removing obstacles and ensuring the iteration plan is met and products are delivered to agreed quality.

The role that supports the Business Visionary by eliciting, analysing and documenting requirements, and by facilitating communication between business stakeholders and the technical team.

The role responsible for shaping the technical structure of the solution, ensuring it meets non-functional requirements and fits the wider technical environment across iterations.

The group of people who do the actual work of building and testing the solution within each timebox. It is a small, empowered, cross-functional team that self-organises around the work.

The senior decision-making group for the project, providing direction, approving key products and resolving escalated issues. It usually includes the Business Sponsor and other senior stakeholders.

Statements of what the solution must do or be like, captured in the Prioritised Requirements List. They are prioritised so the team can focus on the most valuable ones first.

Requirements describing qualities or constraints such as performance, security, usability or availability, rather than specific features. They often shape the architecture and can be hard to prioritise.

A short, clear statement of the intended end result and the benefits it will bring. It keeps the team and stakeholders focused on the same goal throughout the project.

A plan for a single timebox showing which prioritised requirements the team will work on and the activities needed to deliver them. It is owned by the team and updated as work progresses.

A plan showing how the solution will be delivered across one or more timeboxes and when increments will be released into use, linking delivery to business expectations.

A set of increments made available for operational use at a point in time. Releases are planned so that value reaches users early and often rather than only at the end.

A structured, timeboxed meeting run by a facilitator to bring stakeholders together to agree requirements, priorities or designs, aiming for a shared decision in a single session.

A technique for representing requirements, processes or solution designs in a simplified visual or structured form so that stakeholders can review and agree them early.

The eight underlying principles, such as focusing on business need and delivering on time, that guide behaviour and decision-making. They are applied throughout rather than treated as optional.

Adapting the AgilePM framework, roles, products and controls to suit the size, risk and context of a particular project, while keeping the intent of the method intact.

The planned activities that confirm products meet agreed standards before acceptance, including reviews, testing and sign-off by the appropriate roles.