Requirements Gathering and Business Analysis Questions

Objective: Run a focused 2-hour workshop to align stakeholders on requirements for a revenue forecasting dashboard, produce prioritized user stories and acceptance criteria, and create a clear path to an actionable backlog.

Pre-work for participants (send 3–5 days ahead):

• Short brief: goals, KPIs we’ll discuss, current data sources, and constraints.
• One-slide: current pain points and one must-have metric.
• Bring examples of reports/dashboards you use (screenshots).
• Quick survey (3 questions): primary use case, frequency, and top 3 decisions the dashboard must support.

Attendees / personas:

• Finance (FP&A lead) — forecast methodology, KPIs, reconciliation needs
• Sales Ops — bookings, pipeline adjustments, quota attainment
• Product/Revenue Ops — pricing changes, product-level revenue attribution
• Data/ETL owner — data availability and latency
• BI Analyst (facilitator) — capturing requirements and feasibility

2-hour agenda:

• 0:00–0:10 — Welcome, objectives, outcomes, rules (timebox)
• 0:10–0:25 — Quick participant intros + top pain points (from pre-work)
• 0:25–0:45 — Use-case walkthrough: define user personas and key decisions (sticky notes)
• 0:45–1:10 — Metrics & data model deep-dive: agree on KPIs (ARR, MRR, bookings, churn), granularity, cadence
• 1:10–1:30 — Forecast methodology options: inputs, adjustments, confidence intervals
• 1:30–1:50 — Visualization & interaction needs: filters, drilldowns, export requirements
• 1:50–2:00 — Prioritization & next steps: vote (dot-vote) on features, assign owners

Key questions to surface:

• What decisions will this dashboard drive and by whom?
• Which forecasts must be reconciled to accounting?
• Required granularity (product, region, rep)?
• Frequency and latency tolerances
• Acceptable forecasting methods and override controls

Artifacts to produce:

• Persona-driven user stories (As a..., I need..., so that...)
• Acceptance criteria for each story (data source, calculation logic, performance)
• Data source matrix (field-level mapping, owner, freshness)
• Wireframe sketch or example visualization
• Prioritized feature list with effort/impact dots

Converting outputs into an actionable backlog:

• Immediately after workshop, synthesize notes into Epics and User Stories in the backlog tool within 48 hours.
• Attach acceptance criteria, data source mappings, and mockups to each story.
• Triage with Data/ETL owner to estimate data work; tag stories as “blocked/needs-data.”
• Run a quick grooming session with PM/tech lead to size and sprint-plan top 3 stories for an MVP (deliver within 2–4 sprints).
• Communicate roadmap and feedback cadence to stakeholders.

Situation: A sales manager requests a quota-attainment dashboard for reps.

Discovery process (using Jira/Azure DevOps)

1. Kickoff: Create an initial ticket/epic and schedule a 30–45 min discovery meeting to clarify scope, audience, cadence, and KPI definitions (quota, attainment %, period, territory, role).
2. Capture requirements in the ticket: attach mockups or ask stakeholder to mark up an example (Excel or screenshot). Ask about filters, drill-downs, refresh frequency, security (row-level security), and downstream consumers (executives, managers).
3. Data validation: Identify source systems (CRM, compensation system), required joins, and known data quality issues. Request sample data extracts if needed.
4. Acceptance & UX: Agree on visualizations (bar/line, table), export options, and success metrics (e.g., within 2% of source totals).
5. Follow-up: Convert discovery notes into detailed user stories and subtasks (data pipeline, model, visuals, QA).

Ticket fields to populate (Jira/Azure DevOps)

• Title: "Quota attainment dashboard — Sales Reps (Monthly/Quarterly)"
• Type: Story (or Feature/Epic if broader)
• Priority: (set after WSJF)
• Reporter / Assignee
• Description: One-paragraph summary + business why
• Acceptance Criteria (see below)
• Data sources: list with owners & sample links
• Mockups/attachments: annotated screenshots
• Dependencies: downstream data readiness, API limits
• Estimates: Story points or T-shirt size
• Labels/Tags: powerbi, quota, sales
• Security/RLS requirements
• Due date/SLA
• Test steps & QA owner

Estimation & prioritization

• Estimation: Team does a quick grooming session; break into subtasks (ETL, model, visuals, QA). Use story points via planning poker; if unfamiliar, use T-shirt sizing then convert.
• Prioritization: Use WSJF (Business value * Urgency / Effort) or simple priority matrix. Consider impact (number of users, revenue influence), confidence in requirements, and effort estimate.
• Buffer: Add a small contingency for data cleanup work.

Example acceptance criteria (clear, testable)

• Given production CRM and compensation feeds, the dashboard shows quota attainment % per rep for selected month and matches source totals within 2%.
• Users can filter by time period, region, and manager; selecting a rep shows a drill-through to transaction-level records.
• Data refreshes daily at 6:00 AM and reflects data loaded by 5:00 AM.
• Row-level security enforces that managers see only their team; executives see all.
• Exports to CSV preserve displayed filters and include timestamp.
• Performance: initial load under 4 seconds for default view.
• Tests: Unit tests for ETL, sample QA checklist attached.

Why this works

• Captures business context, data constraints, and UX up front to reduce rework
• Breaks work into measurable chunks for accurate estimation
• Acceptance criteria are specific and testable so dev/QA know when done
• Prioritization aligns team effort with business impact and urgency.

Situation: I was asked to deliver a cross-functional executive dashboard for a new subscription product involving Product, Finance, Marketing, and Sales — stakeholders had different metric definitions and tight timelines.

Task: My goal was to gather unambiguous reporting requirements, align stakeholders, and deliver a production-ready dashboard with minimal rework.

Action:

• I ran a 1-hour kickoff workshop to surface use cases, decisions the dashboard must support, and existing data sources.
• Created a concise requirements document that included: stakeholders & owners, use cases, frequency, data sources, and a prioritized metric list.
• Produced low-fidelity mockups (Power BI wireframes) showing layout, filters, and drill paths so stakeholders could visualize interactions.
• Drafted a data dictionary defining each metric (e.g., “active subscriber” = paid within last 30 days), calculation SQL pseudo-code, and trusted source tables.
• Wrote acceptance criteria for each card (visual) and overall QA checklist (row-level accuracy within 0 mismatches, load time <3s for executives).
• Used MoSCoW prioritization to align scope and set a two-week MVP and a follow-up roadmap.
• Held a sign-off meeting; captured decisions and versioned the requirements doc in Confluence.

Result: Because metric definitions and acceptance criteria were agreed up front, I avoided multiple rework cycles. The MVP shipped in 10 business days (target was 14), and the post-launch revision required only one small change instead of the three rework cycles we usually saw. Stakeholders reported trusting the dashboard immediately; Finance saved ~8 hours/week previously spent reconciling numbers.

This taught me that visual mockups plus a clear data dictionary and measurable acceptance criteria are the most effective artifacts for reducing ambiguity and accelerating delivery in cross-functional BI programs.