Scenario-Based Business Analytics Interview Questions

Check data accuracy, then segment by city, restaurant, time and user type; look at supply, delivery time, pricing, competitors and seasonality before proposing fixes.

Log the change, assess impact on scope, cost and timeline, get approval through change control or backlog grooming, and update documents and stakeholders.

Define churn, analyse who leaves and why, segment customers, find drivers through data and surveys, design retention offers and measure uplift with a control group.

Score them with RICE or value-vs-effort, align with goals, consider dependencies and risks, validate with stakeholders, then use MoSCoW for the release plan.

Look at the cost side: heavier discounts, higher CAC, logistics costs, product mix shifting to low-margin items, one-time expenses or pricing changes. Break contribution margin down by segment.

Break sales into footfall, conversion and average basket, compare with last year and competitors, and check stock, pricing, staffing and local events.

Clarify the underlying goals, present data and trade-offs, facilitate a joint session, escalate to the sponsor if needed and document the agreed decision.

Clarify the goal behind each request, map them to business objectives, prioritise with MoSCoW, run a joint session, then document the decision and get sign-off.

Check market size (population, online ordering share), competition, restaurant supply, unit economics per order, CAC and payback period. Propose a pilot with clear success metrics.

Assess market size and demand, customer need, competition, unit economics, capabilities, risks and strategic fit, then test with a pilot before scale-up.

Map the funnel, find the biggest drop-off, check usability and load time, run A/B tests on fixes and track conversion lift.

Split into revenue and cost, then revenue into price, volume and mix, and cost into fixed and variable; check internal factors and external market factors.

Start with Performance Analyzer to see which visuals and DAX queries are slow. Then fix the model: remove unused columns, reduce high-cardinality text, use a star schema and correct data types. Rewrite heavy measures, avoiding FILTER over whole tables and nested iterators. Cut the number of visuals per page, use aggregations or Import instead of DirectQuery where possible, and push transformations upstream into SQL or Power Query.

First agree on the definition: date range, gross or net, tax, returns, currency and which date (order or invoice) is used. Then reconcile at a small grain, such as one month and one region, comparing row counts and sums between the source query and the sheet. Common causes are filters on the page, missing relationships, duplicate rows after a join or a late refresh. Document the agreed definition in the report tooltip.

The filter from the row field is not reaching the fact table. Usually there is no relationship between that dimension and the fact, the relationship is inactive, or it filters in the wrong direction. It can also happen when the measure uses ALL or REMOVEFILTERS on that column, or when the row field comes from the fact table of a different grain. Check the model view and test the measure with a simple SUM.

Ask what decisions they make weekly and which three to five KPIs drive them. Propose a summary page with those KPIs, trends and one breakdown, then drill-through or separate pages for detail. Show a quick mock-up of both versions so they see the clutter and the load time. Use bookmarks or a field parameter to let them switch views without adding charts. Agree on the layout before building.

Check the refresh history error first: expired credentials, gateway offline, source schema change or timeout. Fix the quick cause and trigger a manual refresh. If it cannot be fixed in time, inform the stakeholders early, state the last refreshed date clearly on the report and share the key numbers from a direct query if needed. Afterwards add refresh failure alerts and a data-as-of label so it never surprises anyone.

Create a shared, certified semantic model with one definition per KPI, built on a governed warehouse layer. Departments build thin reports on top of it through live connection instead of copying data. Set up workspaces by environment (dev, test, prod), deployment pipelines, naming standards, a KPI glossary and owners for each measure. Keep a small central team for the core model and let departments self-serve on top, which balances control and speed.

Use an extract with only the needed columns and rows, aggregated to the visible grain where possible. Replace quick filters showing all values with fewer filters, use context filters wisely and avoid 'only relevant values' on large fields. Move complex calculations into the data source, reduce marks per view and the number of sheets per dashboard. Use the Performance Recorder to find the slowest queries and fix those first.

