A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a Business Analyst might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
Discovery
Double Diamond
Design Council model: Discover and Define, then Develop and Deliver, with diverge-converge cycles that separate problem and solution space.
When to use it
Problem unclear
Risk of specifying the wrong thing is high
Stakeholders jump straight to solutions
Example for a Business Analyst
Timebox Discover and Define before committing large Develop slices. Bring problem evidence into refinement so the PO and team see the diamond, not only a feature list.
Things that go wrong
Skipping Discover under date pressure
Endless Discover with no decision owner
Treating the model as a waterfall gate set
Discovery
Jobs to be Done
Users hire products to make progress in a circumstance. Focuses on the job, forces and competing solutions rather than demographics alone.
When to use it
Feature requests conflict and need a deeper frame
Solutioneering is drowning the problem
You need a sharper outcome statement for the PO
Example for a Business Analyst
Rewrite noisy feature asks as job stories. Use the job and forces to challenge solutioneering in workshops and keep acceptance criteria tied to user progress.
Things that go wrong
JTBD as jargon with no interview evidence
Ignoring competing solutions users already hire
Writing jobs so broad they cannot drive priority
Specification
BDD / Given-When-Then
Shared examples of behaviour that bind product, analysis, development and test before code hardens.
When to use it
Behaviour is ambiguous across roles
UAT historically invents the real rules
Automation can reuse living examples
Example for a Business Analyst
Facilitate three amigos sessions so examples become acceptance criteria. Prefer observable outcomes over UI click scripts unless the interaction is the risk.
Things that go wrong
Writing scenarios alone after coding starts
Over-specifying UI details that should stay flexible
Scenarios that are untestable or tautological
Modelling
BPMN / process modelling
Visual process notation for as-is and to-be flows, hand-offs, gateways and exceptions across roles and systems.
When to use it
Multiple actors or systems hand work off
Operational pain sits between teams
You need a shared picture before stories
Example for a Business Analyst
Model the seam that fails today, name owners, then cut stories from the to-be path. Keep the diagram light enough that SMEs will correct it.
Things that go wrong
Pretty diagrams with no owners
Modelling fantasy future state without PO buy-in
Models denser than the problem
Rules
Decision tables
Tabular representation of conditions and actions that exposes combinatorial rules SMEs hold in their heads.
When to use it
Eligibility, pricing, routing or policy rules combine
Verbal rules keep changing in UAT
Testers need coverage of rule combinations
Example for a Business Analyst
Harvest rules with SMEs, publish the table, and link each critical row to acceptance criteria or BDD scenarios the tester can prove.
Things that go wrong
Leaving rules verbal after the workshop
Tables nobody maintains after the first release
Encoding every rare exception as Must before the thin slice
Backlog shaping
User story mapping
Journey-shaped map that turns activities into release slices instead of a flat backlog of equal tickets.
When to use it
Need a shared journey before Sprint planning
Release slicing is political or unclear
Stakeholders cannot see the thin vertical path
Example for a Business Analyst
Facilitate the map with PO and UX, then cut a first release that proves the outcome. Refuse to leave the room with an uncut giant map.
Things that go wrong
Giant map never sliced into Increments
Mapping without users or informed proxies
Treating every activity as Must
Prioritisation
MoSCoW
Must, Should, Could, Will not for a fixed timebox. Forces scope honesty under a deadline.
When to use it
Fixed deadline with negotiable scope
Stakeholder workshops that need a shared scope line
Statutory or regulatory dates
Example for a Business Analyst
Facilitate scope talks with capacity on the table so Must means Must. Keep a named arbiter (usually the PO or SRO) and a visible Will-not list after the workshop.
Things that go wrong
Everything becomes Must
Will-not list disappears after the workshop
No capacity check, so Must is fantasy
Team methodology
Scrum
Lightweight agile framework with roles, events and artefacts for a usable Increment each Sprint. The BA supports Ready work; the PO owns backlog order.
When to use it
Stable team with a clear backlog owner
Need refinement and review cadence
Value emerges through thin vertical slices
Example for a Business Analyst
Own clarity in refinement and three amigos. Never outsource priority to whoever shouted last. Protect Definition of Ready so Sprint Goals stay honest.
Things that go wrong
BA as ticket clerk for every stakeholder email
Refinement as a monologue
Acceptance criteria after coding starts
Team methodology
Kanban
Visualise work, limit WIP and manage flow. Strong fit when analysis demand is interrupt-driven beside delivery.
When to use it
Unscheduled clarification and BAU analysis load
Flow of Ready items matters more than Sprint theatre
Classes of service need to be explicit
Example for a Business Analyst
Make analysis WIP visible. Use classes of service so urgent clarifications do not silently erase discovery for strategic outcomes.
Things that go wrong
Invisible analysis queue that bottlenecks the team
No WIP limit on 'clarify with SME'
Ignoring aging blockers on rules questions
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology for UK public services.
When to use it
UK public service build or iteration
Service assessment preparation
Need a shared quality bar across product, design and analysis
Example for a Business Analyst
Attach Service Standard evidence to major requirement themes so assessment is continuous. Put relevant points into Definition of Ready and Done with the PO and tester.
Things that go wrong
Paperwork-only assessment prep
Leaving accessibility and performance out of AC
Treating the Standard as design-only, not analysis-owned
Accessibility
WCAG
Web Content Accessibility Guidelines. AA is the common public-sector floor for inclusive interfaces.
When to use it
Public-facing interfaces
Inclusive design and test evidence
Service assessment or equality duty risk
Example for a Business Analyst
Put WCAG 2.2 AA checks into acceptance criteria for public interfaces. Partner with UX and testers so evidence exists before release, not after complaints.
Things that go wrong
Treating AA as optional polish
Relying only on automated scans in AC
Bolting accessibility on in the final Sprint
Business case
Green Book / Five Case Model
HMT appraisal guidance and the Strategic, Economic, Commercial, Financial and Management cases for public funding decisions.
When to use it
Seeking or refreshing public funding
Options appraisal needs economic and strategic rationale
Benefits realisation is live
Example for a Business Analyst
Shape options and assumptions with evidence the Economic and Management cases can use. Challenge optimism bias locked into a feature list dressed as analysis.
Things that go wrong
Business case as fiction written once
Options that are really one preferred solution
Benefits with no owner after go-live
Profession
BABOK / IIBA techniques
Business Analysis Body of Knowledge techniques for elicitation, analysis, requirements lifecycle and solution evaluation.
When to use it
Need a shared professional vocabulary
Complex elicitation across many stakeholders
Assurance asks how analysis was done
Example for a Business Analyst
Pick techniques that fit the risk, not the whole catalogue. Use BABOK as a menu: interviews, workshops, document analysis, prototyping, and requirements lifecycle management.
Things that go wrong
Technique theatre: every artefact because the book lists it
Ignoring agile Ready/Done in favour of heavyweight specs
Documentation that never reaches developers or testers
Change
ADKAR
Individual change journey: Awareness, Desire, Knowledge, Ability, Reinforcement. Useful when requirements depend on staff adoption.
When to use it
Process change needs people to work differently
Training alone is not moving behaviour
Resistance shows up as 'the rules are wrong'
Example for a Business Analyst
When SMEs resist a to-be process, diagnose whether the block is Awareness, Desire or Ability before rewriting more requirements. Partner with Change Management on Reinforcement after go-live.