Business analyst case study interview: a full worked example

In a business analyst case study interview, you get a vague business problem and must show how you would structure it. Clarify the goal and scope, ask who the stakeholders are, find root causes with data, map the current and future process, write prioritised requirements and user stories, and define how success will be measured.

Most guides to business analyst case studies give you a list of frameworks and stop there. That is not how the interview feels. You get a messy problem, a whiteboard or a shared doc, and 30 to 45 minutes. The interviewer wants to watch you think.

So instead of another list, this post solves one full case the way a strong candidate would, step by step, with the actual questions and artefacts. Use it as a template. For shorter question-and-answer practice, our business analyst interview questions page covers the rest of the round.

What does a business analyst case study interview test?

Behind every case, the interviewer is scoring a few core skills:

• Structuring ambiguity: can you turn a vague complaint into a clear problem statement?

• Stakeholder thinking: do you ask who is affected and who decides?

• Data instinct: do you look for evidence before proposing solutions?

• Requirements craft: can you write clear, testable requirements and user stories?

• Prioritisation: do you know what to build first and why?

• Communication: can you explain your reasoning simply as you go?

Notice that "picking the right answer" is not on the list. There is rarely one right answer. A clear, well-reasoned path matters far more.

The case: a food delivery app with rising cancellations

Here is a prompt similar to what product companies and consultancies use:

Interviewer: We run a food delivery app in five Indian cities. Over the last quarter, order cancellations have gone up and the business head is worried. You are the business analyst on this. How would you approach it?

Let us follow Ananya, a BA with three years of experience, through her answer. Her steps work for almost any case, whether it is a bank onboarding flow, an HR portal or an insurance claims process.

Step 1: What clarifying questions should you ask first?

Ananya does not jump to solutions. She spends the first five minutes asking questions, and says out loud why each one matters.

1. "Who is cancelling: customers, restaurants, or the system after a delivery partner is not found?" Each has a different root cause.

2. "When do cancellations happen: before the restaurant accepts, during preparation, or after pickup?"

3. "Is the rise across all five cities or concentrated in one or two?"

4. "Did anything change last quarter, such as a new release, a pricing change or a new restaurant partner group?"

5. "What is the business goal: reduce cancellations to a target, or protect revenue and customer ratings?"

6. "Who are the main stakeholders, and who owns the final decision?"

Suppose the interviewer replies: most of the rise is customer cancellations, mostly after the order is accepted but before pickup, concentrated in two cities, and an estimated delivery time redesign went live last quarter. The goal is to bring cancellations back to the earlier level without hurting order volume.

That one exchange has already narrowed the problem dramatically. This is exactly what the interviewer wants to see.

Then write a one-line problem statement

Ananya summarises in one sentence before moving on. This checks alignment and shows structure.

So the problem is: customer cancellations between restaurant acceptance and pickup have risen in two cities since the new delivery time estimates launched, and we want to bring them back to the earlier level without reducing order volume. Is that a fair summary?

Step 2: How do you find the root cause?

Now she builds hypotheses and says what data would confirm or reject each one. A simple table keeps it clear on the whiteboard.

She would also talk to people, not just data: a short call with the city operations lead, a look at support tickets, and a few customer reviews. Qualitative input often explains what the numbers cannot.

The interviewer then tells her the delivery time gap did widen after the release, and cancellations spike within a couple of minutes of a delay notification. That points to the estimate design as the main cause.

Step 3: How do you map the current and future process?

Ananya sketches the current flow in a few boxes: order placed, restaurant accepts, estimate shown, partner assigned, delay detected, customer notified, customer cancels. Then she proposes a future flow with changes at the weak points.

• Calculate the first estimate using real preparation time per restaurant and current partner availability, not a city average.

• Show a time range instead of a single exact minute, so small slips do not feel like broken promises.

• When a delay happens, explain why and offer something useful, such as a small coupon, rather than only showing a new time.

• Flag restaurants with repeated preparation delays to the partnerships team.

She keeps each change tied back to a root cause. That link is what separates a BA answer from a random brainstorm.

