PMI-ACP Exam 1

✅ Correct answer: Run a concierge test with patients

📌 Explanation: Experimenting early means validating the market need with the smallest possible test before committing large funds. A concierge test, where staff fulfil orders by hand for a small group of patients, shows within weeks whether people actually pay NGN 1,500 a month, which decides whether the NGN 90 million build is justified.

❌ Why the other options are wrong: Commissioning the full platform build stakes the whole budget on an untested assumption; a detailed requirements catalogue documents guesses rather than testing them; benchmarking competitor apps describes the market but says nothing about whether these patients will pay.

📋 Objective: 1.1 (Experiment early)

✅ Correct answer: Plan hardware upfront, iterate the software

📌 Explanation: Suitability tools are read area by area, and a mixed result points to tailoring rather than an all-or-nothing choice. The regulated hardware design needs approval upfront, so a predictive plan fits that part, while the app software, where the team scores high on buy-in and trust, can be built iteratively with frequent feedback.

❌ Why the other options are wrong: Pure Scrum for everything ignores the regulator's requirement for an approved fixed design; a fully predictive plan for both throws away the agile strengths the assessment found in the team; postponing until the regulator relaxes delays value for a constraint that a hybrid approach can accommodate.

📋 Objective: 1.2 (Embrace the agile mindset)

✅ Correct answer: Co-create updated team working agreements

📌 Explanation: Working agreements are the team's own explicit rules for how it collaborates. When membership nearly doubles, the old unspoken habits no longer hold, so facilitating the team to co-create updated agreements on stand-up timing and review turnaround gives newcomers clarity and builds shared ownership as the team re-forms.

❌ Why the other options are wrong: Publishing rules and enforcing them is command and control and weakens ownership; moving the newcomers into a separate team dodges the integration problem and creates a silo; letting things settle leaves the friction in place while the team stays stuck in the storming stage.

📋 Objective: 1.3 (Promote a collaborative team environment)

✅ Correct answer: Radiate risks on the shared board

📌 Explanation: Building transparency means making risks and impediments visible to everyone who needs them. Putting the risks on the shared team board as an information radiator lets developers in both cities and the client see them as they change, so surprises at reviews stop and the team can act early.

❌ Why the other options are wrong: Emailing the spreadsheet monthly keeps the information weeks out of date; asking the lead to brief the client privately still hides risks from the developers; holding risk talks only with managers narrows visibility further instead of radiating it.

📋 Objective: 1.4 (Build transparency)

✅ Correct answer: Agree retrospective norms with the team; Run an anonymous safety check

📌 Explanation: Psychological safety lets people speak up without fear. An anonymous safety check measures how safe people feel and surfaces issues they will not voice openly, and agreeing retrospective norms with the team, such as who attends and a focus on process rather than individuals, restores a no-blame space.

❌ Why the other options are wrong: Having the director lead the retrospective strengthens the very pressure that silenced the team; recording who raised each issue removes anonymity and invites blame; skipping retrospectives for a month stops improvement and avoids the problem.

📋 Objective: 1.5 (Foster psychological safety)

✅ Correct answer: Test paper prototypes with drivers now

📌 Explanation: Shortening feedback loops means involving the people who will use the product from day one. Design thinking starts by empathising with users, and testing rough paper prototypes with drivers now exposes wrong assumptions about routes, loading and phone use when they cost almost nothing to change.

❌ Why the other options are wrong: Following the three-month plan delays any user feedback and relies on managers' second-hand views; showing drivers the finished app at launch makes their feedback the most expensive to act on; surveying managers by email still leaves the drivers, the actual users, out of the loop.

📋 Objective: 1.6 (Shorten feedback loops)

✅ Correct answer: Reorder the backlog toward offline lessons

📌 Explanation: Embracing change means adapting the product to learning and feedback with a growth mindset. Usage data shows the quiz builder misses the need, so the product owner reorders the backlog toward offline lessons and helps the team see the three sprints as cheap learning that redirected the product, not as failure.

