The Close Out of Timebox B was completed as scheduled, but the Could Have requirement of tiled walls in the bathrooms was NOT delivered within this period, with the agreement of the team. Which…

Question

Options

• ADeliver on time.
• BNever compromise quality.
• CBuild incrementally from firm foundations.
• DDevelop iteratively.

• A
  88% (57)
• B
  2% (1)
• C
  8% (5)
• D
  3% (2)

Explanation

"Deliver on Time" is correct because in DSDM/AgilePM, the timebox end date is fixed and non-negotiable - scope is what flexes. "Could Have" requirements exist precisely to be dropped when needed to protect the delivery deadline, and the team's agreement to do so is the standard mechanism for keeping the timebox on schedule.

B ("Never compromise quality") is wrong because quality refers to the standard of work actually delivered, not the volume of features. Dropping a Could Have doesn't lower quality - it maintains it by ensuring finished work meets acceptance criteria rather than rushing incomplete work through.

C ("Build incrementally from firm foundations") is wrong because this principle governs how the solution is constructed across multiple deliveries; it doesn't explain why a specific requirement was de-scoped within a single timebox.

D ("Develop iteratively") is wrong because iteration refers to refining and revisiting the solution through feedback cycles - it's about how work evolves, not about the scope decision made to honor a deadline.

Memory tip: Think of the "Could Have" MoSCoW band as the timebox's safety valve - it exists so the team can always deliver on time. If you see a scenario where the clock wins and a low-priority item is dropped by agreement, the answer is almost always A.

No community discussion yet for this question.