PMP · Question #1180
An agile project team discovers that they are unable to implement a feature completely in the first iteration. The team believes it may not be able to complete the tasks in the second iteration. The f
The correct answer is B. Split the feature into smaller subfeatures, implement them, and then deliver them incrementally in. For a critical feature too large for one or two iterations, an agile team should split it into smaller, manageable subfeatures and deliver them incrementally to maintain progress and provide value.
Question
Options
- AGo back to the customer and explain that they cannot implement the feature completely in one
- BSplit the feature into smaller subfeatures, implement them, and then deliver them incrementally in
- CAsk the customer to simplify the feature so that it can be implemented in one iteration.
- DReduce the scope of the feature to fit into one iteration and deliver it to the customer.
How the community answered
(27 responses)- A7% (2)
- B70% (19)
- C4% (1)
- D19% (5)
Why each option
For a critical feature too large for one or two iterations, an agile team should split it into smaller, manageable subfeatures and deliver them incrementally to maintain progress and provide value.
Simply informing the customer without offering a solution or strategy for completion is not proactive and can lead to dissatisfaction.
In agile, large or complex features should be broken down into smaller, manageable subfeatures that can be implemented and delivered incrementally. This approach allows the team to provide continuous value, gather feedback earlier, and mitigate the risk of not completing a critical component within a single iteration.
Asking the customer to simplify a critical feature might compromise its value or intended functionality, which should be avoided unless absolutely necessary and agreed upon.
Reducing the scope of a critical feature without full customer agreement could result in delivering an incomplete or less valuable product, failing to meet the customer's prioritized need.
Concept tested: Agile principles: breaking down work and incremental delivery
Source: https://www.scrum.org/resources/scrum-guide#product-backlog
Topics
Community Discussion
6B is the answer here. Agile is all about delivering working increments, so splitting a large feature into smaller subfeatures and delivering them across iterations is exactly what the team should do. A lot of people get drawn to A because communicating with the customer sounds right, but just telling them you cannot do it without offering a solution is incomplete. C and D are traps because asking the customer to simplify or cutting scope on a critical feature just to fit one iteration defeats the purpose of iterative delivery.
Agree on B, but the real program-level lens here is that splitting features into deliverable increments protects benefits realization across the component, not just within a single iteration.
B is the answer. Saw this on my exam last month and the key word is "incrementally" which maps directly to agile delivery. C and D are traps because they ask the customer to compromise instead of the team doing the work of breaking the feature down.
B is the right call. In agile you break down work and deliver value incrementally, so splitting the feature into smaller pieces lets the team keep momentum instead of stalling on something too big for one iteration. Spin up a quick sprint simulation in your head and you can see how incremental delivery keeps the customer in the loop.
B is the right call here because incremental delivery through decomposition protects benefits realization across iterations rather than forcing an all-or-nothing gamble on a critical component. One thing worth examining: how does the program governance framework handle traceability when a single feature gets split across multiple iterations, and does that fragmentation create any risks for downstream component interdependencies?
Agree on B but in my last three practice sets the traceability question is where people lose points, since the exam wants you to map the decomposed feature back to a specific benefit in the benefits register, not just track it across iterations.