❌ Why the other options are wrong: Completing the quiz builder as planned adds more effort to a feature teachers do not use; a formal change request adds bureaucracy to a backlog decision the product owner already owns; waiting for next year's survey ignores clear evidence that is available now.

📋 Objective: 1.7 (Embrace change)

✅ Correct answer: Arrange hands-on TDD training sessions

📌 Explanation: Training transfers a skill people do not yet have, coaching draws out answers people already have the knowledge to reach, and mentoring shares experience. Because no developer has written a unit test, hands-on TDD training builds the missing skill first; coaching can then help the team apply it to the banking API.

❌ Why the other options are wrong: Coaching through open questions cannot draw out a skill the developers do not yet have; mandating TDD from tomorrow sets a rule without building the capability to follow it; asking one senior developer to write the tests creates a silo and leaves the rest of the team unable to practise TDD.

📋 Objective: 2.1 (Empower teams)

✅ Correct answer: Run a team fishbone analysis

📌 Explanation: Recurring failures with several possible causes call for root cause analysis done with the team. An Ishikawa (fishbone) diagram groups causes such as test data, environment and merge timing, so the team sees which category drives the failures and chooses a fix that removes the cause rather than patching symptoms again.

❌ Why the other options are wrong: Making one developer own the build concentrates the problem on a single person and leaves the causes untouched; disabling the failing tests hides defects and weakens continuous integration; reporting to the IT director escalates before the team has investigated a problem it can solve itself.

📋 Objective: 2.2 (Facilitate problem resolution)

✅ Correct answer: Pair her with developers from both teams; Run weekly knowledge-sharing sessions on the engine

📌 Explanation: Knowledge sharing works best when it is built into the work. Pair programming lets developers from both teams learn the premium engine by changing it alongside her, and regular sessions, with time set aside in each sprint, spread the knowledge wider and leave shared notes before she relocates.

❌ Why the other options are wrong: Overtime adds strain without transferring knowledge to anyone; restricting engine changes to her deepens the single point of failure; a handover document requested after she leaves arrives when nobody can ask her questions.

📋 Objective: 2.3 (Promote knowledge sharing)

✅ Correct answer: Explain why velocity is team-specific

📌 Explanation: Promoting agile principles includes raising awareness of how agile measures are meant to be used. Velocity is a team's own planning tool on its own point scale, so ranking or rewarding teams by it invites inflated estimates and lower quality; the Scrum Master should explain this and suggest outcome measures instead.

❌ Why the other options are wrong: Normalising story points across the five teams strips the measure of its team-specific meaning and still invites gaming; publishing the ranking monthly turns a planning aid into a competition; setting a velocity target per team rewards point inflation rather than delivered value.

📋 Objective: 2.4 (Promote agile mindset principles and practices)

✅ Correct answer: Facilitate a shared product vision workshop

📌 Explanation: A shared vision gives everyone the same basis for decisions. Facilitating a workshop, using tools such as a vision statement or a product box, lets engineers, call-centre staff and finance agree one purpose for the app before the backlog fills with conflicting features.

❌ Why the other options are wrong: Letting each group write its own product goals entrenches the three competing purposes; asking the chief executive to decide imposes an answer the groups may not understand or support; adopting the finance view ignores the needs of the engineers and call-centre staff who will use the app.

📋 Objective: 2.5 (Promote shared vision and purpose)

✅ Correct answer: Facilitate a time-boxed spike comparing both

📌 Explanation: At this level the conflict is a problem to solve, so a collaborative approach fits best. A short spike that tests both options against agreed criteria such as offline behaviour and battery use turns opinion into evidence and lets the two developers reach a decision they both own.

❌ Why the other options are wrong: Choosing the design for them forces an outcome and takes ownership from the team; escalating to the head of engineering is premature for a respectful, fact-based disagreement; compromising on both designs adds complexity just to avoid choosing.