Standardise both first: trim spaces, fix case, convert IDs to the same type and remove duplicates. Use a unique key like customer ID, or a combined key of phone and email if IDs differ. Then use XLOOKUP or COUNTIFS to mark each record as matched, only in sales or only in billing, or a Power Query merge with anti joins. Summarise mismatches by type and share the exception list with both owners.

Map the steps first: which files arrive, what cleaning is done and which outputs are needed. Move the import and cleaning into Power Query so a refresh replaces copy-paste. Base calculations on Excel Tables and PivotTables that update automatically, and keep a fixed template for the output. Use a small macro or Office Script only for the remaining formatting or emailing. Add checks such as row counts and totals so errors surface quickly.

Usually the values only look the same. Common causes are trailing or leading spaces, numbers stored as text in one sheet and as numbers in the other, non-breaking spaces from web exports, or different spellings. Check with =LEN() and =ISNUMBER(), clean with TRIM, CLEAN or VALUE, and confirm the lookup range covers all rows and uses exact match. Wrap the final formula in IFNA to label true misses.

Add a helper column for each customer's first order month using MINIFS on customer ID, and another for the order month. Compute the month index as the difference in months between them. Then build a PivotTable or COUNTIFS grid with cohort month as rows, month index as columns and distinct customers as values. Divide each cell by the month-zero count to get retention percentages and add a colour scale to show decay.

The join created a fan-out: some orders have more than one payment row, such as split payments or retries, so each order amount is repeated. Check the grain by counting rows per order_id on both sides. Fix it by aggregating payments to one row per order in a CTE before joining, joining on the full key, or summing from the table whose grain matches the metric. Always compare row counts before and after a join.

Read the execution plan to find full scans and expensive joins. Filter early on partitioned or indexed columns such as date, select only needed columns instead of SELECT *, and avoid functions on filter columns. Pre-aggregate in a CTE before joining, replace correlated subqueries with joins or window functions, and check join keys have matching types. For repeated use, build a summary table or materialised view refreshed daily.

Put both queries side by side and compare definitions: which events count as active, time zone, calendar versus rolling month, test and internal accounts, deleted users, and DISTINCT on user ID versus device ID. Run both on a single day to find where they diverge. Agree on one definition with the metric owner, document it, and publish it as a shared view or metric so everyone queries the same logic.

A condition on the right table was probably placed in the WHERE clause, for example WHERE o.order_date >= '2026-01-01'. For customers with no orders, o.order_date is NULL, so WHERE removes them and the query behaves like an INNER JOIN. Move the condition into the ON clause, as in LEFT JOIN orders o ON o.customer_id = c.id AND o.order_date >= '2026-01-01', or explicitly allow NULLs.

Growth came from more value per customer, not more customers. Break revenue into customers times orders per customer times average order value to see which moved. It could be price increases, larger baskets, a shift to premium products or a few large accounts. Then check risks: is new customer acquisition stalling, is churn being masked, and is growth concentrated in a small segment that could leave?

Confirm the data first: definition changes, failed-payment handling or a billing date shift. Then segment churn by plan, tenure, acquisition channel, city and device to find where it concentrates. Separate voluntary cancellations from involuntary card failures. Look at events before the jump, like a price change, app release or competitor offer, and read cancellation reasons. Recommend targeted fixes, such as payment retries or win-back offers, and track the affected cohort.

A single KPI can be gamed, so I would propose one headline with guardrails. The headline could be first-contact resolution rate, because it reflects solving problems, not just closing tickets. Guardrails would be customer satisfaction score after the ticket and median first response time. I would also watch ticket volume per thousand orders, which shows whether product issues are falling. Review targets quarterly with the support head.

Bring both teams together and list each definition, its purpose and its numbers. Agree on one company-wide definition tied to real value, such as a user who completed a core action in the last 7 days, and allow clearly named secondary metrics like 'visitors' for marketing. Assign an owner, document it in a metric glossary, implement it once in the warehouse or semantic model, and retire the duplicate dashboards.