Step 4: How do you turn this into requirements and user stories?

Next, she writes requirements at two levels. A business requirement states the outcome. Functional requirements and user stories describe what the system must do.

Business requirement: reduce post-acceptance customer cancellations in the two affected cities back to the earlier level, while keeping weekly order volume stable.

User story: As a customer waiting for my order, I want to see a realistic delivery time range, so that I can plan and am not surprised by delays. Acceptance criteria: Given an order is accepted, when the estimate is shown, then it is displayed as a range based on that restaurant's recent preparation times and current partner availability. Given the predicted arrival moves outside the range, when the customer is notified, then the message states the reason and the new range. Given a delay of more than a set threshold, when the notification is sent, then a compensation coupon is offered automatically.

Then she prioritises using MoSCoW. The range-based estimate is a Must, because it targets the main cause. The delay explanation is a Should. The coupon is a Could, pending a cost check with finance. The restaurant flagging report is a Should for the partnerships team.

Step 5: How do you measure success and close the case?

A strong close covers metrics, rollout and risks in about two minutes.

• Primary metric: post-acceptance customer cancellation rate in the two cities.

• Guardrail metrics: order volume, average delivery time and customer rating, so the fix does not quietly hurt something else.

• Rollout: A/B test the new estimate in one city first, compare against the second city, then expand.

• Risks: wider ranges might reduce conversion at checkout; coupons add cost. Both are tracked as guardrails.

• Stakeholders: product owner for priority, engineering for feasibility, operations for partner supply, finance for coupon budget.

Finally, she asks the interviewer if they would like her to go deeper on any part. It is a confident, collaborative finish.

How can you practise case studies on your own?

First, know the mistakes that sink most case answers:

• Proposing a solution in the first minute, before asking a single question.

• Asking ten clarifying questions with no visible reason for any of them.

• Listing frameworks by name instead of using them on the problem in front of you.

• Writing requirements that cannot be tested, such as "the app should be faster".

• Forgetting guardrail metrics, so the fix could quietly damage revenue or ratings.

• Going silent while thinking. Narrate your reasoning, even when you are unsure.

Take any app you use daily, such as a banking app, a ride-hailing service or your company's HR portal, invent a problem like "drop-offs went up", and run all five steps in 30 minutes. Do it aloud. The talking is the hard part.

When you explain past work during the same interview, our STAR method examples keep your stories tight. A timed mock interview is the best way to check whether you are spending too long on clarifying questions or rushing to solutions.

If you are already in a new BA role and facing a real version of this problem at work, Job Support for business analysts can help you structure requirements and stakeholder updates in your first 90 days.

Want to try a case study with feedback tonight? Create a free InterviewPlan AI account with 5 live minutes and 100 AI credits, no card needed, and run a business analyst mock interview before the real one.

Frequently asked questions

How long is a business analyst case study interview?

Most case rounds last 30 to 60 minutes. Some are live discussions on a whiteboard or shared document, while others are take-home tasks with a presentation afterwards. In live rounds, spend roughly the first five minutes on clarifying questions before you propose anything.

What frameworks should a business analyst use in a case study?

Keep it simple: clarifying questions, a one-line problem statement, hypotheses tested with data, current and future process maps, requirements with user stories and acceptance criteria, MoSCoW prioritisation, and success metrics with guardrails. Use frameworks as tools, not as a script to recite.

Do I need to know SQL or data tools for a BA case study?

You rarely need to write queries in the case itself, but you should say what data you would pull and how you would slice it. Many BA roles in India now expect basic SQL and Excel or Power BI, so mention how you would check each hypothesis.

What if I do not know the industry in the case?

Say so honestly and use clarifying questions to learn the context. Interviewers care about your structure, not your domain knowledge. Ask how the business makes money, who the users are and what changed recently, then apply the same steps you would use anywhere.

How should I end a case study answer?

Summarise the problem, your main recommendation, how you would measure success and the key risks, in about two minutes. Then ask the interviewer if they would like you to go deeper on any part. This shows confidence and keeps the discussion collaborative.