1. The Agile Manifesto and Principles

04 Values of the Agile Manifesto

12 Principles of Agile

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

2. Agile Methodologies

Agile has more than 50 project management methods, some of which can be mentioned: Scrum, eXtreme Programming (XP), Lean product development, Kanban, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal, Scrum of Scrum, etc.

Common methods in the PMI-ACP® test can be mentioned:

• Scrum
• Extreme Programming (XP)
• Kanban
• Scrum of Scrum

3. Value-Driven Delivery

• Delivering the "highest-value" as early as possible is a top priority of the Agile Team. When encountering situations related to requirement/task prioritization,... you should be considered in the answers that bring high "value". 
• In the PMI-ACP®, "Risk" refers only to negative impacts (aka threats), so Risk = Anti-value.
• The Product Owner is accountable for maximizing the value of the product. In situations related to the product - such as requirements, priorities, or changes in requirements - the appropriate course of action is to consult or involve the Product Owner, or seek their support in addressing the matter.

4. Evaluate value in an Agile projects

 Identifying potential projects

In Agile projects, the following formulas are typically used to evaluate and identify potential projects:

• ROI
• PV
• NPV
• IRR

→ The higher these indices, the more valuable the project is considered to be. In the PMI‑ACP® exam, calculation-based questions are rare, so it’s more important to understand the concepts than to focus heavily on performing calculations.

 Earned Value Management in an Agile projects

- Normally, Earned Value Management will be used for the "release" milestone instead of "iteration". The goal of Earned Value Management: 

• EVM is a formula to measure work performance.
• Represents earned value of actual performance compared to expected performance.

- How to use Earned Value Management in Agile projects:

• Convert Requirement/User Story into money.
• Use Story Points.

Again, in the PMI-ACP® exam, the calculation questions about Earned Value Management are almost non-existent, so we can learn more without focusing too much on calculation questions.

 Common tools used to measure performance in Agile projects

- Burn-down chart: Keywords to identify Burn-down chart include “remaining” work, “how much work is left”, “how close they are to achieve their sprint goals”, “how the project is progressing”, etc.

- Burn-up chart: Keywords to identify a Burn-up chart include “scope line”, “capture scope changes”, “total number of points burned up”, “completed work”, etc.

Usually, both of these tools can be used in Iterations/Sprints and in Releases.

- Velocity: This is a straightforward method to accurately measure the consistent pace at which the Development Team completes work. Velocity is the basis for showing the average amount of Product Backlog that is converted into product feature increments in Sprints. It is tracked by the Development Team for planning purposes. Therefore, to calculate the velocity of the team, we simply add up the estimates of the features, user stories, requirements, or backlog items completed within a single iteration or Sprint.

A few notes about Velocity:

• Velocity is a metric used to measure the pace at which a team completes work. It is intended for tracking progress within the same team over time, not for comparing performance across different teams.
• Velocity is expected to be stable and consistent, as this reflects the accuracy of the team’s work estimates and contributes to overall team stability. 

 Overview of risk management in an Agile projects

• In the context of PMI‑ACP®, “risk” specifically refers to negative impacts or threats - in other words, risk is considered anti-value.
• High-risk requirements or features should be prioritized and addressed early, in alignment with Agile’s “fail fast” mindset, which encourages early detection and resolution of potential issues.

5. Prioritizing Value

- The customer is the ultimate decision-maker on whether a product/project is successful.

- The Product Owner is accountable for maximizing the value of the product. For matters related to the product - such as requirements, priorities, or changes in requirements - it is appropriate to refer to the Product Owner or seek their support in addressing the issue.

- All requests and changes should be evaluated based on their value, and those with higher value should be prioritized accordingly..

- Common prioritization tools include:

• MoScoW
• Monopoly Money
• 100-Point Method
• Dot Voting or Multi-Voting
• Kano Analysis

 Delivering Incrementally

- Delivering incrementally is one of the key ways Agile teams optimize value delivery, enabling early feedback, faster realization of benefits, and reduced risk. 
- Agile teams typically deploy “working increments” of the product throughout the project lifecycle to achieve the following:

In the test environment (not yet released to customers):

• The Business and Agile Teams will have an objective view of the product’s progress
• Enable early product testing
• Minimize unnecessary errors, or
• Facilitate error detection and resolve as soon as possible

In the environment that has been released to customers:

• Increase the chances of collecting customer feedback on the product
• Increase the chances of seeing the product value
• Increase the chances of getting a return on the investment in the product,...