The incentive rewards revenue regardless of profitability, so reps are likely discounting heavily or pushing low-margin products. Analyse deal-level discount, product mix and margin by rep and region to confirm. Then recommend changing the target to gross margin or contribution, or adding discount approval limits and a margin floor to commission. Pilot the new plan with one region and track revenue, margin and win rate together.

Assume a data problem until proven otherwise, because real businesses rarely move 40 percent in a day. Check whether the refresh completed, whether source row counts look normal, and whether any tracking, pipeline or definition changed. Compare with a raw source query and a related metric, such as orders versus payments. If the data is fine, segment by channel, region and platform to locate the drop, then alert the owners quickly.

Cover the full funnel and risk. Acquisition: applications, approval rate, cost per disbursed loan and time to disbursal. Value: disbursed amount, average ticket size and net interest margin. Risk: delinquency rates at 30 and 90 days past due by cohort, and early default rate. Customer: drop-off by application step, complaint rate and repeat borrowing. Track risk by monthly disbursal cohort, because defaults show up months later.

Understand the real need first: what decision is it for and what is the minimum that helps tomorrow? Offer a phased answer, such as a quick directional view with the top three numbers tomorrow, clearly labelled with caveats, and the full validated report in a week. Explain the trade-off between speed and accuracy. Confirm the agreed plan in writing so expectations are clear.

Double-check the data and method first, and ask a peer to review it. Then share it privately with the VP before any group meeting, so they are not surprised in public. Present it neutrally: what we expected, what the data shows, and possible reasons. Invite their context, as they may know factors you missed. Suggest a small test to settle it. Focus on the decision, not on being right.

Talk to them one-to-one to understand why they skip, such as timing, relevance or workload. Offer shorter reviews, asynchronous reviews with a clear deadline, or a delegate with decision rights. Record sign-offs at each stage in writing so late changes become formal change requests. Share early drafts and mock-ups, because people react better to something visible. Escalate to the sponsor if the pattern risks the timeline.

Get to the underlying business goal behind the requirement, because the goal is often achievable in another way. Ask developers to explain the constraint and the cost of alternatives. Bring both sides together with options: a simpler version, a phased delivery, a manual workaround or a different design. Show effort, risk and value for each, and let the product owner or sponsor decide. Document the decision.

Skip the formulas and talk about what drives the forecast, such as seasonality, past trend and pipeline, in plain words. Show one chart of actuals versus forecast with a range rather than a single number, and explain that the range reflects uncertainty. Translate it into their terms: what it means for their targets and stock. Invite questions and share an example of where it would be wrong.

Tell the sponsor and key stakeholders as soon as you are confident, not on the deadline. Be direct about the delay, the cause and the impact. Come with options, such as reducing scope to hit the date, adding resources, or moving the date with a phased release, plus your recommendation. Agree on the new plan, update the communication plan and track the recovery visibly.

Stay neutral and move the discussion from blame to facts. Trace the number end to end: source system, extraction, transformation and report logic, and find exactly where the values diverge. Share the findings with both teams together, agree on the fix and on a single owner for the definition. Then add automated reconciliation checks and a data dictionary, so the process, not people, prevents the next issue.

Understand the urgency and the business impact of waiting until the next sprint. Bring it to the product owner, who decides. If it truly cannot wait, the team agrees to swap out work of similar size so the sprint goal stays realistic, and the trade-off is made visible to the stakeholder. If it can wait, add it to the top of the backlog for the next sprint. Avoid silently adding scope.

Ask which screens or actions feel slow, for which users, on which devices and networks, and how it affects the business, such as checkout drop-off. Gather current timings from monitoring data. Then write measurable non-functional requirements, for example 'the search results page loads within 2 seconds for 95 percent of requests on a 4G connection'. Confirm targets with the stakeholder and agree how they will be tested.

