Elicitation - Mistake¶

When to use it¶

• Use a full elicitation loop when work changes a user journey, a business rule, an integration, or a cross-team handoff. The cost of a misunderstood rule is usually much higher than a short discovery session.
• Use a lighter loop for a small, familiar change. Confirm the outcome, rule, affected people, and proof of success in writing; do not schedule a workshop just to rename a button.
• The benefit is less rework and fewer hidden assumptions. The team can explain why it is building something and what must be true when it is done.
• The cost is time and attention from people who know the work. Keep sessions focused, bring existing evidence, and ask only for the decisions or facts you need next.

Common mistakes¶

• Treating the requested feature as the requirement. “Add cancellation” skips the customer outcome, timing rule, and refund promise. Fix: ask what problem the feature should solve, then write the need and the measurable result before naming a solution.
• Asking only the requester. A product manager may know the goal while support, warehouse, finance, or customers know the hard cases. Fix: map who uses, operates, approves, supports, or is harmed by the change; include the people with different evidence.
• Starting with “what do you want?” and stopping there. People often know the pain better than the best solution. Fix: ask about a recent real case, the current path, the desired outcome, and the rule that separates allowed from disallowed cases.
• Collecting opinions without checking the work. A confident answer can describe an old policy or an ideal process. Fix: read the policy, inspect a real order, observe the work, or test the interface that enforces the rule.
• Skipping edge cases because the happy path sounds clear. The cancellation button works until picking starts, a partial refund is needed, or a guest order has no account. Fix: ask “when does this not apply?”, “what must never happen?”, and “what happened in the last exception?”
• Writing notes nobody confirms. The analyst may have heard “before dispatch” while operations meant “before picking.” Fix: show back a short scenario, flow, or acceptance examples and ask the knowledgeable people to correct it.
• Treating elicitation as a one-time phase. A prototype, design choice, or integration test often exposes a missing rule. Fix: revisit the open assumptions as the work changes; IIBA describes elicitation and collaboration as ongoing work.
• Chasing perfect detail before making progress. Endless questions can delay a small, reversible improvement. Fix: state what is known, what is uncertain, the risk of being wrong, and the next smallest test or decision.

Continue to Best Practise.