AgilePM Foundation flashcards
AgilePM Foundation · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- DSDM Framework
- The framework on which AgilePM is based, resting on four pillars: philosophy, principles, people and process, and providing a structured yet flexible approach.
- AgilePM Philosophy
- The belief that best business value emerges when projects align to clear business goals, deliver frequently and involve motivated, empowered people collaborating closely.
- Focus on Business Need
- The DSDM principle that every decision and action should be directed at delivering business value and meeting the stated business need.
- Deliver on Time
- The DSDM principle that timeboxes are fixed and scope is flexed to meet deadlines, ensuring predictable delivery of value.
- Build Incrementally
- The DSDM principle that projects should build on firm foundations, delivering the solution in increments rather than all at once.
- Demonstrate Control
- The DSDM principle that progress should be visible, measurable and managed, with clear control points and appropriate governance throughout the project.
- Business Sponsor
- The project-level role that owns the business case, funds the project and acts as the ultimate decision-maker for the project.
- Business Visionary
- The project-level role that provides business direction, owns the Prioritised Requirements List and ensures the solution meets business needs.
- Technical Coordinator
- The project-level role that leads the Solution Development Team, owns the Solution Architecture Definition and ensures the solution is technically sound.
- Project Manager
- The role responsible for day-to-day project management, owning the Project Plan and managing risks, issues and overall delivery at project level.
- Team Leader
- The role that leads the Solution Development Team, ensures AgilePM practices are followed and represents the team to the Project Manager.
- Business Ambassador
- A business role that provides business knowledge and supports the team in delivering requirements, often participating in workshops and reviews.
- Solution Tester
- A solution development role responsible for testing the solution against requirements and ensuring it meets the agreed quality criteria.
- Workshop Facilitator
- The role responsible for planning and facilitating workshops, ensuring effective collaboration and communication among stakeholders.
- Business Case
- A project-level product owned by the Business Sponsor that demonstrates the business value of the project and justifies continued investment.
- Project Plan
- A project-level product owned by the Project Manager that defines the overall approach, timeboxes, resources and control points for the project.
- Prioritised Requirements List
- A project-level product owned by the Business Visionary that captures requirements using MoSCoW prioritisation to guide iterative delivery.
- Solution Architecture Definition
- A project-level product owned by the Technical Coordinator that describes the overall structure of the solution and its technical approach.
- Development Approach Definition
- A project-level product owned by the Technical Coordinator describing how the solution will be developed, including tools, techniques and standards.
- Timebox Plan
- A timebox-level product created by the Solution Development Team to plan the work and products to be delivered within a single timebox.
- Product Checklist
- A timebox-level product listing the products to be delivered in a timebox and their status, used to track progress.
- Foundations Summary
- A product produced at the end of the Foundations phase summarising the baseline products and confirming readiness to begin evolutionary development.
- MoSCoW Prioritisation
- A prioritisation technique using Must Have, Should Have, Could Have and Won't Have categories to ensure the most important requirements are delivered first.
- Must Have Rule
- Must Have requirements must not exceed 60% of the total effort; if they do, the project is at risk and priorities must be rebalanced.
- Could Have Rule
- Could Have requirements should represent around 20% of the effort, providing contingency that can be dropped if time is short.
- Timeboxing
- A practice of fixing a period of time (typically 2-4 weeks) within which work is prioritised and delivered, flexing scope to protect the deadline.
- Iterative Development
- The practice of developing the solution in increments, each building on the previous, with stakeholder feedback informing subsequent iterations.
- Modelling
- A practice of using models such as diagrams and prototypes to explore and communicate requirements and solutions, supporting rather than replacing collaboration.
- Daily Stand-up
- A short daily team meeting, typically 15 minutes, where members share progress, plan the day's work and identify blockers.
- Feasibility Phase
- The first phase of the AgilePM lifecycle, assessing whether the project is viable and producing the outline Business Case and Feasibility Assessment.
- Foundations Phase
- The phase that establishes project foundations, producing the PRL, Project Plan, Solution Architecture Definition and Development Approach Definition before delivery begins.
- Evolutionary Development Phase
- The phase where the solution is developed iteratively through timeboxes, each producing a potentially shippable increment of the solution.