The story is ambiguous, so bring the three amigos together: BA or product owner, a developer and a tester. Walk through concrete examples, including edge cases and error cases, and write them as acceptance criteria, ideally in Given-When-Then format. Add business rules, sample data and mock-ups where needed. Update the story and use the same practice in refinement for future stories, so gaps are found before coding starts.

Combine several sources. Interview and observe users doing real tasks, and review screens, reports and outputs to infer business rules. Analyse the database and logs to see which data and functions are actually used. Work with long-serving staff and IT support for hidden rules and workarounds. Build AS-IS process maps, decide what to keep, drop or improve, and validate the findings with users. Plan data migration requirements early.

The team built what was written, but not what users needed, which points to gaps in elicitation, missing real-world scenarios or users not involved early. Capture each rejection and classify it as a defect, a missed requirement or a new request. Prioritise blockers with the product owner and agree on a fix plan and date. Going forward, involve users in demos every sprint and base UAT scenarios on real workflows.

Rule out data issues first: tracking changes, app release bugs, pipeline delays or bot filters. Check whether the drop is seasonal by comparing with the same week last year or a festival calendar. Then segment by platform, app version, country or city, acquisition channel and new versus returning users to locate it. Look at the funnel for the core action. Connect findings to releases, outages or marketing changes, then recommend fixes.

Not automatically. Find out why: the variant may push cheaper products, bigger discounts or smaller orders, so more people buy but each spends less. Check average order value, margin and long-term metrics like repeat purchase. Decide based on the metric tied to the business goal, usually revenue or contribution per user, which should have been the primary metric or a guardrail. Consider iterating to keep the conversion gain without lowering order value.

Check whether the extra sign-ups are lower-intent users who would naturally retain less. Compare Day-7 retention for comparable users in both versions and count retained users in absolute terms, not just rates. If the new flow skips a step that led users to the aha moment, retention per user may truly fall. The decision depends on whether total retained, valuable users went up or down.

Advise against it. Checking results repeatedly and stopping at the first significant result inflates false positives, often far beyond the planned 5 percent. Three days also misses weekly patterns and novelty effects. Run the test for the pre-calculated sample size and duration. If speed is critical, the team can use a sequential testing method designed for early looks, but that must be planned before the test starts.

Find out whether it is a discovery problem or a value problem. Check how many users saw the entry point, how many tried it and how many returned. If few saw it, test better placement or onboarding prompts. If many tried and few returned, interview users and review session recordings to understand why. Also check if the 4 percent are high-value users. Then decide to improve, reposition or remove it.

It depends on the product's goal. For a content or learning app, more time may mean more engagement. For a payments or banking app, more time can mean users struggle to complete tasks. Check task completion rate, time to complete key actions, errors, support tickets and retention. A metric is good only when it moves in line with the value users came for.

Use quasi-experimental methods. Compare before and after with enough history to account for trend and seasonality. If it rolled out at different times in regions or platforms, use difference-in-differences between early and late groups. Compare users who adopted with similar non-adopters using matching, while being careful about self-selection. For future launches, recommend keeping a small holdout group so impact can be measured cleanly.

Quantify both effects: extra sessions and revenue from notifications versus users lost through uninstalls and notification opt-outs, including their lifetime value. Segment by notification type and frequency to find which ones annoy users. Recommend frequency caps, personalised timing, relevance rules and easy preference settings, then test them with uninstall rate and opt-out rate as guardrails. Short-term engagement should not cost long-term users.

This is Simpson's paradox caused by a change in mix. If mobile converts lower than desktop and the share of mobile traffic grew sharply, the overall average can fall even though each segment improved. Show conversion by segment along with the traffic mix. The insight is not that conversion got worse but that traffic shifted, so the question becomes how to raise mobile conversion further.