📋 Objective: 2.6 (Facilitate conflict management)

✅ Correct answer: Loyalty points (WSJF 5.0)

📌 Explanation: WSJF divides cost of delay (business value + time criticality + risk reduction) by job size. Loyalty points: (5 + 8 + 2) ÷ 3 = 5.0; fraud alerts: (3 + 13 + 8) ÷ 8 = 3.0; click-and-collect: (8 + 5 + 3) ÷ 8 = 2.0; supplier portal: (13 + 3 + 5) ÷ 13 = 1.6. Loyalty points has the highest WSJF, so it goes first.

❌ Why the other options are wrong: Fraud alerts has the highest cost of delay (24) but its job size of 8 lowers its WSJF to 3.0; the supplier portal has the highest business value (13) but the lowest WSJF at 1.6; click-and-collect scores only 2.0 because a cost of delay of 16 is spread over a job size of 8.

📋 Objective: 3.1 (Refine the product backlog)

✅ Correct answer: Have the outliers explain, then re-vote

📌 Explanation: Collective relative sizing works by surfacing different understandings. A spread from 2 to 13 points means team members see the story differently, so the highest and lowest estimators explain their reasoning, the team discusses the hidden work in the photo upload, and everyone re-votes until the estimates converge.

❌ Why the other options are wrong: Recording the average hides the disagreement and the risk behind it; letting the most senior developer decide alone abandons collective estimation; skipping the estimate leaves the story unsized when the spread shows it needs more discussion.

📋 Objective: 3.1 (Refine the product backlog)

✅ Correct answer: Measure abandonment against the 55% target

📌 Explanation: Managing value delivery includes confirming that targeted outcomes are achieved, not just that work shipped. Checking cart abandonment against the agreed 55% target shows whether the checkout delivered its value; if it fell short, the team can learn why and adapt before moving on.

❌ Why the other options are wrong: Closing the epic as delivered treats output as value without checking the outcome; reporting story points completed measures effort rather than business results; starting the next epic straight away skips the evidence that should shape what comes next.

📋 Objective: 3.4 (Manage value delivery)

✅ Correct answer: Release smaller increments each sprint

📌 Explanation: Seeking early feedback means delivering in small increments so customers can respond quickly. The team already finishes stories each sprint, so releasing them each sprint gets fixes to teachers within weeks and gives the team frequent, real feedback instead of once a term.

❌ Why the other options are wrong: Adding a test phase lengthens a release cycle that is already too slow; gathering teacher feedback at year end makes the loop even longer; bundling more fixes into the term release increases batch size and the delay teachers are complaining about.

📋 Objective: 4.1 (Seek early feedback)

✅ Correct answer: Handoffs between the three teams; The six-day wait for change approval

📌 Explanation: Lean treats delays and handoffs as waste. The map shows a process cycle efficiency of 3 ÷ 18 = 17%, so most of the lead time is waiting; the six-day queue for the weekly change board and the handoffs across three teams are the non-value-added time the team should target first.

❌ Why the other options are wrong: Automated regression tests on each build protect quality and flow, so they are not waste; the fifteen-minute daily scrum is a short coordination event rather than a delay here; hands-on coding of each fix is the value-adding time the map is meant to protect.

📋 Objective: 4.4 (Recognize and eliminate waste)

✅ Correct answer: Invite pharmacists to backlog refinement; Write acceptance criteria with pharmacists

📌 Explanation: Actively engaging customers means bringing them into the work, not just the sign-off. Inviting pharmacists to backlog refinement lets them explain real dispensing steps before stories are built, and writing acceptance criteria with them means deliverables are validated against how pharmacies actually work.

❌ Why the other options are wrong: Detailed specifications signed upfront repeat the gap between written requirements and real practice; dropping the pharmacists' acceptance tests removes the customer's check on value; collecting feedback only after go-live moves customer input to the most expensive point.

