Why this matters
As a Business Analyst, your writing turns discovery into decisions. Clear writing reduces rework, accelerates approvals, and keeps teams aligned.
- Requirements: Translate stakeholder needs into testable acceptance criteria.
- Change requests: Explain scope, impact, and decision needed in one screen.
- Status updates: Make risks, blockers, and next steps unambiguous.
- Tickets/user stories: Help developers and QA act without meetings.
- Stakeholder emails: Ask for one decision, provide context, set deadline.
Concept explained simply
Clear writing answers three reader questions fast: What is this? Why should I care? What do you need from me?
- Clarity: Use plain words. Define terms once.
- Brevity: Keep only what helps the decision or action.
- Structure: Put purpose first, details later.
- Tone: Neutral, factual, respectful.
- Evidence: Numbers, examples, or screenshots when needed.
- Audience: Choose the smallest set of info your reader needs.
- Action: State the ask, owner, and deadline.
Mental model: The Clarity Ladder
- Purpose: One-sentence goal.
- Reader: Name the decision-maker or doer.
- Structure: Choose a pattern (e.g., SCQA, Problem→Options→Recommendation).
- Sentence: Short, active voice, one idea per line.
- Signal: Headings, bullets, and bold keywords to guide scanning.
Frameworks and quick templates
SCQA (Situation → Complication → Question → Answer)
Use for emails and updates.
- Situation: Current state in one sentence.
- Complication: What changed or blocks progress.
- Question: The decision or info needed.
- Answer: Your recommendation and next steps.
PORAA for BA writing (Purpose → Outcome → Requirements → Actions → Attachments)
- Purpose: Why this doc exists.
- Outcome: What will be true when done (measurable if possible).
- Requirements: Numbered statements + acceptance criteria.
- Actions: Owner, due date, status.
- Attachments: Links or names of files/screenshots (reference titles only).
Mini templates
Status update (short)
- Purpose: Sprint 12 – Checkout redesign status.
- Done: Payment service integrated; smoke tests passed.
- Risk: Fraud check latency up 200ms; mitigation in progress.
- Ask: Approve rollout to 10% by Friday 5 PM.
- Owner: PM; Rollback plan prepared.
User story
- As a returning customer, I want saved addresses so I can checkout faster.
- Acceptance criteria:
- Given a logged-in user with ≥1 saved address, when they reach checkout, then the default address is preselected.
- When user selects "Edit", then they can change, add, or delete addresses.
Decision email
- Purpose: Choose fraud threshold for launch.
- Options: A) Strict (−2% approvals), B) Balanced, C) Lenient (+1% chargebacks).
- Recommendation: B for week 1; review daily metrics.
- Ask: Approve option B by Tue 12:00.
Worked examples (before → after)
Example 1: Stakeholder email
Before: "Hey team, following up on some stuff we chatted about in the meeting, also not sure if legal has confirmed anything on the privacy policy but anyway we should aim to get this thing out ASAP…"
After:
- Purpose: Confirm privacy notice placement for checkout redesign.
- Status: Legal approved text (v3). Placement undecided.
- Options: A) Footer only; B) Checkout page link; C) Inline checkbox.
- Recommendation: B (visible, minimal friction).
- Ask: Approve option B by Thu 3 PM so dev can ship in Sprint 13.
Example 2: Requirement clarity
Before: "System should be fast when users log in."
After: "Login response time ≤ 800 ms at p95 for 1k concurrent sessions."
Example 3: Status update
Before: "We did a bunch of tests, some failed but it's fine and we might still hit the date."
After:
- Done: 24/27 integration tests passed.
- Risk: 3 failing tests block mobile checkout.
- Plan: Fix #1245, #1248 by Wed; fallback is disable Apple Pay on mobile.
- Ask: Confirm fallback acceptable if tests fail by Thu 5 PM.
How to write clearly (step-by-step)
- State the purpose in one sentence. If you can't, you aren't ready to write.
- List the reader's decision or action needed.
- Choose a structure (SCQA or PORAA).
- Draft with short sentences (15–20 words), active voice, one idea per line.
- Cut 30%: remove fillers, move extras to appendix/attachments.
- Signal the ask: bold the decision, include owner + due date.
- Self-check with the checklist below.
Self-review checklist
- Purpose is first and is one sentence.
- Ask is specific (owner + due date).
- Requirements are measurable or testable.
- Sentences are short; jargon is minimized or defined.
- Bullets group related ideas; each bullet starts with a keyword.
- Numbers and examples support claims.
- The reader can scan and act in under 60 seconds.
Exercises
Do these and compare with the solutions. Tip: Set a 10-minute timer per exercise.
- Exercise 1: Rewrite a rambling email into a crisp decision note with a clear ask.
- Exercise 2: Turn a vague requirement into testable acceptance criteria.
Saved progress note: The quick test is available to everyone. Only logged-in users will have progress saved.
Common mistakes and how to self-check
- Hiding the ask: Put the decision and due date near the top. Self-check: Can a skim-reader find the ask in 5 seconds?
- Vague requirements: Replace adjectives (fast, secure) with metrics (p95 ≤ 800 ms, AES-256 at rest).
- Walls of text: Use bullets and headings. One idea per bullet.
- Unowned actions: Always name an owner.
- Jargon overload: Define terms once. Prefer plain language.
- Overstuffed emails: Move detail to attachments/appendix and keep the main body for decisions.
Mini challenge
In 80 words max, write a status update that includes: one win, one risk with impact, and one decision needed with a due date. Use bullets.
Practical projects
- Requirements mini-spec: Pick a small feature (e.g., saved addresses). Write 5–7 requirements with acceptance criteria and a traceability note.
- Decision log: For two weeks, record every key decision (date, context, options, choice, owner). Aim for one-screen entries.
- Playbook page: Create a one-page template your team can reuse for status updates (purpose, done, risks, ask).
Who this is for
- Aspiring and current Business Analysts who write requirements, tickets, and stakeholder updates.
- Analysts transitioning from QA, support, or operations who need crisp written communication.
Prerequisites
- Basic understanding of your product or domain.
- Comfort with simple metrics (percentages, response times, counts).
Learning path
- Learn the SCQA and PORAA structures.
- Rewrite 3 old emails using these structures.
- Convert 3 vague requirements into testable acceptance criteria.
- Share with a peer for feedback; apply the checklist.
- Take the quick test to confirm mastery.
Next steps
- Apply the templates on your next sprint update and one user story.
- Start a personal snippet library for recurring phrases and structures.
- Set a monthly reminder to prune and simplify your templates.