Clarify where the wait is measured: registration, consultation, diagnostics or billing. Split the problem into demand and capacity. On demand, check patient volume, peak-hour mix, walk-ins versus appointments and new departments. On capacity, check doctor availability, no-shows of staff, consultation time per patient and process bottlenecks such as manual billing. Identify the biggest stage and suggest fixes like slot-based appointments, triage and digital billing.

Evaluate attractiveness and ability. Attractiveness: private labels usually earn higher margins, so check category size, how price-sensitive customers are, and whether brand loyalty is weak in categories like staples and cleaning. Ability: supplier availability, quality control, shelf space and brand trust. Estimate the margin gain against cannibalisation of branded sales and supplier relationships. Recommend starting with a few high-volume, low-loyalty categories and measuring repeat purchase.

Define completion and see where learners drop: first week, a specific module or before assessments. Segment by course, length, learner background, device and acquisition channel. Look at causes in content difficulty, video length, lack of deadlines, mentor support and job relevance. Recommend tests such as shorter modules, cohort-based deadlines, progress nudges and live doubt sessions, and measure completion and referral impact.

Users are coming but not completing transactions, so look at the gap. Possible causes: a release that broke a payment flow, new security steps like extra OTPs adding friction, logins driven by balance checks or offers, or transactions shifting to another channel. Compare the funnel from login to transaction by app version and device, check failure and error rates, and review support complaints before recommending fixes.

First split by who cancels: riders or drivers. For rider cancellations, check wait times, pickup accuracy, price surges and changes in ETA. For driver cancellations, check trip distance, payment mode, low fares, destination visibility and incentive changes. Then segment by city, time of day and area. Link to recent changes like a new pricing rule. Recommend fixes for the largest driver, such as better matching or adjusted incentives.

Compare options on fit, cost, time and risk. Buying a proven product is faster with lower risk and includes upgrades, but may need process changes and has recurring licence fees. Building fits unique processes exactly but needs a strong tech team, longer time and ongoing maintenance. Estimate five-year total cost of ownership, check whether processes are truly unique, and usually recommend buying and configuring unless warehousing is a core differentiator.

First measure each handoff: waiting time, rework rate and volume, using system timestamps where possible. Then classify steps as value-adding, required for compliance or waste. Look for patterns: repeated approvals, information re-entered in two systems, work bouncing back for missing documents. Typical fixes are merging roles, adding a checklist at intake so applications arrive complete, parallelising checks and automating rule-based approvals. Quantify the expected reduction in cycle time for each option.

Treat each version as a hypothesis. Walk the process physically or observe real cases end to end, and pull a sample of 20 to 30 recent orders from the system to trace what actually happened. Compare timestamps and status changes with each department's story. Then hold a joint session, show the evidence-based map and mark the variants openly. Often all three are partly right because different order types follow different paths, which should be modelled explicitly.

Restructure it into levels. Create a high-level map with 7 to 10 main steps, then collapse detailed parts into sub-processes with their own diagrams. Move complex decision logic into a decision table rather than chains of gateways. Show the happy path first and handle exceptions in separate views. Use consistent naming in verb-noun form and remove duplicated steps. Finally, test readability by asking a stakeholder to explain the diagram back to you.

Check that the process is stable, rule-based and high volume, with structured digital inputs. Look at the variant rate: if half the cases are exceptions handled by judgement, a bot will fail often. Verify that the underlying systems and screens will not change soon. Fix the process first, because automating a broken flow only makes errors faster. Finally estimate hours saved against bot build and maintenance cost, and define how exceptions get routed to people.

Ask compliance which specific controls they believe are weakened, and map each regulatory requirement to steps in the old and new flows. Often the control can be kept in a different form, such as automated checks, risk-based sampling or a post-approval audit instead of a manual pre-check. Bring compliance into the redesign rather than presenting a finished model. Document the agreed controls in the TO-BE diagram so audit can trace them. Speed never overrides a mandatory control.