📋 Objective: 4.6 (Actively engage customers)

✅ Correct answer: Route requests through the board's intake

📌 Explanation: Optimising flow means limiting work in progress and shielding the team from interruptions. Routing requests through a single intake on the board, with an expedite class of service for genuine emergencies, makes the hidden work visible, keeps the WIP limits real and lets the team pull work in priority order.

❌ Why the other options are wrong: Raising the WIP limits to fit the requests hides overload and lengthens cycle time; holding sprint planning for each request imports a Scrum event that does not fit a Kanban flow team; letting developers decide privately keeps the work invisible and the interruptions unmanaged.

📋 Objective: 4.7 (Optimize flow)

✅ Correct answer: 7 sprints

📌 Explanation: Average velocity over the last four sprints is (28 + 34 + 31 + 35) ÷ 4 = 32 points. Remaining scope of 200 points ÷ 32 = 6.25 sprints, which rounds up to 7 whole sprints because a partial sprint still has to be run. With scope frozen, this empirical forecast is the most defensible figure for the sponsor.

❌ Why the other options are wrong: Six sprints rounds 6.25 down, or uses the best sprint alone (200 ÷ 35 = 5.7), and understates the time; eight sprints uses the worst sprint (200 ÷ 28 = 7.1, rounded up) and overstates it; fourteen sprints confuses sprints with weeks, because seven two-week sprints equal fourteen weeks.

📋 Objective: 4.2 (Manage agile metrics)

✅ Correct answer: Switch to a release burnup chart

📌 Explanation: A burndown nets new scope against completed work, so the 45 points added over sprints 6 to 8 hide a steady velocity of 31 to 35 points. A burnup chart shows completed work and total scope as separate lines, making it visible that the team is not slowing and that scope is growing.

❌ Why the other options are wrong: Rebaselining the burndown each sprint hides the scope growth even further; reporting velocity per developer misuses a team measure and says nothing about scope; an emailed progress summary replaces a visible, current chart with a static report.

📋 Objective: 3.3 (Visualize work)

✅ Correct answer: Run a data-led retrospective on defects

📌 Explanation: Continuous improvement uses metrics and feedback to drive change. Bringing the escaped-defect trend into a retrospective lets the team find the causes, agree an improvement such as stronger automated tests in the definition of done, and then check in later sprints whether defects fall.

❌ Why the other options are wrong: A hardening sprint defers quality to the end and treats symptoms rather than causes; skipping retrospectives to recover velocity removes the event designed to fix this; asking one developer to retrain blames an individual for what is likely a process problem.

📋 Objective: 4.5 (Perform continuous improvements)

✅ Correct answer: Add risk-response stories to the backlog

📌 Explanation: Managing risk proactively means engaging the team and prioritising mitigation alongside features. Turning each risk into backlog work, such as a spike on the new SMS gateway, a load test above 5,000 transactions a minute and audit preparation, creates a risk-adjusted backlog the team can rank, track on a risk burndown and act on before the deadlines.

❌ Why the other options are wrong: Making the sponsor own the register keeps the risks away from the team that must reduce them; reviewing the register at release end is too late for an SMS contract ending in ten weeks; a buffer sprint adds time but does nothing to reduce the risks themselves.

📋 Objective: 4.3 (Manage impediments and risk)

✅ Correct answer: Craft a sprint goal on onboarding

📌 Explanation: Managing increments means aligning each increment with business priorities through a clear goal. Under the Scrum Guide 2020, the product owner proposes how the product could increase its value and the whole Scrum Team crafts a sprint goal; a goal on merchant onboarding tells the head of merchants exactly what each sprint is for.

❌ Why the other options are wrong: Presenting the planned stories in priority order still leaves a list with no unifying objective; letting developers pick stories freely breaks the link to the quarter's priority; reporting points completed measures output, not what the increment delivers.

📋 Objective: 3.2 (Manage increments)