When answering exam questions related to fast delivery of value to the market, the correct options often include keywords such as “incrementally,” “MVP (Minimum Viable Product),” “working product,” and similar terms.

 MVP - Minimum Viable Product

MVP (Minimum Viable Product) is the first version of a new product released to the market by the Agile team, containing only the minimum necessary features. The goal is to quickly reach early customers and gather maximum feedback with minimal time and effort, enabling faster learning and informed decision-making for future development.

Note: An MVP (Minimum Viable Product) must satisfy two key criteria - it must be both minimal (containing only essential features) and usable (delivering real value to users in its initial form).

This helps Agile Teams:

• Assess market demand
• Gradually improve the product based on customer feedback
• Move toward a more complete product in the future

 Verifying & Validating Value 

- The difference between Verifying & Validating

- A few common ways for Agile Teams to continuously verify and validate the product:

• Consistently engage with stakeholders to establish a shared understanding of both the Acceptance Criteria and the Definition of Done.
• Use prototypes and visual presentations to help stakeholders clearly understand and validate requirements and expectations.
• Continuously demonstrate the product to stakeholders throughout development to gather feedback and ensure alignment with their needs.

6. Agile Contracting 

Common contract types in Agile projects include: 

• Multi-tiered structure
• Emphasize value delivered
• Not-to-exceed time and materials
• Dynamic scope option
• Team augmentation
• Favor full-service suppliers
• Fixed-price increments.
• DSDM Contract
• Money for Nothing and Change for Free
• Graduated Fixed-Price Contract
• Fixed-Price Work Packages
• Customized Contracts

However, questions related to contracts are rare - or even non-existent - in Agile-focused exams. In alignment with Agile’s third value, “Customer collaboration over Contract negotiation,” contracts in Agile projects typically have the following characteristics:

• A healthy negotiation and coordination between two parties to choose the most suitable contract type for their project.
• Collaboration is still the most important factor between the two parties. 
• The proposal contains information in the contract about flexibility in scope, or sharing of profits and risks between the parties, fostering collaboration to achieve the mutual project goal
   

7. Stakeholder Engagement 

Without continuous interaction with stakeholders, the project may fall into a "Gulf of evaluation" status:

• The development team misunderstood product requirements
• Customers don't describe exactly what they really expect

 Reinforces a shared vision and common understanding of the project among all stakeholders 

Agile Project Charter

• Less detailed than the Traditional Project Charter
• Answers the W5H: Who, What, Where, When, Why, and How — providing a comprehensive understanding of the project’s context and direction.

03 characteristics to keep in mind when talking about Documentation/Plan in Agile projects:

• Just in time: Documents only need to be available at the right time
• Just enough (barely sufficient): Documents are just enough to perform the work
• Progressive elaboration: Documents and plans will be developed gradually and refined continuously

 Definition of Done

- Created by the Scrum Team before the first Sprint begins. The team will:

• Refer to their organization's Definition of Done (DoD)
• “Tailor" it to fit the context of the project while still ensuring the organizational standards

- The Definition of Done (DoD) can only be adjusted through the Retrospective event. 

- The more detailed the DoD, the higher the maturity level of the Agile Team. 

- In the case of applying Scrum of Scrums, each team may have its own Definition of Done (DoD); however, team-level DoDs must not conflict with the overall (or integrated) DoD.

- Definition of Done is mandatory in Agile/Scrum Team. Currently, the DoD will usually refer to quality criteria and it is most commonly applied to User Story. However, we can still apply DoD to other goals: Release, Meeting, etc.

 Communicating with Stakeholders

Face-to-face communication is the most recommended and highest-priority method. If the context does not mention that Agile Teams have any shortcomings in “co-location" or “face to face communication”, then all conditions should be created for the team to be able to “co-location” and “face to face communication”.

- Co-location refers to placing many or all of the most active project team members in the same physical location to enhance their ability to collaborate and perform as a team. This setup can be temporary - used during strategically important phases of the project—or maintained throughout the entire project. In exam questions, co-location may appear under different synonymous terms such as:

• physically located
• everyone is in the same place
• Co-location # Distributed team (remote, virtual team,…) 

- Close or osmotic communication refers to the natural and continuous flow of useful information among team members who work in close physical proximity. As team members overhear each other’s conversations, knowledge is shared passively and efficiently, without the need for formal meetings.

→ Tips: 

• In exam questions, answers containing the keywords “co-location”, “osmotic communication”, or “face-to-face communication” are often correct, depending on the context - especially when referring to effective team collaboration and information flow.
• In contrast, when the team is virtual or distributed, answers that include terms like “video conferencing” or “video calls” are usually the correct choices when selecting the most appropriate form of communication.

 Conflict Resolution

