Role & Behavioral Cases
The role and soft-skill cases every loop asks — systems vs business analyst, junior vs senior, proving the analyst's value, stakeholder conflict, unresponsive customers, and communicating constraints.
11 questions
JuniorDesignVery commonA stakeholder drops a one-line request into the team chat — «we need a dashboard» — with no context, no audience, and no goal, and asks for an estimate by tomorrow. As the analyst, what do you do first, before any design or estimate? Walk through how you turn this vague ask into something workable — whom you talk to, what you ask, and how you avoid guessing the scope.
A stakeholder drops a one-line request into the team chat — «we need a dashboard» — with no context, no audience, and no goal, and asks for an estimate by tomorrow. As the analyst, what do you do first, before any design or estimate? Walk through how you turn this vague ask into something workable — whom you talk to, what you ask, and how you avoid guessing the scope.
Don't estimate a guess. First find who wants it and why — the goal behind «a dashboard». Then elicit specifics: the decisions it drives, the users, the data. Turn that into a few concrete requirements, confirm them, and only then size the work.
Common mistakes
- ✗Estimating the request before its goal or users are known
- ✗Relaying the vague ask to developers without any analysis
- ✗Guessing the scope instead of eliciting it from the stakeholder
Follow-up questions
- →Which questions most quickly expose the real goal behind a vague ask?
- →How do you handle a stakeholder who resists answering clarifying questions?
JuniorDesignVery commonA product owner explains a new requirement to you verbally in a five-minute hallway chat and expects it in the next sprint. You are not sure you and they picture the same thing. Before development starts, how do you confirm that your understanding matches theirs? Describe what you do to close the gap between what was said and what you write down.
A product owner explains a new requirement to you verbally in a five-minute hallway chat and expects it in the next sprint. You are not sure you and they picture the same thing. Before development starts, how do you confirm that your understanding matches theirs? Describe what you do to close the gap between what was said and what you write down.
Play it back in your own words and in concrete terms — an example, a mock, or acceptance criteria — and ask the PO to confirm or correct it. Written confirmation beats a nod. Surface edge cases and assumptions; if they disagree, you caught the gap before code.
Common mistakes
- ✗Assuming a verbal explanation was understood without confirming it
- ✗Recording a verbatim quote instead of a checkable restatement
- ✗Starting development before the shared understanding is confirmed
Follow-up questions
- →Which artifact best confirms shared understanding — an example, a mock, or acceptance criteria?
- →How do you confirm understanding without making the PO feel interrogated?
JuniorDesignCommonMid-sprint you realize an external dependency will almost certainly push a committed feature a week past its promised date. The customer does not know yet. How do you communicate this risk, and when? Describe what you tell them, how early you raise it, and how you frame it so it stays a manageable conversation rather than a broken promise.
Mid-sprint you realize an external dependency will almost certainly push a committed feature a week past its promised date. The customer does not know yet. How do you communicate this risk, and when? Describe what you tell them, how early you raise it, and how you frame it so it stays a manageable conversation rather than a broken promise.
Raise it as soon as you are reasonably sure, not at the deadline. State the risk plainly — what is affected, why, the likely impact — then bring options: less scope on time, full scope later, or a mitigation, with a clear recommendation.
Common mistakes
- ✗Delaying the bad news until the deadline is already missed
- ✗Reporting the problem without any options or recommendation
- ✗Overpromising the date and hiding the slip with overtime
Follow-up questions
- →How do you quantify a risk's impact when the delay is still uncertain?
- →How does communicating risk differ for an internal team versus an external customer?
MiddleDesignCommonReviewing an already-approved specification, you notice two requirements contradict each other — one says orders under a threshold are auto-approved, another says every order needs manual manager approval. Both were signed off. Development starts next week. What do you do when the conflict is inside the written requirements themselves, not between people? Describe how you confirm, resolve, and record it.
Reviewing an already-approved specification, you notice two requirements contradict each other — one says orders under a threshold are auto-approved, another says every order needs manual manager approval. Both were signed off. Development starts next week. What do you do when the conflict is inside the written requirements themselves, not between people? Describe how you confirm, resolve, and record it.
Confirm it is a real contradiction, not two contexts conflated. Trace each requirement to its owner and goal, then bring the owners together to decide which rule wins or how they coexist. Update both so the spec is consistent, and record it.
Common mistakes
- ✗Silently deleting one requirement without involving its owner
- ✗Leaving both contradictory requirements for developers to reconcile
- ✗Deferring the conflict to testing instead of resolving it in the spec
Follow-up questions
- →How do you tell a true contradiction from two requirements with different valid contexts?
- →What review practice catches such contradictions before sign-off?
MiddleDesignCommonThe backlog contains one item — «add a reporting module» — and the team is asked to plan it this sprint. There is no detail beyond the title. How do you decompose this vague feature into something the team can estimate and build incrementally? Describe how you break it down, what you clarify first, and how you decide the first slice to deliver.
The backlog contains one item — «add a reporting module» — and the team is asked to plan it this sprint. There is no detail beyond the title. How do you decompose this vague feature into something the team can estimate and build incrementally? Describe how you break it down, what you clarify first, and how you decide the first slice to deliver.
Recover the goal and users first, then split by delivered value, not by layer. Turn each report — its data, filters, access — into a thin end-to-end slice that ships something usable. Sequence the highest-value slice first; estimate slices, not the blob.
Common mistakes
- ✗Splitting by technical layer so nothing is usable until the end
- ✗Estimating the whole module as one undivided item
- ✗Committing to every possible report before delivering a first slice
Follow-up questions
- →How do you choose which slice delivers value first?
- →How thin can a vertical slice get before it stops being shippable?
MiddleDesignCommonA neighbouring team owns an API your feature depends on, and they have not responded to your integration request for three sprints. The deadline is now at risk, and your polite reminders go unanswered. Do you escalate, and if so, how — without turning it into a complaint about people? Describe how you decide it is time, whom you involve, and how you frame the escalation so it stays about the blocker, not blame.
A neighbouring team owns an API your feature depends on, and they have not responded to your integration request for three sprints. The deadline is now at risk, and your polite reminders go unanswered. Do you escalate, and if so, how — without turning it into a complaint about people? Describe how you decide it is time, whom you involve, and how you frame the escalation so it stays about the blocker, not blame.
Escalate once you have tried directly, set a clear ask and deadline, and the block still threatens delivery. Keep it about the risk, not people: name the dependency, its impact on the date, and the decision you need. Go to whoever can unblock it.
Common mistakes
- ✗Escalating on the first missed reply and framing it as blame
- ✗Never escalating and silently absorbing the delay
- ✗Routing around the dependency without raising the blocker
Follow-up questions
- →What should a good escalation message actually contain?
- →How do you preserve the peer relationship after escalating over them?
MiddleDesignCommonThe customer has not answered your clarifying questions for two weeks, several requirements are still open, and the sprint starts Monday with the team expecting work. You cannot get sign-off in time. How do you decide what the team builds, and how do you protect yourself if your assumptions turn out wrong? Describe how you prioritize the known scope and proceed responsibly under the silence.
The customer has not answered your clarifying questions for two weeks, several requirements are still open, and the sprint starts Monday with the team expecting work. You cannot get sign-off in time. How do you decide what the team builds, and how do you protect yourself if your assumptions turn out wrong? Describe how you prioritize the known scope and proceed responsibly under the silence.
Build what is clear and low-risk first; defer whatever hinges on the open questions. Document explicit assumptions for the gaps and send them as «this is what we build unless you say otherwise». Keep a written trail and escalate the silence in parallel.
Common mistakes
- ✗Building the most uncertain items on a guess without documenting assumptions
- ✗Halting the whole sprint instead of proceeding on the clear scope
- ✗Self-approving requirements and hiding the customer's silence
Follow-up questions
- →How do you rank the known scope when value and risk point in different directions?
- →How do you word an assumption so that silence counts as tacit agreement safely?
MiddleDesignCommonTwo days into a sprint, a senior stakeholder pulls you aside and asks the team to «just make it work the other way» — directly contradicting behavior fixed in the signed specification (ТЗ) the whole team is building against. They expect it done quietly and quickly. How do you handle the stakeholder and the request without either ignoring them or letting the baseline drift uncontrolled? Describe your steps.
Two days into a sprint, a senior stakeholder pulls you aside and asks the team to «just make it work the other way» — directly contradicting behavior fixed in the signed specification (ТЗ) the whole team is building against. They expect it done quietly and quickly. How do you handle the stakeholder and the request without either ignoring them or letting the baseline drift uncontrolled? Describe your steps.
Don't silently comply and don't just refuse. Acknowledge the need, but treat it as a change to a signed baseline, not a hallway tweak. Clarify the goal, assess impact on scope and timeline, and route it through change control. If urgent, get the right approver.
Common mistakes
- ✗Quietly implementing an off-baseline request from a senior voice
- ✗Flatly refusing without exploring the goal or offering a change path
- ✗Building both versions to avoid the conversation, leaving the spec stale
Follow-up questions
- →What belongs in a lightweight change request for an urgent tweak?
- →How do you keep a good relationship while insisting on change control?
SeniorDesignOccasionalA developer tells you a requirement you specified is «technically impossible» and cannot be built. The business is counting on it, and you are not deeply technical yourself. How do you check whether the claim is true, and what do you do next in either case? Describe how you probe the constraint, tell a hard limit from a costly-or-unfamiliar one, and drive the requirement to a workable outcome without steamrolling the developer or the business.
A developer tells you a requirement you specified is «technically impossible» and cannot be built. The business is counting on it, and you are not deeply technical yourself. How do you check whether the claim is true, and what do you do next in either case? Describe how you probe the constraint, tell a hard limit from a costly-or-unfamiliar one, and drive the requirement to a workable outcome without steamrolling the developer or the business.
Treat «impossible» as a starting point, not a verdict. Ask what specifically blocks it — a hard limit, a cost, a missing skill — and get a concrete reason. Separate «cannot» from «expensive» or «unfamiliar». If the limit is real, take options to the business.
Common mistakes
- ✗Accepting «impossible» at face value without a concrete reason
- ✗Overruling the developer and forcing the original requirement
- ✗Confusing a real hard limit with something merely costly or unfamiliar
Follow-up questions
- →Which questions separate a true limit from an expensive workaround?
- →How do you bring in a second technical opinion without undermining the first developer?
SeniorDesignOccasionalDescribe a real analysis mistake of your own that reached production — a missed requirement, an ambiguous spec, an unvalidated assumption — that caused a visible problem. What was the cost, how was it caught, and, more importantly, what did you change in how you work so the same class of mistake could not recur? Focus on the systemic fix, not just the apology.
Describe a real analysis mistake of your own that reached production — a missed requirement, an ambiguous spec, an unvalidated assumption — that caused a visible problem. What was the cost, how was it caught, and, more importantly, what did you change in how you work so the same class of mistake could not recur? Focus on the systemic fix, not just the apology.
Own a specific mistake and its impact honestly, then focus on the systemic fix, not blame. The root cause is usually an unvalidated assumption or ambiguous requirement. Change the process — a review step or acceptance criteria — to prevent the whole class of error.
Common mistakes
- ✗Denying any mistake or blaming developers and testers
- ✗Patching the single instance with no process change
- ✗Over-correcting into heavyweight process on everything
Follow-up questions
- →How do you decide whether a fix should be a process change or a one-off?
- →How do you share a lesson from a mistake without blaming the team?
SeniorDesignRareA skeptical client challenges you directly — «developers can talk to me themselves; prove that I need an analyst on this project at all». You have one conversation to make the case. How do you justify the role in terms the client actually cares about — cost, risk, and delivery — rather than listing tasks you perform? Describe the argument you make and the concrete value you point to.
A skeptical client challenges you directly — «developers can talk to me themselves; prove that I need an analyst on this project at all». You have one conversation to make the case. How do you justify the role in terms the client actually cares about — cost, risk, and delivery — rather than listing tasks you perform? Describe the argument you make and the concrete value you point to.
Argue in the client's terms — money and risk, not titles. Without an analyst, developers translate needs part-time, so ambiguity reaches code and is fixed late, when it costs most. The analyst cuts rework, keeps one requirement source, and frees developers to build.
Common mistakes
- ✗Defending the role by listing artifacts or citing methodology
- ✗Conceding the role is unnecessary instead of making the value case
- ✗Framing the analyst as a gatekeeper who blocks direct communication
Follow-up questions
- →How would you prove the analyst's value on a single slice of work?
- →Which metric best shows the cost of ambiguity reaching development?
