Free PMI-ACP Practice Test

The project director's request is an impediment to the iteration goal. The team lead has already attempted to discuss alternatives without success. The next logical step is negotiation, not escalation or capitulation. By negotiating to reduce the scope of the request (e.g., detailing only the most critical tests), the team lead attempts to find a compromise. This approach respects the stakeholder's need while minimizing the negative impact on the team's committed work. It is a constructive, collaborative problem-solving technique that seeks to balance competing demands, which is a key skill for an agile leader.

B. Escalation should be a last resort after other resolution attempts, like negotiation, have failed. It can damage working relationships.
C. Gathering a detailed estimate only confirms the size of the problem; it does not actively work toward a solution or resolve the conflict.
D. Putting all work on hold sacrifices the iteration goal for an unplanned request, which is a significant agile anti-pattern.

1. Project Management Institute. (2017). Agile Practice Guide. Section 5.3, Engaging Stakeholders, p. 50. (This section highlights the importance of managing stakeholder expectations and actively collaborating to resolve issues and misunderstandings).

2. Project Management Institute. (2017). Agile Practice Guide. Section 4.2.2, Servant Leadership, p. 34. (Describes the servant leader's role in removing impediments, which includes negotiating solutions with stakeholders who may be disrupting the team's flow).

3. Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional. Chapter 16, The Product Owner. (While focused on the Product Owner, this chapter discusses the need to negotiate with stakeholders to protect the team and the sprint goals).

When user stories lack sufficient detail, the most effective and collaborative agile approach is to facilitate a user story workshop. This is a dedicated, collaborative session involving the product owner, the development team, and other relevant stakeholders. The goal is to discuss, clarify, and refine the user stories together, ensuring everyone develops a shared understanding of the requirements. This proactive, team-based approach directly addresses the communication gap and aligns with the agile principle of collaboration over contract negotiation.

A. Coaching the product owner is a good step, but focusing only on acceptance criteria may not solve the problem if the core story description is also weak.
B. A retrospective is for improving the process, not for fixing the content of current work items. The team needs clarification before starting the work.
D. Escalating to a manager is a confrontational step that undermines team self-organization and should only be considered a last resort.

1. Project Management Institute. (2017). Agile Practice Guide. Section 5.2.2, Backlog Refinement, p. 52. "Backlog refinement is the progressive elaboration of details for user stories... This is a collaborative effort led by the product owner and including the team and other stakeholders." A workshop is a formal way to conduct this collaboration.

2. Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional. Chapter 3, "User Role Modeling," and Chapter 14, "A Catalog of Story Smells," emphasize the need for collaborative conversations to add necessary detail to stories.

3. Patton, J. (2008). The new user story backlog is a map. This concept, often visualized as a "story map," is built through collaborative workshops to ensure shared understanding and sufficient detail. Retrieved from Jeff Patton's official publications/blog archives.

In the context of team dynamics, especially in an Agile environment that values open communication, a team that completes tasks but offers little vocal interaction can be a sign of underlying issues. Passive-aggressive behavior is characterized by an indirect resistance to the demands of others and an avoidance of direct confrontation. The silence and lack of engagement, despite task completion, can be a manifestation of unresolved conflict, low psychological safety, or resentment. An Agile project manager or coach would recognize this as a potential team health issue that requires further investigation to ensure long-term collaboration and resilience.

A. Synchronous describes the timing of communication (real-time), not the quality or nature of the team's behavior. The lack of interaction suggests a problem with synchronous communication.
B. While tasks are completed, the lack of vocal interaction is a symptom that may indicate a lack of true, open collaboration, which is a cornerstone of Agile teams.
D. The behavior is a consistent pattern of minimal interaction, not random. It is a predictable, albeit concerning, team norm.

1. Project Management Institute. (2017). Agile Practice Guide. Section 5.4.2, Emotional Intelligence. pp. 73-74. The guide highlights the importance of self-awareness and relationship management for high-performing teams, noting that a team's emotional intelligence is critical for navigating conflict and collaborating effectively. A silent team may indicate low emotional intelligence or safety.

2. Edmondson, A. C. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350–383. https://doi.org/10.2307/2666999. This foundational paper establishes that psychological safety—a belief that one will not be punished for speaking up—is critical for team learning and performance. A silent team often indicates a lack of psychological safety.

3. Katzenbach, J. R., & Smith, D. K. (1993). The Wisdom of Teams: Creating the High-Performance Organization. Harvard Business Review Press. The authors describe how real teams require open communication and constructive conflict, which are absent in the described scenario.

The core of the problem is a misunderstanding and misalignment between the team and business stakeholders. Agile methodologies address this through frequent feedback loops. The sprint review (or demo) is the primary formal event for the team to demonstrate the working product increment to stakeholders and get their feedback. By explicitly considering this feedback during the next sprint's planning, the team ensures that its understanding is aligned with stakeholder expectations. This iterative process of demonstrating, gathering feedback, and adapting the plan is fundamental to reducing misunderstandings and ensuring the project delivers value.