In the scope of the PMI-ACP® exam, conflict resolution can go through the following steps:

• Step 1: Encourage the individuals involved in the conflict to resolve it on their own, demonstrating the Agile Team’s characteristics of being self-organizing and self-directing.
• Step 2: If the conflict remains unresolved despite their efforts, the Project Manager (PM) or Scrum Master should step in—acting as a servant leader to coach the team on conflict resolution techniques, or serve as a facilitator to guide the team in finding their own resolution.

→ Tips: Answers containing the word “Coach” are often correct, especially in contexts related to servant leadership, team development, or conflict resolution within Agile teams.

• Step 3: If the PM or Scrum Master has tried their best but the current conflict has gone too far and cannot be resolved, the team members have excessively negative and unprofessional moves in the work environment. PMs and Scrum Masters can implement escalation measures to higher levels or HR. 

 → Tips: Situations rarely escalate to Step 3; most stop at Step 1 or 2. 

8. Adaptive Planning

 Progressive Elaboration

Progressive elaboration: The iterative process of increasing the level of detail in a project management plan as more information becomes available and estimates become more accurate over time. This approach can be applied to areas such as:

• Planning
• Estimate
• Risk Assessment
• Definition of Requirements
• System/product structure
• Acceptance Criteria
• Test scenarios

The example above illustrates Rolling Wave Planning — a form of Progressive Elaboration specifically applied to project planning.

 Time-boxing

- Time-boxing is the practice of allocating a fixed, maximum duration for each planned activity, regardless of whether the work is completed. This technique helps maintain focus, encourages efficiency, and supports continuous improvement.

• Iteration/Sprint: 04 weeks 
• Sprint Planning: 08 hours for a Sprint with a length of 01 month (04 weeks)
• Daily Scrum/Daily Meeting: 15 mins
• Sprint Review: 04 hours
• Sprint Retrospective: 03 hours 

 Types of Iteration

• The concept of "Sprint 0" or "Iteration 0" can be thought of as a container for all activities that need to be performed before the first Sprint. Typically, these activities will include team formation, infrastructure setup, logistics locations, and the like.
• Iteration H (Hardening Iteration) refers to the final iteration in some Agile frameworks that is reserved for post-processing activities required before the product release. For example, the H iteration is used to stabilize the code, compile the final code, create product documentation, and perform final testing before releasing the product.

9. Solving problems according to the PMI-ACP® mindset

 Project Manager, Scrum Master, or other leadership positions in the Agile projects often have the role of Servant Leadership:

- Support the team and help them stay 100% focused on work. Resources in Agile are proposed to focus on a project (dedicated team) so that the team can complete the work as quickly as possible, as well as ensure quality → In situations of conflicting resources, the Project Manager, Scrum Master will discuss with stakeholders to protect resources as well as create conditions for their team to focus on working in a project. 

- Because of the role of Servant Leadership, the tasks can be mentioned:

• “Coach" team
• Eliminate possible barriers to the team work
• Be cautious with words like “command”, “direct”, “ask”, “request”, etc. when evaluating options in Agile-related questions. In most cases, answers containing these words are incorrect, as they tend to contradict Agile principles of servant leadership, collaboration, and self-organization. 

- Always maintain a sustainable working environment for your team. Be cautious with options provided to handle such situations - many of them are incorrect:

• Increase bonuses or incentives just to push the team to work overtime or make commitments. → Instead of relying solely on financial motivation, Servant Leadership should focus on understanding the underlying issues the team is facing, analyze the root causes, and provide appropriate support.  
• Forcing the team to work overtime just to meet a "deadline". 

 Promote team cohesion and overall strength. When internal conflicts arise, the Project Manager or Scrum Master should take proactive steps, such as:

• Organize meetings (face to face is the best) with stakeholders to discuss the problem at hand. 
• Work with the team to identify root causes.
• Choose solutions based on team consensus.
• Project Manager, Scrum Master, or Product Owner will not be able to make decisions on work and technical issues. Instead, these decisions should be discussed with the team, and the team members/development team/developers should have the final say on how the work is performed, as they are the ones directly executing it

We hope this information helps you achieve a high result on the PMI-ACP® exam. This article will be continuously updated as new insights become available. Best of luck in reaching your goals!

Trainer Lam Thu Nguyen 

(PfMP®, PgMP®, PMP®, PMI-ACP®, PMI-PBA®, PSPO II™, PSM II™, SPS, PAL I, PMI-ATP Instructor)