Product practice questions

MoSCoW sorts scope into Must have, Should have, Could have and Won't have this time, which is useful when the date is fixed and scope flexes.

The four groups map one-to-one to MoSCoW. 'Agreed not to be delivered this time' is the Won't-have group that makes MoSCoW distinctive. The other techniques produce satisfaction categories, a ranked order or point weights.

1. List the four groups in the stem.
2. Map them to Must, Should, Could and Won't.
3. Rule out techniques that produce scores or satisfaction categories.

Exam tip: Must, Should, Could, Won't (this time): MoSCoW is how fixed-date releases agree what can flex.

The Kano model classifies features by how they affect satisfaction: must-be (basic), performance (more is better) and attractive (delighters), plus indifferent and reverse.

Asking how customers feel with and without each feature, then sorting into basic, performance and delighter groups, is Kano analysis. The other techniques also involve customers or stakeholders, but they rank by commitment, weighted scores or spending.

1. Notice the paired with/without questions.
2. Notice the output categories: basic, performance, delighter.
3. Match them to the Kano model.

Exam tip: Kano asks how customers feel with and without a feature: basics prevent dissatisfaction, delighters create excitement.

User stories follow the three Cs: Card, Conversation, Confirmation. Clarifying a backlog item is a conversation between the team and the product owner, confirmed by acceptance criteria.

The ambiguity is about intent, and the product owner who holds that intent is present. Talking it through now is the fastest route to a shared understanding. A written specification delays and replaces dialogue, the developers guessing risks building the wrong thing, and sizing before understanding gives a meaningless estimate.

1. Identify what is unclear: intent and scope.
2. Identify who holds the answer: the product owner, who is present.
3. Choose the action that clarifies through direct conversation before sizing.

Exam tip: A story is a promise of a conversation: clarify it with the product owner, then confirm it with acceptance criteria.

Acceptance criteria are the conditions a specific backlog item must satisfy to be accepted. Writing them with concrete examples during refinement exposes edge cases early.

The gap was a story-specific rule (expired cards) that nobody discussed. Acceptance criteria with examples are the refinement practice that catches these. The definition of done is the near-twin trap: it holds standards common to all items, so it is the wrong home for one story's rule.

1. Classify the missing item: a business rule of one story.
2. Separate story-level acceptance criteria from the team-wide definition of done.
3. Choose the practice that surfaces edge cases during refinement.

Exam tip: Acceptance criteria are per story and clarify the business rules; the definition of done is shared by all items.

A definition of ready is an optional team agreement on the state a backlog item must reach in refinement before it is taken into an iteration.

The problem is items entering planning before they are prepared, and the constraint is a shared agreement with no extra approval. That is a definition of ready. The definition of done is the tempting near-twin, but it describes the end of the work, not its entry.

1. Locate the problem: items enter planning unprepared.
2. Note the constraint: a shared agreement, no approval gate.
3. Choose the entry criterion, not the exit criterion.

Exam tip: Definition of ready guards the start of the work; definition of done guards the end.

Product backlogs are progressively elaborated: items near the top are small and detailed, items further down stay large and coarse until they approach delivery.

Feedback is expected to change the later features, so detailing them now is waste. The backlog should be detailed just in time, a few iterations ahead. Spreading the effort or splitting early repeats the same timing mistake, and freezing scope defeats the feedback loop.

1. Note the expectation: feedback will reshape later features.
2. Recall that backlog detail should follow priority and proximity.
3. Choose the option that limits detail to near-term items.

Exam tip: Refine just in time: detailed at the top, coarse at the bottom.