A. Attempting to get full agreement on all requirements upfront is a waterfall approach. Agile embraces the fact that requirements emerge and change over time.
B. Planning every four iterations is an arbitrary and infrequent cadence that would likely increase, not decrease, misunderstandings due to the long feedback cycle.
D. While a contract may state the project's purpose, it is a static document and not an effective tool for resolving ongoing, operational disagreements about specific epics.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. The "Sprint Review" section states its purpose is to "inspect the outcome of the Sprint and determine future adaptations

" which directly involves stakeholder feedback influencing future plans.

2. Project Management Institute. (2017). Agile Practice Guide. Section 5.2.8

Review/Demonstration

p. 66. "The team demonstrates the work that it has 'Done'... The product owner and the team get feedback that they can incorporate in the next iteration."

3. Stray

V.

Sjøberg

D. I.

& Dybå

T. (2016). The daily stand-up meeting: A grounded theory study. Journal of Systems and Software

114

101-124. https://doi.org/10.1016/j.jss.2016.01.004. While focused on stand-ups

the paper reinforces the importance of frequent communication and feedback cycles in agile to maintain alignment.

An agile team is responsible for maintaining a sustainable pace and ensuring product quality. Expediting a schedule introduces significant risks, such as technical debt, reduced quality, and team burnout. The team's professional responsibility is to be transparent about these risks. Advising the client that it is best to continue as planned is a direct way of communicating that the proposed change carries a high risk of being counterproductive. This opens a collaborative discussion about the trade-offs between the potential financial gain and the risks to the project's long-term health and quality.