Compare against the baseline you measured before the change, using the same definitions: cycle time, first-time-right rate, cost per case, backlog and customer complaints. Pull data from system timestamps rather than surveys. Check that the gain is not explained by lower volumes or seasonality, ideally by comparing similar periods. Also check for side effects, such as faster processing but more rework downstream. Present the before-and-after with the business owner, and note where adoption is still incomplete.

Use Data Validation with a List rule. Keep the allowed regions in a separate sheet as an Excel Table, name it, and set the validation source to that range so the dropdown grows when you add a region. Turn on an error alert so free text is rejected. Then clean existing entries once with Find and Replace or a mapping lookup. For stronger control, protect the sheet and unlock only the input cells, so the list cannot be edited by mistake.

The PivotTable source is probably a fixed range such as A1:F500, so rows added below 500 are outside it. The fix is to convert the data to an Excel Table with Ctrl+T and change the pivot's data source to the table name, so it expands automatically. Also check for blank header cells, filters on the pivot hiding new items, and whether the new rows are actually text values in a numeric column, which can change grouping.

Use drill-through. Create a detail page, add the Region field to the page's drill-through filter well, and design visuals for orders, products and trends. Power BI adds a back button automatically. On the summary page, users right-click a region and choose Drill through. Keep all filters on so date selections carry over. For guided navigation, you can also add buttons with bookmarks, but drill-through is the cleanest way to pass the selected region.

This is a sample ratio mismatch. With 200,000 users, a 52/48 split is far outside random chance, which a chi-square test will confirm. It means the assignment or logging is broken, for example the variant page crashing before the tracking event fires, bots filtered unevenly or a redirect losing users. Do not trust the results. Investigate by segment, platform and day to find the cause, fix it and rerun the test.

Compare total cost of ownership over the same period, usually 3 to 5 years. Include licence or subscription fees, implementation, data migration, integration, training, internal staff time, infrastructure, support and upgrade costs, and exit costs. Discount the yearly totals to present value if the timing differs. Then weigh the result against non-cost factors such as fit to requirements, scalability and vendor stability. Often the cheaper licence ends up costlier once customisation and support are added.

Profit is an accrual figure, while cash depends on timing. Check working capital first: receivables may be growing because customers pay late, inventory may be piling up, or suppliers may be demanding faster payment. Then look at large capex, loan repayments, and dividends. Review the cash flow statement and compute days sales outstanding and inventory days over time. Fixes include tighter credit terms, collection drives, inventory reduction and renegotiating supplier terms.

Separate contribution from allocation. If the product's revenue exceeds its variable and directly attributable fixed costs, it contributes to covering shared overheads, which will not disappear if it is closed and will be reallocated to other products. Check whether the overhead allocation key, such as revenue share, is fair. Also consider strategic links, like customers who buy it alongside profitable products. Recommend shutting it only if contribution is negative or the freed capacity has a better use.

Build a discounted cash flow comparison over the vehicle life. For buying: purchase price, financing cost, maintenance, insurance, tax benefit of depreciation, and resale value. For leasing: lease rentals, what maintenance is included, tax treatment and end-of-term conditions. Discount both at the company's cost of borrowing and compare present value of costs. Then add qualitative factors: flexibility if volumes drop, technology risk such as a shift to electric vans, and impact on the balance sheet.

Break the change into drivers. Price: were discounts or promotions deeper? Mix: did sales shift towards lower-margin products, channels or regions? Cost: did raw material, freight or supplier prices rise, or did currency movements raise import costs? Also check one-offs like inventory write-offs and accounting reclassifications. Build a margin bridge showing how many percentage points each driver contributed, then take the biggest driver to the business owner with a specific action.

Run a benefits review against the original baseline and assumptions. Check whether savings depended on actions that did not happen, such as reducing manual roles, retiring the old system or full user adoption. Check whether the baseline or volumes changed. Separate delayed benefits from lost ones. Then produce a recovery plan with owners, for example decommissioning the legacy licence or driving adoption. Also feed the lessons into how future business cases estimate benefits.

