Adaptive Planning (Domain V) contains the focus areas & quick notes on this topic which will help you to pass the PMI-ACP® exam offered by PMI. Domain V Adaptive Planning accounts for 12% of all questions in the Exam (i.e. ~14 questions among 120 Exam questions). Below is a collection of the key knowledge addressed in Adaptive Planning and the tasks related to the domain (Produce and maintain an evolving plan, from initiation to closure, based on goals, values, risks, constraints, stakeholder feedback, and review findings).
Focus Areas for Adaptive Planning
Return on investment (ROI)
ROI is calculated using the formula of benefit to cost.
- ROI = (Gain – Cost) / Cost
- Discounted ROI = NPV of Benefits / NPV of Costs. Discounted ROI considers the future value of the money (benefits and costs).
- ROI = Velocity × Margin. ROI is also calculated by multiplying the velocity against the margin of the project.
Earned value technique (EVT)
- Planned story points of the release = Sum of story points planned for the iterations
- Completed story points of the release = Sum of story points completed of the iterations
- Earned value of the release = Sum of the earned value of the iterations
Kano analysis
Kano analysis prioritizes customer requirements as customer satisfaction.
- Must Be: Whatever the quality characteristic is, it must be present, such that if it is not, the customer will go elsewhere.
- Performance: The better we are at meeting these needs, the happier the customer is.
- Delighter: Those qualities that the customer was not expecting, but received as a bonus.
Important formula
- Schedule Variance (SV) = Earned value (EV) − Planned value (PV)
- Cost Variance (CV) = Earned value (EV) − Actual cost (AC)
- Schedule Performance Index (SPI) = Earned value (EV) / planned value (PV)
- Cost Performance Index (CPI) = Earned value (EV) / actual cost (AC)
- Lead Time = Work In Progress (units) / Average Completion Rate (units per time period)
- Work In Progress = Lead Time* Average Completion Rate (units)
- Average Completion Rate = Work In Progress / Lead Time
MoSCoW Approach
- MUST have this requirement to meet the business needs.
- SHOULD have this requirement if possible, but the project’s success does not rely on it.
- COULD have this requirement if it does not affect the business needs of the project.
- WON’T have this requirement, and the stakeholders have agreed that it will not be implemented in a release but may be considered for the future.
Adaptive planning/rolling wave planning/progressive elaboration: A multi-step, intermittent process of planning which is based on the philosophy that the plan can be detailed only as more details are revealed with time and with the changing scenario in the project.
Core Agile project management phases
- Envisioning
- Speculating
- Exploring
- Adapting
- Closing
Agile Planning Stages
- Product Vision –A document created by the product owner describing what the product is, who will and why to use it, and how the product supports company strategy. [revised once a year].
- Product Roadmap – A document created by the product owner describing the high-level product requirements and the timeframes for deliverables, providing a visual overview of all the planned releases and major components. [revised twice a year].
- Release Plan –A document created by the product owner describing the high-level timeline for product releases (features with higher values are given higher priority in the releases). [revised twice / four times a year].
- Personas – a tool used in requirement collection and testing in which realistic depictions of likely users for the product are created, these users can be real or fictitious.
- Extreme Persona – extreme persona is a persona taken to the extreme (with extreme characters/requirements) in order to identify user stories that would be missed otherwise.
- Wireframes – sketch graphical presentations of how the requirements are fulfilled (usually as interface designs), can act as a kind of fast requirement documentation.
Sprint Plan / Iteration Plan – A document created by the product owner, scrum master, and development team describing sprint goals, tasks, and requirements and how those tasks will be completed [revised once a month/iteration].
- Iteration ZERO is for carrying out tasks before the actual development work begins for technical and architectural setup (e.g. spikes) and gathering initial requirements into the backlog, etc.
- Iteration H represents hardening iteration which is the time used to test and prepare the launch software
- Iteration Planning vs Release Planning
- Iteration planning involves schedule development at a lower/detailed level about tasks and time
- Release planning involves schedule development at a high level regarding features and iterations
Daily Stand-up / Daily Scrum – [daily for 15 minutes] a planning meeting to be attended by the project team and stakeholders (as observers only) to discuss the following 3 questions:
- What was completed yesterday?
- What will be done today?
- Any roadblocks/impediments found
Sprint Review – A meeting scheduled at the end of each sprint for demonstration of working product/increment/deliverable to stakeholders for feedback and/or acceptance [monthly, at least an hour, for scrum]
Sprint Retrospective – [monthly, at least an hour, for scrum] a meeting scheduled at the end of each sprint to be attended by team members only, will discuss improvements on product and process to enhance efficiency and effectiveness
Retrospective Meeting vs Review Meeting
- A retrospective meeting is for the development team only (stakeholders are not invited) with the primary purpose of process improvement
- A review meeting is for the demonstration of deliverables with management, product owner, and stakeholders; new backlog item(s) may be identified together with the customers to be added in the next iteration
Retrospective Meeting vs Lessons Learned Meeting
- A retrospective meeting is carried out once per iteration to timely identify areas for improvement for immediate action to benefit the project itself
- Lessons Learned meeting (in traditional project management) is carried out at the end of the project/phase as the project closure activity and all the lessons learned are to be identified and documented (according to PMBOK® Guide) so that they will benefit upcoming projects.
Agile Modeling
- Agile Modeling is a practice-based methodology (including a collection of values, principles, and practices) for effective modeling and documentation of software-based systems based on best practices
- a model is a pre-defined way of doing things
- Agile Modeling is more flexible than traditional modeling methods to be used in traditional project management in order to fit the fast-changing environments of Agile projects
Agile Planning Terms
- Agile Themes – a theme is usually assigned for an iteration in which similar functions are grouped to be done in a batch to maintain the focus of the team, e.g. bug fixes, reporting, etc.
- Epic Story – a large block of functionality (usually requires several iterations), epic stories will later be disaggregated into smaller user stories for estimation and implementation
- User Story – usually takes the format of “As a [role], I want [need] so that [business value]”
- User stories need to be Independent, Valuable, Estimable, Small, and Testable [INVEST]
- User stories need to be Specific, Measurable, Attainable, Relevant, and Timely [SMART]
- [Ron Jeffries’ three Cs of user story] Card, Conversation, Confirmation
- Story Maps – are the overview of how different user stories are related to each other in the project
- Features – a capabilities/group of functionalities that is of value to the end user
- Tasks – the underlying jobs/development work to fulfill a user story, tasks are taken up by the team members through self-organization
- Spikes – a short experimental test to help decisions making, e.g. trying a new technology for a feasibility study
- Architectural spikes – an investigation taken to explore the architectural aspects of the setup
- Time-boxing: time-boxing is a concept for time management by treating time as fixed blocks, once the allotted time (time-box) is up, the work must be stopped regardless of whether it has been finished with a fixed start time, fixed end time, and fixed duration for the activity to control the risk and progress time-boxing allows the team to focus on the essential works and reduce wastes
Agile estimation and sizing
- Relative Sizing – Agile project management makes use of relative sizing (e.g. story points) as opposed to the use of exact units like money and time in traditional project management for estimation as Agile projects are more prone to changes, making use of relative sizing will be more flexible yet still give a reference for meaningful estimation
- Ideal Time – a unit used in the estimation of Agile tasks: ideal time is a block of the uninterrupted period to focus solely on the task without any distractions e.g. email, phone call, toilet break, etc.. Though ideal time is NOT realistic in the actual world, it does give an accurate unit to begin working with (e.g. by multiplication of a factor of 2 to 3 to give a reasonable estimate)
- Wideband Delphi Estimating – similar to the Delphi technique but discussion about details of the requirements is allowed in the beginning to allow each individual to have a common understanding of the scope of the tasks, each participant will then try to give an estimate for the user stories, etc. with relative sizing on their own; repeat the process until a consensus is reached
- Planning Poker – each member needs to select from a deck of cards (with ?, 0, 1, 2, 3, 5 …) to express their estimation of the story points for a user story, discussion follows until a consensus is reached
- Affinity Estimating / T-shirt Sizing – assign a size (e.g. T-shirt sizing: S, M, L, XL, XXL) to user stories instead of giving a more concrete unit, this method is ideal if the scope/details of the task are not quite concrete