A. Immediately adhering to a new deadline without assessing its feasibility and impact on quality is irresponsible and not an agile practice.
C. Proposing a price increase based on the client's potential profit is adversarial and undermines the agile principle of customer collaboration.
D. Requesting additional resources assumes that adding people will solve a schedule problem, which is often false (Brooks's Law) and ignores other solutions like scope reduction.

1. Project Management Institute. (2017). Agile Practice Guide. Principle #8, "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely," p. 9.

2. Beck, K., et al. (2001). Manifesto for Agile Software Development. The principle of "Sustainable Pace" is a cornerstone of agile development, ensuring long-term productivity and quality.

3. Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. This foundational text explains why adding manpower to a late software project makes it later.

The primary value of a product demonstration (Sprint Review) before the product is "complete" is to create a fast feedback loop. It allows stakeholders to see a tangible, working increment of the product and provide input. This immediate feedback is crucial for validating or correcting the team's assumptions about the requirements and the solution. This process of inspection and adaptation ensures that the product being built aligns with stakeholder needs and delivers the expected value, allowing for course correction in subsequent sprints.

A. The goal is to increase direct stakeholder involvement and feedback, not to suggest they can be represented by a proxy.
B. The demo focuses on the product increment and its value ("what" was built), not on the team's estimation accuracy or understanding of effort.
D. While the long-term goal is a worthwhile return on investment, a single demo is a tactical meeting to inspect the increment and adapt the plan.

1. Project Management Institute. (2017). Agile Practice Guide. Section 5.2.7, Demonstration/Review, p. 60. "The purpose of the demonstration is to get feedback from the product owner and other stakeholders on the increment... This feedback is then incorporated into the product backlog for consideration in a future iteration."

2. Rus, I., & Lindvall, M. (2002). Knowledge management in software engineering. IEEE Software, 19(3), 26-38. https://doi.org/10.1109/MS.2002.1003450. This paper discusses how agile practices facilitate knowledge sharing and learning, with reviews and demos being key mechanisms for validating knowledge and assumptions between developers and customers.

Both teams have estimated 14 sprints to complete their respective projects (Team A: 420÷30=14; Team B: 280÷20=14). While they use different story point scales, the relative sizing within each team results in the same project duration estimate. Story points are relative units specific to each team, not absolute measurements. The key insight is that both teams perceive their projects will require the same number of iterations to complete.

A. Team B's lower story points don't indicate underestimation since story points are team-specific relative measures, not absolute values.
B. Velocity confidence cannot be determined from these estimates alone; the numbers only show each team's baseline velocity.
C. Technology details are not required for story point estimation as they're already factored into team-specific estimates.
3. References:
1. Cohn, M. (2005). Agile Estimating and Planning. Chapter 4: "Estimating Size with Story Points," pp. 35-38. Prentice Hall PTR.
2. Rubin, K. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process. Chapter 7: "Estimation and Velocity," pp. 129-134. Addison-Wesley.
3. Sutherland, J. & Schwaber, K. (2017). The Scrum Guide. Section: "Development Team," pp. 7-8. Available at: https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
4. Larman, C. & Vodde, B. (2010). Practices for Scaling Lean & Agile Development. Chapter 5: "Feature Teams," pp. 89-92. Addison-Wesley.
5. IEEE Computer Society (2014). Guide to the Software Engineering Body of Knowledge (SWEBOK) V3.0. Chapter 6: "Software Construction," Section 6.3.4. Available at: https://www.computer.org/education/bodies-of-knowledge/software-engineering

1. PMI & Agile Alliance. “Agile Practice Guide” (2017)

§4.3.2

pp. 46-47 – points unique to a team

non-comparable.

2. PMI & Agile Alliance. “Agile Practice Guide” (2017)

§4.3.4

p. 50 – velocity used to forecast number of iterations.

Agile adoption succeeds when everyone affected understands and supports the change. PMI’s Agile Practice Guide states that introducing agile “requires broad‐based training and coaching so that teams, managers, and stakeholders share a common understanding of agile values, principles, and practices.” Organising workshops for all stakeholders therefore gives predictive-oriented teams the knowledge, vocabulary and mindset they need before roles or artefacts are assigned, ensuring a consistent, organisation-wide shift to agile delivery.

A. Limits training to predefined roles; fails to create the whole-system understanding that PMI prescribes for successful adoption.
C. Focusing only on senior leaders ignores the delivery teams that must execute the work.
D. Mixing agile and predictive on the same product fractures process consistency and inhibits learning for the formerly predictive team.

1. PMI. Agile Practice Guide

2017

Section 2.2 “Implementing Agile on a Project”

pp. 19-20.

2. Dikert

K.

Paasivaara

M.

& Lassenius

C. “Challenges and success factors for large-scale agile transformations.” Journal of Systems and Software 119 (2016): 87-108. https://doi.org/10.1016/j.jss.2016.06.013.

Planning Poker is a consensus-based estimation technique commonly used by agile teams. Team members use numbered cards (often following a modified Fibonacci sequence) to privately vote on the size of a user story. After revealing their cards simultaneously, the team discusses any significant variances and re-votes until a consensus on the story point value is reached. This method combines expert opinion, analogy, and disaggregation to estimate relative size, fostering collaboration and shared understanding of the work.

A. Parametric estimation uses statistical models and historical data to calculate estimates, which is different from the collaborative, relative sizing of Planning Poker.
B. One-to-one comparison is a general concept, not a specific, named agile estimation technique like Planning Poker.
C. Affinity estimating is a technique used to quickly group and size a large number of user stories, but Planning Poker is the specific gamified, consensus-driven method described.

1. Project Management Institute. (2017). Agile Practice Guide. Section 5.2.3.3, Common Agile Estimating Techniques, p. 61. "Planning Poker... This technique blends consensus with individual expert opinion... to arrive at a shared, agreed-upon estimate."

2. Haugen, N. C. (2006). An Empirical Study of Using Planning Poker for User Story Estimation. Paper presented at AGILE 2006 Conference. This paper details the process and benefits of Planning Poker for collective, relative estimation. DOI: 10.1109/AGILE.2006.33.

3. Mahnič, V., & Hovelja, T. (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), 2086-2095. This academic article analyzes Planning Poker as a method for collective estimation. https://doi.org/10.1016/j.jss.2012.04.005

The most effective and least disruptive way to provide status updates is through information radiators, such as a physical or digital task board, burndown charts, or a project dashboard. These tools offer real-time, pull-based information, promoting transparency and allowing stakeholders to check progress at their convenience without interrupting the team's workflow. This approach empowers stakeholders while protecting the team's focus. The product owner's role is to ensure such transparent communication mechanisms are in place and known to stakeholders.

A. The daily stand-up is a brief, internal synchronization meeting for the development team, not a status report for executives.
C. Personal meetings are inefficient, not scalable, and create a dependency on the product owner for information that should be publicly visible.
D. Emailing status reports is a "push" communication method that can become outdated quickly and adds unnecessary administrative overhead.

1. Project Management Institute. (2017). Agile Practice Guide. Section 4.2.4, Information Radiators, p. 52. "To ensure that the stakeholders are aware of the project's progress, agile teams use information radiators... These are visible, physical displays that provide up-to-the-minute information..."

2. Cockburn, A. (2001). Agile Software Development. Addison-Wesley. Chapter 3 discusses "Information Radiators" as a technique for osmotic communication, allowing information to be picked up by stakeholders as they pass by.

3. Stray, V., & Moe, N. B. (2020). Understanding coordination in global software engineering: A mixed-methods study on the use of meetings and information radiators. IET Software, 14(4), 351-359. https://doi.org/10.1049/iet-sen.2019.0139. This study highlights the role of information radiators in facilitating awareness and coordination.