Working professionally — requirements, ownership, stakeholders and Agile delivery
The behaviours that make analysts trusted — understanding why a task exists, clarifying requirements, managing deadlines and expectations, challenging constructively — and how analytics work runs in Agile teams.
This lesson builds on: Analytical thinking — from business question to analytical task.
- Clarify the purpose and acceptance criteria of a request
- Question unnecessary work constructively and propose better alternatives
- Manage deadlines and expectations proactively
- Map stakeholders and communicate according to their needs
- Use Agile concepts (epics, sprints, tasks, story points, Definition of Done) for analytics work
Understand why the task exists
Before "how", ask "why": What decision does this support? What happens if we don't do it? What would make it obviously successful? Knowing the purpose lets you choose the smallest sufficient deliverable — and spot when the request solves the wrong problem.
Clarifying requirements
Turn a request into acceptance criteria — testable statements that define "done":
As the Head of Retail, I want a weekly store plan-vs-fact table, so that I can intervene in under-performing stores before month end. Acceptance criteria: completed-order net revenue by store and ISO week; plan pro-rated by days; stores below 95% highlighted; refreshed every Monday 08:00; totals reconcile to the Finance flash report within 0.5%.
Deadlines and expectation management
- Estimate honestly, including data access and validation time.
- Communicate early when risks appear ("Data from the new CRM arrives Thursday, so the analysis moves to Friday; I can send a preliminary view on Wednesday without online sales").
- Offer options: quick and approximate now, or precise next week.
- Never silently miss a deadline.
Questioning unnecessary tasks — constructively
Instead of "this is pointless", ask and propose:
"I want to make sure the 40-page monthly pack is worth the 3 days it takes. Which pages do you use in decisions? If only the store summary and the variance page, I could automate those and send them on day 2 instead of day 5."
Focus on the goal, bring evidence (usage data), offer a better alternative, and accept the decision if the stakeholder disagrees for good reasons.
Ownership and teamwork
Ownership means you deliver end to end — including validation, documentation and follow-up — and you raise problems you find even if they are not "yours". Teamwork means sharing code and knowledge, reviewing each other's work, and giving credit.
Stakeholder management
Map stakeholders by influence and interest: manage closely (high/high), keep satisfied (high influence), keep informed (high interest), monitor. Tailor content (Module 1): executives want the answer and the decision; Finance wants reconciliation; operational teams want detail and timeliness. Cross-department collaboration works best with shared definitions and a single source of truth.
Agile for analytics
| Concept | Meaning in analytics work |
|---|---|
| Epic | A large outcome, e.g. "Self-service sales reporting for store managers" |
| User story / task | A deliverable slice: "Store plan-vs-fact page with drillthrough" |
| Sprint | A fixed time-box (often 2 weeks) with a committed set of stories |
| Story points | Relative estimate of effort/complexity/uncertainty (often Fibonacci 1, 2, 3, 5, 8, 13) — not hours |
| Estimation | Team discussion (e.g. planning poker) comparing to reference stories |
| Backlog | Prioritised list of work |
| Statuses | To do → In Progress → In Review → Done |
| Definition of Done | Shared checklist: query reviewed, numbers reconciled, documentation updated, stakeholder accepted |
| Review & acceptance | Demo to stakeholders; product owner accepts against acceptance criteria |
| Retrospective | Team improves its process |
Analytics adds uncertainty (you may not know what the data shows), so time-box exploratory work as spikes and keep stories small enough to finish within a sprint.
(The founder brief lists "Second Line" as an Agile status. This is not a standard Agile term — it may refer to second-line support escalation between operations and analysts. It is awaiting definition.)
Practice
Which is a good acceptance criterion for a weekly plan-vs-fact report?
What do story points estimate?
A manager asks for a 40-page monthly pack that takes 3 days. Usage logs show 2 pages are opened. Best response?
Summary
- Start from the purpose; write acceptance criteria; offer options and communicate risks early.
- Challenge unnecessary work with evidence and a better alternative.
- Map and serve stakeholders differently; share definitions across departments.
- Agile: epics → stories → sprints; story points are relative; Definition of Done includes validation and acceptance.