Possible causes include falling sales against unchanged purchasing, poor demand forecasts, bulk buying for discounts, slow-moving or obsolete SKUs, or deliberate stock-building ahead of a festive season or expected price rise. Analyse by SKU, warehouse and age bucket to find where stock is stuck. Recommend clearing aged items, adjusting reorder points using recent demand, and reviewing supplier minimum order quantities. Also quantify the cash locked up and the carrying cost to show urgency.

Demand: population density, smartphone and digital payment penetration, average basket size and how often people buy groceries. Supply: dark store rent, rider availability and local sourcing. Unit economics: orders per store per day needed to break even, given lower average order values. Competition: local kirana delivery and other apps. Then propose a pilot in two or three cities with clear success metrics such as orders per day, contribution margin per order and repeat rate before scaling.

It is a regression: the fix for one defect broke existing functionality, which usually means changes were not impact-analysed and there is no regression suite. Log it as a new high-priority defect linked to the fix. Agree with the team that every UAT build comes with release notes listing the changes, and that QA runs an automated or core manual regression pack before handing the build to business testers. Also add the broken flow to the UAT regression checklist.

Escalate immediately to the business sponsor with the impact: each day without testers delays sign-off and go-live. Ask for named testers with protected time, even part-time. Meanwhile, prepare so no time is lost: finalise test cases, check the environment and data, and plan a short tester briefing. If testers cannot be released, propose re-planning UAT dates rather than letting IT or the BA test on the business's behalf, because acceptance must come from the users.

Run a joint triage with the business owner, QA and development. Compare each item against the signed-off requirements and acceptance criteria. Real defects stay in the defect log; items not covered by requirements are reclassified as change requests and prioritised separately through change control. Keep the tone neutral so users do not feel dismissed. Also review why the gap happened, for example prototypes were not shown early enough, and fix that for the next release.

Confirm the impact and reproduce it quickly. Work with development to estimate a fix and its regression effort. Then present options to the business owner with risks: fix and do targeted retesting before go-live, go live with a temporary workaround or manual process, go live with the affected feature switched off, or delay. The decision belongs to the business, documented at the go or no-go meeting. Never hide a critical defect to protect a date.

Explain the risks in business terms: without UAT, there is no evidence that real processes work, and production defects cost far more to fix and can affect customers and compliance. Offer alternatives: a shortened UAT covering only critical business flows, parallel running with the old system, a phased rollout to one branch or user group, or extended hypercare. If the sponsor still decides to skip it, record the decision and accepted risks formally.

Go back to the requirement and acceptance criteria. If the system matches the agreed requirement, the developer is right, and the business need is a change request. If the requirement is unclear or the design misread it, it is a defect, and the requirement wording should be fixed. Discuss it in triage with both parties, using examples. Either way, close the loop with the tester so they understand the outcome and keep trusting the process.

Identify which documents are actually used: usually a product overview, process maps, business rules, data dictionary and integration details. Update those first rather than everything. Make documentation part of the Definition of Done, so a story is not complete until related docs are updated. Keep living documents in a shared wiki with owners and last-reviewed dates, and archive outdated files clearly. Test the result by having a new joiner use it during onboarding.

The subquery probably returns at least one NULL, for example SELECT customer_id FROM orders where some orders have a NULL customer_id. With NOT IN, comparing any value to NULL gives UNKNOWN, so no row passes the condition. Fix it by using NOT EXISTS with a correlated subquery, or a LEFT JOIN with WHERE o.customer_id IS NULL, or by adding WHERE customer_id IS NOT NULL inside the subquery. NOT EXISTS is the safest habit.

Usually rounding. Excel may display rounded values while summing the full-precision numbers, or line items were rounded individually in the source system and the total was computed differently. Check whether finance rounds each invoice line before summing, and apply ROUND at the same level in Excel. Other causes include floating-point artifacts, values stored as text being skipped by SUM, or hidden filtered rows. Agree and document one rounding rule with finance.