Business Analyst · Playbook
Business Analyst Playbook
A practical guide to making clarity speed up delivery. Standards describe what good looks like for public services. Methods describe how you discover, model and specify. Keep those ideas separate so you do not bury the team in artefacts, or ship ambiguity dressed as agility.
MAP-01 Analysis maps
Analysis maps & methods
Pick the artefact that answers the question in front of you.
Analysis work mixes discovery methods, specification techniques and public-service standards. Forcing every need into a user story creates either fog or gold-plating. Every framework below answers a different question. Use the lightest one that unlocks the next honest decision.
Maps you will actually use
| Map | Answers | Shape |
|---|---|---|
| Double Diamond / Design Thinking | Is the problem clear enough to specify? | Diverge then converge: Discover, Define, Develop, Deliver |
| BDD / Given-When-Then | What behaviour must we prove? | Examples that bind PO, BA, developer and tester |
| BPMN / process maps | Where do hand-offs and rules break? | As-is and to-be with owners at each seam |
| Decision tables / data dictionaries | What rules and data make the system honest? | Conditions, actions, entities, constraints |
| GDS Service Standard & WCAG | Is this fit for a public service? | 14 points · accessibility floor AA |
| Green Book options logic | Which option is defensible with public money? | Strategic to Economic to Management cases |
Choose in practice
- Problem unclear: frame and discover before writing stories.
- Behaviour ambiguous: write BDD examples with the tester and PO in the room.
- Cross-team hand-offs: model the process seam before you invent tickets.
- Funding or options fight: use Green Book grammar, not feature preference.
- Public interface: put WCAG and Service Standard evidence into Ready and Done.
In DDaT terms, business analysis roles run from Associate through Lead and Principal. Titles vary by department. The accountability does not: someone must make needs testable and options comparable. If that person is "whoever last spoke to the stakeholder", you do not have analysis.
Accountability ladder (typical digital BA path)
- Associate / Junior BA: learning framing and AC craft on a contained slice with coaching.
- Business Analyst: accountable for requirements clarity on a product or service area.
- Senior / Lead BA: complex or multi-team analysis, coaches other BAs, holds modelling standards.
- Principal / Head of BA: owns the analysis profession, quality bar and hiring standard.
What you stop and start doing as you grow
You stop doing
- Writing every story yourself as the only path to clarity
- Taking every stakeholder ask at face value
- Measuring your week by tickets refined
You start doing
- Coaching POs and testers so Ready items arrive without you bottlenecking
- Publishing problem statements and inviting challenge on assumptions
- Measuring your week by decisions unlocked and ambiguity removed
Three questions to run every day
If any answer is "no" for more than a week, that becomes the priority over the loudest new request.
Separate symptoms from causes. Capture current-state pain with evidence. Write a problem statement the SRO would recognise and the team could repeat. Solutioneering thrives where the problem is vague.
Weak versus strong framing
| Signal | Weak version | Strong version |
|---|---|---|
| Ask | We need a new portal | Citizens abandon renewals at step 3; 40% drop-off last quarter |
| Success | Ship the portal | Completion rate above X% with WCAG AA |
| Scope | Everything the business wants | Named non-goals and a Will-not list |
| Assumptions | Verbal, forgotten | In RAID with owner and invalidate-by date |
Who is affected: …
What happens today: …
Impact (user, operational, financial, risk): …
Evidence: …
Non-goals: …
Success signal agreed with PO: …
Framing hygiene
- Non-goals are explicit before story mapping starts.
- Assumptions sit in RAID, not in chat history.
- Success measures are agreed with the PO, not invented in isolation.
- Challenge "we need X system" until you hear the job the user is hiring for.
Prefer behaviour-focused criteria. Use BDD Given/When/Then where shared examples clarify intent. Keep non-functionals (performance, WCAG, security, audit) visible in the same conversation as the happy path.
Ready checks for requirements
| Ready check | Why it matters |
|---|---|
| User and problem clear | Stops solutioning for the wrong person |
| Acceptance criteria testable | Aligns PO, BA, QA and developers |
| Happy path and key edges covered | UAT should not invent the real rules |
| Data rules and errors stated | Prevents "works on my data" surprises |
| Dependencies named | Feeds RAID and Sprint planning honesty |
| Non-functionals noted | Accessibility and performance do not arrive in panic week |
| Trace link to outcome or epic | Lets you cut without losing the why |
Feature: …
Scenario: …
Given [context] And [further context]
When [action]
Then [observable outcome] And [further outcome]
Anti-patterns
- Acceptance criteria written after coding starts.
- "As a user I want a button" with no so-that value.
- Ambiguous words: fast, intuitive, flexible, as appropriate, etc.
- Gold-plating: every edge case treated as Must before the thin slice ships.
Process models, decision tables and data dictionaries make hand-offs and rules inspectable. A story that ignores the seam will fail in UAT even if the button works.
When to model what
| Artefact | Use when | Fail mode |
|---|---|---|
| As-is / to-be process | Multiple roles or systems hand work off | Pretty diagram with no owners |
| Decision table | Rules combine into combinatorial edges | Verbal rules only in the SME's head |
| Data dictionary | Fields, codes and retention matter | Developers invent meanings mid-Sprint |
| Story map | You need release slices from a journey | Giant map never cut into Increments |
Model enough to decide
- Name the actor, trigger, outcome and exception path
- Mark system boundaries and who owns each step
- Link each critical rule to a testable AC
Stop when
- The next workshop would not change a story
- You are documenting fantasy future state with no PO buy-in
- The model is denser than the problem
- Publish as-is pain with evidence before selling to-be elegance.
- Put unresolved rules in RAID with an invalidate-by date.
- Invite the tester to challenge combinatorial explosion early.
Map power and interest. Manage Closely those who can stop clarity (policy owners, SMEs, security, finance). Keep Informed those who feel the change. Bring options and a recommendation to the PO; do not escalate a blank problem.
Workshop types that earn their keep
| Workshop | Output | Fail mode |
|---|---|---|
| Discovery synthesis | Insights + opportunities | Notes with no decisions |
| Story mapping | Release slices | Giant map never cut |
| MoSCoW | Scoped Musts with capacity visible | Everything Must |
| Rules harvest | Decision table | Verbal rules only |
| AC / BDD three amigos | Shared examples | BA monologue after the meeting |
- Agenda states the decision needed before people join.
- Owners named for open questions before leaving the room.
- Circulate decisions the same day; shared memory is not a system of record.
- Partner with the PO so priority stays theirs even when you facilitate.
Decision: …
Why: …
Options considered: …
Owner / date: …
Impact on scope / AC: …
Run thin discovery beside delivery. Timebox spikes. Put evidence next to every material requirement. Your job is to translate research and options into Ready work the PO can prioritise, not to own the value call.
Three-way operating rules
| Partner | They own | You contribute |
|---|---|---|
| Product Owner | Priority and outcome bets | Options, impact, Ready clarity |
| UX Designer | Research quality and experience | Journey constraints, rules, edge cases |
| Tester | Proof strategy | Testable AC and combinatorial honesty |
- Attach interview, analytics or support evidence to risky assumptions before a full Sprint of build.
- Prototype or spike when uncertainty is high. Prefer falsification over polish.
- Kill or reshape stories when evidence contradicts the bet. Celebrate the kill with the PO.
- In government, map discovery evidence to Service Standard points on user needs and iteration.
If discovery never ends, name the decision owner for "enough evidence". If discovery never starts, protect a thin dual-track slice in the next Sprint with the Delivery Manager.
Traceability is not a bureaucracy hobby. It is how you show coverage, assess impact of change, and survive assurance without rewriting history the night before.
Minimum useful chain
Outcome / benefit to epic / theme to story to acceptance criteria / BDD to test evidence. Add Service Standard or policy references where they drive the requirement.
| Change type | Your first move | Who decides |
|---|---|---|
| Clarify AC (same intent) | Update story, notify tester and developer | BA with PO awareness |
| Expand scope inside Sprint | Impact note: capacity, risk, deferrals | PO (Sprint Goal intact or not) |
| Baseline / funded scope shift | Change request with baselines affected | SRO / PM change control |
| Assumption invalidated | RAID update + re-frame or re-prioritise | PO with BA evidence |
- Every material story has a parent outcome or epic ID.
- Scope changes are logged with impact, not absorbed silently.
- Orphan requirements without outcomes get challenged or cut.
- Keep the trail light enough that people update it; heavy matrices go stale.
In UK public services, analysis includes accessibility, trust, operational cost and policy outcomes. Shipping tickets is not the same as meeting the Service Standard or defending an options appraisal.
- Align requirement themes to Service Standard user-needs evidence.
- Treat WCAG 2.2 AA as a floor in acceptance criteria for public interfaces.
- Connect options and benefits to Green Book logic when funding is live.
- Prefer GOV.UK Design System patterns over inventing one-off UI that fails assessment.
- Work with the SRO and PO on what "good enough to ship" means for this tranche.
Assessment readiness as continuous work
- Accessibility and performance acceptance criteria are explicit, not implied.
- Research repositories, decision logs and rules artefacts are findable before the assessor asks.
- Private Beta and Public Beta exit criteria are written early, not invented week-of.
- Options appraisals state assumptions and optimism risk, not only preferred features.
The information does not change between a three amigos session and a board options brief. The altitude, the framing and the ask do.
Audience calibration
| Audience | Detail level | What they want |
|---|---|---|
| Team | High, AC and edge cases | Clear intent without mid-Sprint fog |
| PO / UX / tester | Medium, options and evidence | Shared examples and early warning |
| SRO / board | Low, outcome and decision | Options plus a recommendation |
| SME / policy | Precise, rule-focused | Unambiguous rules and exceptions |
Problem: …
Options: A / B / C with trade-offs
Recommendation: …
Assumptions / risks: …
Decision needed by: … · Owner: …
Story / area: …
What is unclear: …
Impact if we guess: …
Question for: … · Needed by: …
Words to drop
| Drop | Use |
|---|---|
| "The business wants…" | "[Named stakeholder] asked for X. Recommendation is Y because…" |
| "It should be intuitive" | "Success looks like [observable behaviour / metric]" |
| "We'll clarify in build" | "Open question owned by [name], decide by [date], or park the story" |
Under pressure, the instinct is to write more stories or more detail. Diagnose first. A fix for the wrong cause costs a Sprint of rework.
| Symptom | Likely cause | First move |
|---|---|---|
| Solutioneering (tools before problem) | Problem never framed; sponsor sold a system | Write a problem statement with non-goals today; park the solution |
| Gold-plating every edge as Must | No thin slice, or fear of UAT blame | Cut a vertical slice that proves the outcome; park edges as Should |
| Ambiguous acceptance criteria | Written alone, or after coding started | Three amigos rewrite with Given/When/Then before next build |
| UAT rejects "done" work | AC weak, late, or SMEs absent in discovery | Bring SME into Ready checks; freeze AC before coding |
| Everything is Must | No arbiter, or capacity never shown | Put capacity on the table; name the Must arbiter with the PO |
| Stories arrive mid-Sprint fog | Ready ignored under date pressure | Protect a Ready buffer; refuse untestable items into the Sprint |
| Stakeholders bypass the BA | Slow decisions, or unclear RACI with PO | Publish decision rights; speed small clarifications, escalate big scope |
| Rules live only in SME heads | No decision table or dictionary | Harvest rules workshop this week; link each rule to AC |
| Discovery never ends | No owner for "enough evidence" | Timebox; ship a falsifying slice with the PO |
| Traceability scramble before assurance | Trail never maintained | Backfill outcome-to-AC links for this tranche only; keep light going forward |
The one-minute checklist
- Name the problem in one sentence, without naming a solution.
- Is the pain framing, ambiguity, gold-plating, dependency or quality?
- Which decision unlocks the most clarity, and who owns it?
- Tell the PO (and SRO if needed) before they hear a distorted version.
- Protect Ready quality while you sort the noise; do not flood the Sprint with fog.
Glossary anchors
- BDD: Behaviour-Driven Development (Given/When/Then)
- DoR / DoD: Definition of Ready / Done
- MoSCoW: Must, Should, Could, Will not
- BPMN: Business Process Model and Notation
- Three amigos: PO / BA, developer, tester on examples
- JTBD: Jobs to be Done
- GDS: Government Digital Service
- Service Standard: 14 points for public services
- WCAG: Web Content Accessibility Guidelines
- RAID: Risks, Assumptions, Issues, Dependencies
- Green Book: HMT appraisal and Five Case Model
- SRO: Senior Responsible Owner
Companion: the cheatsheet distils every section into a one-screen field reference.