PMP Predictive, Agile and Hybrid: Choose a Response From Context (2027 Prep)

A warehouse supervisor asks for an extra confirmation screen in a stock-scanning tool. The request is small enough to describe in one sentence, but you still need to know which work it affects and who can authorize it.

Read the context first. A baselined installation project, a Scrum product team and a combined hardware-and-software project can receive the same request with different responsibilities and commitments in place.

The fictional comparisons below make those conditions explicit. Use them to practice explaining why a response fits the situation, including the approval boundary that supports the action, then change one condition and reconsider your explanation. They are original teaching cases, with no official or recalled exam questions and no rule that predicts the correct answer from one keyword.

Locate the approach and authority in the scenario

The current PMP Examination Content Outline includes choosing a development approach, managing changes and establishing governance. These connections support studying delivery context alongside decision authority. This article's 2027 label identifies its preparation edition, while the outline remains the source for current exam scope.

Look for the assigned control. A scenario might state that a change board approves baseline changes, that a Product Owner orders future work, or that a contract limits what can be changed without agreement. Those facts are stronger evidence than an isolated word such as meeting or backlog.

PMI's 2021 tailoring-process explainer describes selecting an approach and adjusting it for the organization and project. It is dated background for tailoring, rather than a new 2027 specification. The examples here give each project its own stated rules so you can see how those rules affect the request.

Clarify what the supervisor wants to change

In all three examples, the supervisor wants a second screen that displays the item and quantity before the operator submits a stock movement. The intended benefit is fewer accidental submissions. The team has not yet established how much that extra screen would reduce errors.

Ask about the problem. Find out which submissions are going wrong and whether the proposed screen would help the operators who make them. A detailed request can still contain an untested assumption about its benefit.

The comparison follows the approval route. It does not assume the team should build the screen, reject the request, or abandon its current delivery approach merely because a stakeholder suggested a change.

Predictive case: assess the proposed baseline change

In the first fictional project, the scanning installation has approved scope and a scheduled acceptance date. The confirmation screen is outside that scope. The project's change plan assigns approval of scope-baseline changes to a change board.

Assess the impact. The team examines design effort and testing, along with any effect on training or acceptance. Give the board enough evidence to consider the proposed benefit and the consequences for the existing commitment.

Follow the stated control. A project manager who immediately instructs a developer to build the screen would skip the approval assigned in this case, even if the estimate looks small. Rejecting it solely because planning is complete would also leave its potential benefit unevaluated.

If approved, update the affected plans and records through the agreed process and communicate the decision. These board responsibilities belong to our fictional project. The label predictive alone does not tell you the approval threshold of every real organization.

Scrum case: distinguish future work from the current Sprint

The second case is a product team explicitly using Scrum. The requested screen concerns future product work, and the organization permits the Product Owner to order the Product Backlog within the agreed funding boundaries. No contract or compliance change is stated.

Discuss the need with the Product Owner and team, clarify the item, and consider its place among other work. The case provides no reason to promise immediate implementation or to send every routine ordering decision to the installation project's change board.

The Scrum Guide makes the Product Owner accountable for Product Backlog ordering. During a Sprint, changes must preserve its goal, and Developers can negotiate scope with the Product Owner as they learn. Scrum is the framework specified in this case, so these accountabilities should not be assigned automatically to every agile team.

Now move the request into the current Sprint. Ask how it affects the Sprint Goal and the work in progress before agreeing to an adjustment. Future backlog priority and a change to current work are different decisions, even when the feature description stays the same.

Hybrid case: check the interface between components

In the third project, the software team uses a backlog while the scanner installation follows an approved hardware plan. A shared interface specification connects the two. The case's governance requires approval when a proposal changes that specification or the committed installation date.

Trace the dependency. The screen might fit existing devices. A change to how the scanner sends a confirmation could instead require firmware work and another round of integrated acceptance testing before release. You need that evidence to identify the affected control route.

Suppose testing confirms that the proposed screen requires new firmware and would move the installation date because the devices must be retested before the warehouse accepts them. Ordering the software backlog would address only part of the change. Prepare the combined impact for the authority assigned to the interface and milestone decisions.

If the screen instead fits the current interface and approved boundaries, the software team can evaluate future work through its permitted backlog process. Record the evidence supporting that conclusion so the hardware team can see why its commitment is unaffected.

Compare the cases using facts rather than shortcuts

The table keeps the request constant while varying the project conditions, with each proposed route following an authority or boundary explicitly stated in the case. It is a comparison tool, not a universal predictive/agile/hybrid answer key.

Read across a row. The approach provides context, the stated condition identifies the control, and the reason explains why the proposed next step respects that control. If a question supplies a different authority, reconsider the action using that authority.

Collaboration belongs in all three cases. The supervisor can explain the error, operators can discuss usability, and the team can assess effort regardless of the delivery approach. Collaboration alone does not identify the person authorized to approve a commitment.

Change a constraint and test the explanation again

Add a contract condition to the Scrum case. The proposed screen would now change an agreed customer acceptance obligation, and the organization requires authorized contract review for that change.

Check the boundary. Backlog ordering cannot by itself amend the customer's agreement. The team still uses Scrum, but it must also follow the additional control stated in this variation before making a commitment that changes the obligation.

Try another variation. In the predictive case, the extra confirmation is already required by the approved scope, but the team omitted it. That may be a delivery defect requiring correction under the project's quality process rather than a request to add new scope.

Verify the record. Compare the approved requirement with what was delivered before classifying the work. The same words from the supervisor can describe new scope in one case and a missing requirement in another.

Keep a decision record for your next study case

The blank project-change decision record (CSV) has fields for the affected work, stated authority, current commitment, impact evidence and proposed action. Write the facts from a fictional study case before explaining your response in a sentence.

Use a reason you can test. "Assess the firmware and installation impact because the proposal crosses the shared interface" names the condition supporting the action. "Hybrid means use both processes" would leave you unable to explain which decision each process controls.

Our PMP study hub collects PMP study resources. Use the current outline to choose your next topic, then make a fresh decision record for a reporting feature or a training change. Keep the authority and affected commitment visible while you explain the next action.

2027 preparation edition. Official public sources checked October 11, 2026. The three stock-scanning cases, authority assignments, interface changes and variations are original fictional teaching material. PMI 2021 tailoring material is dated background; current ECO establishes exam scope. Scrum accountabilities apply to the explicitly identified Scrum case. No official or recalled questions, exam answer guarantee, universal approval hierarchy or claimed professional credential.