What to do when you are stuck. Real questions, practical answers, relevant concepts — one place.
These are the situations every BA faces. Each answer tells you what to do right now, not just what the theory says.
11 situations across 4 categories
Changing requirements are a signal, not a problem. They usually mean the stakeholder did not have enough clarity upfront, or the business environment changed. Your job is to turn that churn into a structured process.
This is one of the most common situations a BA faces. The stakeholder is not being difficult — they genuinely cannot articulate needs in the abstract. The solution is to give them something concrete to react to.
A vague requirement almost always lacks one of three things: a defined actor, a defined trigger, or a defined measurable outcome. Check your requirement against all three before going back to the developer.
Never prioritise alone. Prioritisation without stakeholder input is just a BA's guess — it has no authority. Your job is to facilitate the decision, not make it unilaterally.
This is not a BA problem to solve — it is a governance problem. Your role is to surface the conflict clearly and escalate it to the right decision-maker, not to pick a side.
Blocked access to a key stakeholder is a project risk, not a personal problem. Escalate it as a risk — do not just keep sending meeting invites that get ignored.
A story rejected at Sprint Planning has almost always failed the Definition of Ready. Run through the DoR checklist against the story and you will find the gap within a few minutes.
This is almost always a Definition of Done or Acceptance Criteria failure. The story was built against the developer's interpretation rather than a testable, agreed specification.
A Kanban board where work piles up usually has one of two problems: no work-in-progress limits, or items are too large to move across the board in a reasonable time.
The format follows the methodology. In Waterfall or Hybrid projects with formal sign-off gates, write a BRD. In Agile projects, write User Stories. In many real enterprises, you write both.
Detailed enough that a tester who has never spoken to the stakeholder can write a test that passes or fails against each criterion without making any assumptions.
