Your BA reference

Finding out what people know and need

Finding out what people know and what they need has a name: elicitation. The interview is where most of it starts. You sit with one person, ask good questions and listen far more than you talk. It sounds simple. The habits behind it are what make it work.

Before the interview

Nobody hands you the questions on a real project. Before every interview, write down three things:

• What you understand so far. The facts you already have, and who gave you each one.
• What you don't yet understand that matters. These become your questions.
• What you are most likely to be wrong about. Ask about these on purpose.

The question that works best is usually the plainest one: what actually happens, step by step?

The habits of a good interviewer

Three traps to watch for

Talk to the people who decide and the people who do

A sponsor can tell you the budget, the deadline and what success looks like. They usually can't tell you how long the daily admin takes, or which day of the week is the worst. The people doing the work can't tell you the budget. If you only speak to one group, your picture will look nothing like the real one. You need both.

Sorting what you heard into themes

Once you have spoken to several people, pull out the themes: the points that keep coming up. Map where people agree and where they differ. Two themes that pull against each other often hide a requirement. If one person wants customers to book online and another wants to keep taking calls, the requirement is that the new way works alongside the phone, not instead of it.

Your notes are your memory and your evidence

Writing things down isn't admin. Your notes are what you remember, what you can prove, and one day they may be what protects you. Write them while they're fresh: the same day, or the day after.

Three reasons to write it down

• Information changes. A deadline of eight weeks becomes six after a board meeting. Your notes show what was agreed first, and when it changed.
• Decisions get challenged. When someone asks where a number came from, you can say straight away who said it, and in which meeting.
• It protects you. If somebody says later that a feature was promised, you can show what was actually decided, by whom, and when.

A good note has four parts

The action matters most. If you don't write it down, nobody will remind you.

Source everything

Next to every fact, write who it came from. "Forty five minutes every morning" is somebody's number, not a fact on its own. When you use it later in a problem statement or a business case, you can say exactly where it came from. If something was only said out loud, follow it up in writing to confirm it.

Write down every decision

In six months somebody will ask why a feature is missing. People move on and memories fade. When a decision is made, write down five things: the decision, the date, the options that were looked at, the reasoning, and who made it. Three sentences is enough.

The stakeholder wheel: who has been missed?

A stakeholder is anybody a change affects, or anybody who can affect it. The names you are given at the start are the names other people remembered. The stakeholder wheel finds the rest by asking one question for each of eight groups, rather than relying on anyone's memory.

The eight groups, and the question for each

How to work round it

• Go back to your notes first. Your notes hold more stakeholders than your list does. Customers, owners and competitors are often mentioned in passing.
• Place people by what they do, not their job title. Someone called a manager who doesn't manage anybody, and does the work that is changing, belongs with the employees.
• Let the questions find the rest. The supplier and the regulator rarely come up in interviews, because nobody is thinking about them. The questions find them.
• Leave a group empty rather than forcing a name in. An empty group is a question to ask the sponsor, not a mistake. An honest gap is worth more than a tidy wheel.

Three kinds of invisible stakeholder

• The people who will support it once it is switched on. Who answers the phone when it goes wrong on a Saturday morning?
• The outside bodies whose rules you have to follow. If a system will hold people's names and phone numbers, data protection law applies.
• The suppliers whose systems set the limits of what can be built, and how fast.

Deciding who gets a say

The wheel finds people. It doesn't tell you how to work with them, and a long list is too many to treat the same way. The power interest grid places each person by two things: how much power they have over the change, and how much they care about it. That is called stakeholder analysis.

The four boxes

How to place someone

• Power: ask what happens if this person says no. Power is about what someone can stop, not how senior they are.
• Interest: ask how much the change touches their day. Someone who is worried about a change cares about it a lot.
• Every box needs a reason you can point to, from what people said and did. Not from their job title.

Keep it up to date, and keep it to yourself

• Look at it again every few weeks, and always after a reorganisation, a new sponsor or a change of scope. A grid from three months ago can send you to the wrong people.
• Plan for the people you haven't met. Work out who speaks for them and how you will reach them, before they make a decision that affects your project.
• Never ask someone which box they belong in. If you're unsure about someone's power, ask an ordinary question that tests it: who has to say yes before anything is bought? Who does the team listen to?
• Nobody should ever see it. Nobody wants to find out they were placed in low power.

From the grid to who hears what

Analysis tells you where each person stands. Management is what you do about it. The grid tells you how much attention each person needs, but on its own it tells nobody anything. The communications plan does that: who hears what, how, how often, and from whom.

The five columns

Some people get no line yet: you watch them instead. A regulator gets no message at all. You check its rules before the system holds anybody's details.

Every stakeholder is a person first

The boxes are starting points, not rules. Some senior people want the detail and some managers want one line. If someone tells you how they want to hear from you, a weekly email in bullet points say, that beats anything the grid suggests. Write it in the plan.

The question that shapes every message

For everyone on your grid, answer one question for yourself: what would make this person an active supporter? One person wants no extra work for their team. Another wants to keep talking to their clients by phone. Each of those is what your messages to them should be about. You find the answer by listening, not by asking it outright. A request that helps someone hit what their own manager measures them on gets answered in hours.

Go and see the work

Everything you learn in an interview is something somebody told you. People explain a process the way it should work. They do it the way it actually does. Observation means sitting beside the people doing the work and watching. It is often the most useful hour of a project.

How to observe

• Ask first. Get the manager's say so before you visit. You watch with permission, never by turning up.
• Go to every place the change covers. One place shows you a problem. Two show you whether it is a pattern. When the same thing goes wrong in two places, it isn't one person being careless. It's the way the work is set up.
• Sit at the back and keep quiet. The moment you join in, you change the work you came to see.
• Count something. One number does more than ten opinions.
• Compare two sources. Put two records side by side, such as two teams' diaries or two copies of a list. It shows gaps neither one shows alone.
• Ask what normal looks like. Before you leave, ask: was today a normal day? That one question tells you how much weight your numbers can carry.

Count the claim

When someone says always, never, nobody or everyone, write the word down and go looking for the number behind it. "Nobody picks up the phone" may turn out to be four calls in seven. The claims aren't lies, just impressions. The numbers are where the analysis starts. Keep a list of the claims you hear, and next to each one, how you could check it: watching, a report, a system record or a log.

Told, or seen?

Sort every finding into two piles: what somebody told you, and what you saw or counted yourself. Both are useful. "She said" and "I counted" carry different weight, and the people reading your work need to know which is which. Write the source next to every finding.

What to watch out for

• People work differently when watched. They answer faster and follow the rules more closely. Stay long enough for them to forget you're there, and tell them you're looking at the process, not at them.
• Don't fix it while you watch. Write every idea down for later. Ideas can wait. What you see can't be got back.
• Be careful with personal details. Your notes need the pattern, such as one booking made twice, not who the booking was for.
• Look for the workaround. Crossing out and rewriting, or ringing another team to check, are workarounds. Nobody designed them and nobody mentions them, because to staff it's just the job. That is called tacit knowledge: what people know so well that they never think to say it. The workaround is often where the real requirement is hiding. Ask: why do you do it that way? What would go wrong if you didn't?

The view from outside

Staff only see their own side of a process. The customer sees the whole of it: every call that wasn't answered, every wait, every time nobody told them what was happening. Always speak to the customer. If you don't, the design is a guess about what they want.

What the customer tells you that staff can't

• The steps nobody inside sees. How many times they rang before anyone rang back.
• What they did while they waited. Often they went to a competitor.
• What never happened. A confirmation they never received isn't on any staff process, because it has never existed.
• What they actually wanted. A business may want customers to book online. Nobody has checked whether customers want to.

One customer is a start, not proof

A single conversation can change your picture completely, and it is still one person. Treat it as a strong lead. If what they said matters to the design, find a way to check it with more customers, through a few short questions when they get in touch, complaints data or a short survey.

Reading and drawing a process map

A process map is a picture of how work gets done: who does each step, in what order, and what happens when things go wrong. People skim a paragraph and nod. Show them a map and they point at a box and say "that isn't what happens". That is exactly what you want, and it's why you draw before you write.

An example to read

A made up example: a customer brings a faulty item back to a shop. Read it from left to right and follow the arrows. The coral arrows are handoffs.

The shapes, and what each one means

These shapes and their meanings are called notation. There are bigger sets of notation with dozens of shapes. You don't need them to start. A simple map everyone in the room can read is more use than a perfect one only you understand. Ask what the team already uses, and use that.

Why swimlanes?

Take the lanes away and a map is a line of boxes. It tells you what happens, but not who does it. With lanes you can see at a glance who is involved, who does most of the work, and every place the work changes hands. Lanes also make you decide who is involved before you draw a single box. If you can't name the lanes yet, you're not ready to draw. Name them after jobs, not people: if the shop assistant leaves, a lane called Shop assistant is still right.

Four mistakes to avoid

• A lane named after a person. People leave, and the map is wrong the day they go.
• A diamond with only one answer. The No is often where the trouble is. Ask straight away what happens on the other answer.
• A dead end. Trace every path with your finger. If one stops at a box with nothing after it, something is missing.
• A box without a doing word. "Receipt" tells nobody what happens. "Check the receipt" does.

The as is map: how it works today

An as is map shows how a process works now, before anything changes. It's not the plan, and it's not how it should work. Draw it after you have watched the work, or at least after you have talked to the people who do it, not just their managers.

• Start with a trigger and end with an outcome. A clear start and end stops a map wandering.
• Show both paths at every decision. The happy path is rarely where the problem is.
• Put the workarounds in. The unofficial steps are often holding the whole process together.
• Put the outliers on as notes. A map with the exceptions on it is a map people trust.
• Listen for "normally it works like this, but sometimes". The sometimes is where the real process lives, and it's often missing from a first map.

A problem everyone can agree on

A problem statement is one or two sentences that everyone can agree on before anyone talks about fixing anything. It says what is going wrong, who it affects, what that leads to, and what good would look like. It sounds simple, and it's the piece of work that gets skipped most often. When it's skipped, people spend weeks arguing about answers, because they never agreed on the question.

Why the right problem matters

A project can be run perfectly and still fail: on time, well built, and solving the wrong problem. That is the most expensive kind of failure, because nobody sees it until the money is spent. Three real examples from the UK:

None of them failed because the technology didn't exist. They failed in the gap between what was being built and what the people doing the work needed. The first version of a problem you are handed is the version that has been approved for telling. Treat it as a starting point, and go and look for the evidence.

The four parts

Three good ones to read

Notice what isn't there. Nobody is blamed, and none of them says how to fix it.

Four mistakes to avoid

Where the evidence comes from

You don't make a problem statement up. Every part comes from one of four places: what is written down, what people tell you, what the numbers say, and what you see for yourself. The more of them that point the same way, the surer you can be. Keep two piles: what you know because you counted or saw it, and what somebody believes because they told you. If you have both, lead with the count. Write it once you have evidence, not before.

Fix the cause, not the symptom

Fix only a symptom and the problem comes back somewhere else. When someone describes a problem, ask why it happens. Then ask why again. Stop when you reach something that, if it changed, would stop the problem. That habit is called the five whys.

The four jobs it does for the rest of the project

1. It gets everyone to agree. Your sponsor reads it and says: yes, that's it.
2. It tests every answer. For each option you ask: does this solve the problem we wrote down?
3. It keeps the work on track. When someone asks for an extra, hold it against the statement. If it doesn't help with this problem, it can wait.
4. It tells you when you've finished. The last part says what good looks like. Every number in it can be counted again afterwards, so it becomes your success measures.

Getting it agreed

• Read it to your sponsor, then stop and listen. If they hesitate over a word, that word needs work. Then get a short email back: yes, that's the problem. It becomes the anchor for everything that follows.
• Check it with the people who live with it, and with every team or site it covers before it's signed off.
• People will see it differently. Ask each person the same three things: what is the problem from where you sit, what does it cost you, and what do you think is causing it? Where they agree is the start of your statement. Where they disagree is where the analysis needs to happen. If two people really disagree, take it to the sponsor to decide.
• Words mean different things to different people. One person's urgent is today and another's is this month. Use numbers where you can.
• If the problem changes, say so. Write it again and get it agreed again. Don't quietly start working to a different one.

Other tools for looking at a problem

They work together. Use one of these to do your thinking, then write the problem statement to get the thinking agreed.

Where requirements come from

An as is map shows how things work today. A to be map shows how they should work once the problem is fixed. Put one above the other and the differences jump out. Writing those differences down is called gap analysis, and it is where requirements come from: not from a wish list, and not from whoever asked loudest.

Drawing the to be map

• Draw it after the problem is agreed, so it fixes the right thing.
• Keep the same start and end. The to be fixes the same process, not a new one.
• Take the workarounds out. Fix the cause and the workaround isn't needed.
• Keep what works. Not everything has to change, and saying so reassures people. A change that only works for some customers meets resistance from the people who serve the rest.
• A lane can be a system, as long as you don't name the product. "Shared diary" is fine. A brand name isn't.
• Watch where the paths meet. The step where different paths join is often the heart of the change.

Gap analysis in four steps

Where nothing changes, write that down too. "Staff still take bookings by phone" is no gap, and it tells the people who worried about losing the phone that they haven't.

A gap isn't only in the process: POPIT

Technology is the one everybody looks at. The other four are where changes fail.

Check it against the problem you agreed

A to be map isn't right because it looks tidy. It's right if it fixes the problem the sponsor agreed. Take your problem statement and check the map against it one line at a time. If a line of the statement has no answer on the map, the map isn't finished. If a step on the map answers nothing in the statement, ask why it's there. If something is only partly fixed, say so. Then go back to your as is evidence and check every problem you found has an answer, not just the main one.

Bringing people with you

A map changes nothing by itself. People have to want to work the new way. That's called buy in, and you don't win it with a presentation at the end. You earn it through the relationships you build from your first conversation.

• A change takes things away too. A familiar routine goes. Even good changes feel like a loss to someone. For each gap, ask who it affects and how they'll feel about it.
• Resistance usually has a reason, and each reason needs a different answer. Ask the person on their own, to understand them, not to convince them.
• Show people their own words in it. Point to the part of the design that came from them. People back a change they can see themselves in.
• Nodding isn't agreeing. Everyone wants "better", and each person pictures something different. The test is whether each person can read your map and say: yes, that's what I expected.
• Walk it with the people who'll use it. Take a real example through the to be map step by step and ask: what could go wrong here? Their answers are the exceptions your map doesn't show yet.

One need, one sentence

A map shows what has to change. It doesn't tell anyone exactly what to build, or how to check it's right. So you write down what each person needs from the new way of working, one need at a time. A user story is one short sentence that says who the need is for, what they need to be able to do, and what they get out of it.

Kinds of requirement

The non functional kind is the first to be forgotten, so keep both kinds of solution requirement on the same list.

Four habits of a good user story

Check the list before you rank it

A list of requirements can be well written and still be wrong. Read it as one list and run three checks:

1. Is anybody left out? Count the user stories for each group in your problem statement. A group with no user story at all is a finding: report it, and ask what they need. Don't make a user story up.
2. Did you cover what the customer asked for? Hold your user stories up against what a customer told you, one point at a time. A customer's words are the quickest way to find a gap.
3. Is any user story too vague to build? "Keep the parts of the old system that work well": which parts? Mark it as open and put a name against the question. It's better to say so now than to find out in testing.

Deciding what matters most

There is never time or money to build everything at once. MoSCoW is a way of putting requirements in order, so the work that matters most is done first. Each requirement goes in one of four columns, and every one gets a reason.

The one hard test for a must have

Ask one direct question: if this doesn't go first, does the project fail? If the honest answer is no, it's a should have at most. Hold that line. If almost everything is a must have, you haven't prioritised. You've relabelled a wishlist.

The board is also a plan

• The must haves go first, inside the deadline.
• The should haves follow as soon as there is time, then the could haves.
• Should and could are your safety margin. If a deadline tightens, they are what can wait without the project failing.
• Naming what's out matters as much as naming what's in. A whole feature left for a later phase should be written down as won't have this time.

Will it fit in the time?

Counting cards isn't enough. Six must haves is not six weeks of work: one big requirement can take longer than five small ones. So before anyone promises a date, somebody has to say how big each requirement is. That is called estimating.

Who estimates

The people who will do the work: the developers, or the supplier who sets the system up. Not the sponsor, and not you. Your part is to make each requirement clear enough for them to estimate: what is needed, why, and what done looks like. If they say it's too vague, it needs more analysis from you. If they say it's too big, split it into smaller user stories.

T shirt sizes and story points

Most teams don't estimate in hours. They compare one piece of work with another, because people compare better than they guess. Ask five people how many hours a job will take and you'll get five answers. Ask whether it's bigger or smaller than the last job and they mostly agree.

• T shirt sizes: small, medium or large.
• Story points: each user story gets a number. A user story worth 8 is about four times the work of one worth 2. The numbers are not hours and not days, and they only have to stay steady inside the team that uses them.

Velocity

Many teams work in sprints: short, fixed blocks of work, usually two weeks long. Velocity is how many story points a team finishes in a sprint. Look back over their last few sprints and you can forecast what they're likely to finish next.

• Velocity is never a way to judge people. Push a team to raise it and they will simply give every user story a bigger number. No more work gets done, and the forecast stops being any use.
• A new team has no velocity yet. Its first forecasts are guesses, and they get better every sprint.
• A date chosen before anyone sized the work is a target, not a forecast. That happens a lot. Remember it when you compare options.

Estimating in waterfall and agile

Most places mix the two. When you start somewhere new, ask how estimating is done there.

How you'll know it's done

A user story says what someone needs. Its acceptance criteria say how anyone will know it has been done. They belong together: every user story has one or more acceptance criteria of its own, and they are a way to test that what was built works as it should.

Given, when, then

How many does a user story need?

One for the normal day, when everything goes right. Then ask: what could be different? The patient might cancel. That is an awkward case, and it needs an acceptance criterion too. Three or four for one user story is normal. If you find you need ten, the user story is trying to do too much: split it into two user stories.

Where they come from, and who uses them

• The best ones come from things that have already gone wrong. Before you write any, look back at what people told you and what you saw. A booking that was moved in one place and never updated in another becomes: given a booking is moved, when someone opens the other list, then they see the new time.
• They are written before anything is built, so the people building it and the people testing it are aiming at the same thing.
• They are not the same as testing. Acceptance criteria are the target. Testing is the checking, done afterwards.
• Users test against them. When the people who will use the system try it before it's switched on (user acceptance testing), they take one acceptance criterion at a time, do what it says, and check they see what it says they should. When every one passes, the user story is done.
• Write them for the user stories that go first. The others get theirs nearer the time, because the detail goes out of date.

Scoring options fairly

Most problems can be fixed in more than one way. An options appraisal compares them by asking every option the same questions and scoring the answers. It doesn't make the decision. The sponsor does. Your job is to make the choice easy to make, and easy to explain to whoever they answer to.

Four things that make a comparison fair

Typical options

• Buy: ready made software. Quick to set up, little you can change, and often a cost every year.
• Build: made just for the organisation. Fits well, costs more up front and takes longer.
• Do the minimum: better use of what is there already, with some training. Cheap, and it often leaves the cause in place.

Every option falls short somewhere. That is normal. If one option looks perfect, you have probably missed something.

Look behind the totals

The highest total is where your recommendation starts, not where it ends. The sponsor will ask what could go wrong, and they will be right to.

• Every option has a people risk as well as a cost. A system nobody uses solves nothing. Name the person or team, and say what you will do about it.
• Doing the minimum is never free. Put a number on carrying on as you are: lost customers, hours of admin. It is the figure the other options have to beat.
• Say what the risk does to the date. A sponsor forgives a risk you warned them about. They don't forgive a surprise.

Helping somebody decide

Notes, maps and lists change nothing by themselves. A recommendation is where your work turns into a decision somebody can make. It's the reason a business pays for a business analyst in the first place.

The five things it says

1. Which option you would choose.
2. Why, following from your scores.
3. What the organisation gets out of it.
4. What could go wrong, with the risks named.
5. What happens next.

If you find yourself recommending something your scores don't support, go back and look at the scores.

Write it for someone who wasn't in the room

The sponsor will read it, and so will the people they answer to, who have never met you. Write it so that somebody who missed every conversation could follow it. Use plain words, and leave out BA terms.

A useful second reader, not the analyst

AI tools are good at the writing and checking parts of BA work: a first draft, a list of things you might have missed, a calmer version of a tricky email. They're no good at the judging part. They weren't in the room, they don't know the people, and they can't build trust or get agreement. AI generates the thing you react to. Whether it's right is still your judgement.

Where it helps

What it can't do

• It can't notice who is missing. It only works with what you give it.
• It can't watch the work, count for you, or spot the workaround nobody wrote down.
• It doesn't know the people, and it can't win them over.
• It can't make the call. It can suggest. You and the sponsor decide.
• It can be wrong, and sound sure. If it quotes a law, a rule, a figure or a price, check it against a real, legitimate source before it goes anywhere near your sponsor. If it adds a number you didn't give it, take it out.

The three rules

What an NFR actually is

Functional requirements describe what the system does. Non-functional requirements describe how it does it — performance, availability, security, scalability, accessibility, observability, compliance. Good BAs raise them deliberately; most projects fail because NFRs were treated as "engineering will sort that out".

The seven NFR categories you'll meet

How to write a good NFR

Who surfaces NFRs in a conversation

• Tech leads raise performance, availability, scalability — they live with the consequences when these break.
• Compliance and security teams raise security, GDPR, audit, accessibility — usually with phrases like "we have to demonstrate" or "the regulator expects".
• Operations / support teams raise observability — they want logs they can troubleshoot from at 2am.
• Sponsors rarely raise NFRs directly but will react strongly when an outage or breach happens. Anticipate.

SOAP, REST, wrappers — what a BA actually needs to understand

Integration is where waterfall specs break and agile sprints stall. Most BAs aren't expected to architect the integration — but a software BA is expected to understand it well enough to write requirements against it, to challenge a tech lead's assumptions, and to translate the limits of a legacy system into business-language risk.

Two things at the centre: SOAP and REST

When a tech lead says "we'll integrate via the API", the unspoken question is which kind. The two you'll meet on real projects are SOAP and REST. They are not the same and the difference matters to a BA because it changes what's possible, what's reliable, and what's affordable.

What a wrapper is — and why it matters

A "wrapper" is a thin layer of code that sits in front of a legacy system and presents a modern API. The legacy system underneath stays as it was; the wrapper translates modern requests (often REST or SOAP) into the legacy system's native commands. Wrappers are common because the cost of replacing a legacy core is usually 10−100× the cost of putting a wrapper on it.

The catch: wrappers inherit the limits of the system they wrap. If the legacy system can only handle 3 transactions per second, the shiniest REST wrapper on top still only handles 3 transactions per second. That number is what an integration tech lead is really telling you when they say "the wrapper has a transaction-rate ceiling".

Legacy integration patterns — the four you'll meet

• Direct integration. Your new system talks to the legacy system natively (often through a database connection or a vendor SDK). Cheapest to build, brittlest in production — a change to the legacy system can break your system without warning.
• Wrapper / facade. A thin translation layer in front of the legacy system. Adds a layer of safety: the legacy system can change underneath without breaking the consumers, as long as the wrapper contract stays stable.
• Middleware / ESB (Enterprise Service Bus). A central piece of software that routes requests between many systems. Useful when you have lots of legacy systems that need to talk to each other. Heavy, expensive, slow to change — but predictable.
• API gateway + cache layer. Modern variant of the wrapper pattern. A gateway sits in front of one or more upstream systems, handles authentication, throttling, and caching. The cache layer is often what saves you when the upstream system can't sustain the load.

What a BA captures about an integration (the requirement checklist)

When you're writing a requirement against an integration point, these are the things your spec or your story needs to cover. Miss any of them and you'll be re-opening it in week 4.

The questions to ask your tech lead in the integration conversation

• "Walk me through the integration paths." Get the architecture in their words, not the documentation's.
• "What's the transaction-rate ceiling on the wrapper / upstream?" The number you get back drives FR-INT-* and your NFR-SCALE-* requirement.
• "What breaks first — latency, throughput, or correctness — if we go above the ceiling?" Tells you which fallback to design first.
• "If the wrapper is unavailable for 10 minutes, what's the fallback?" Surfaces resilience requirements you'd otherwise miss.
• "Is the upstream's data the master, or are we?" Determines whether you cache, mirror, or always read live.
• "If we wanted to replace the wrapper, what would it cost?" Useful for the three-options business case. Often the wrapper is the cheapest piece to upgrade.
• "What changed in the upstream in the last 12 months?" Legacy systems quietly change. Recent changes predict recent incidents.

Translating the tech detail into BA-language risk

The decision framework every software BA needs

"Build it ourselves" feels right because you're in control. It rarely is. Most internal projects underestimate build effort by 2-3x and overestimate the value of customisation. A BA's job is to force the comparison with the same rigour for all three options.

The seven questions to test each option against

When to integrate (often the right answer, often missed)

Integrate = use an existing system (often a buy) but write the glue yourself. You get the speed of buy + flexibility of build for the specific bits that matter. Most "build vs buy" debates ignore this third option even though it's usually the right one.

The conversation to have with each role

• Sponsor: what would change your mind between build and buy? (Most say "cost" — that gives you the test.)
• Product Manager: if we buy, what gets sacrificed on roadmap flexibility? If we build, what gets sacrificed on speed?
• Tech Lead: what are the integration paths for buy? Is there a build-vs-buy decision hidden in there (e.g. middleware)?
• Finance: how do they prefer to fund it — capex (favours build), opex (favours buy)?

Minimum Viable Product — and what it isn't

An MVP isn't "the rubbish version we'd be embarrassed by". It's the smallest thing that delivers measurable value AND that you can learn from. If it doesn't deliver value OR doesn't teach you something, it's not an MVP — it's just unfinished work.

The two tests

1. Does it deliver real value on its own? If yes, you've earned the right to ship. If no, you're shipping something that creates risk without payoff.
2. Will it tell you something you didn't know? An MVP exists partly to disprove assumptions. If you'd ship the same v2 regardless of v1 feedback, your MVP is wrong.

An MVP: a worked example

Why this is a brilliant MVP:

• Real value: 30% reduction in duplicates from week 8 onwards.
• Real learning: tells you whether seeing existing cases is enough — or whether you really do need automatic merging too. That's a £100k design decision answered for free.
• Right scope: excludes the hard parts (case-merging logic, customer-ID matching) for v2 when you've validated the easier hypothesis.

Writing user stories that don't dissolve in a sprint

Most user stories die in refinement because they're vague, too big, or written from the BA's perspective rather than the user's. The format isn't the hard part — "As a / I want / so that" is fine. The hard part is the discipline behind each clause.

The INVEST principle

From conversation to story

Splitting stories that are too big

• By workflow step: "view cases" / "merge cases" / "close merged cases" — three smaller stories instead of one big one.
• By data type: "show phone cases" first, then add email, then web. Each shippable.
• By user role: "view as agent" first, then "view as supervisor with extra data".
• By happy path vs edge case: happy path first, exception handling as separate stories.

Functional requirements that survive sign-off

A waterfall functional requirement is a single, testable sentence that tells the development team what the system must do — written so that, six months later, you can take it to a tester and they can write a test against it. Most reqs fail not because the BA didn't understand the need, but because they didn't write it down with the right discipline.

The anatomy of a "shall" statement

Every waterfall functional requirement has four parts. If any part is missing, the requirement isn't done.

MoSCoW prioritisation — what it actually means

MoSCoW (Must / Should / Could / Won't) is the discipline you use to keep a spec from becoming a wish-list. Each priority has a precise meaning — not a feeling.

Source attribution — every requirement names its origin

A functional requirement without a named source is a requirement nobody owns. The "Source" column on a requirements table is not decoration — it's how you defend the requirement in a change-control meeting six months in.

• Name the stakeholder. "Maya Okafor (Sponsor)" beats "Operations". Specific people defend specific decisions; departments don't show up to meetings.
• Cite the artefact. "Agent workshop, 12 Feb" beats "agent input". You can show the notes; you can show the photo of the whiteboard.
• Name the regulation. "FCA Consumer Duty — PRIN 12" beats "compliance". Regulation has clauses; cite them.
• Combine where the requirement has multiple parents. "Maya Okafor + agent workshops" is fine. "Compliance" is not.

Traceability — the chain you can pull

Each functional requirement should be traceable in two directions:

• Backwards to a business need: which business outcome does this requirement enable? For example, the sponsor's "70% reduction in duplicates" links to the three duplicate checking requirements. If they ship, the outcome can be measured.
• Forwards to a test: at UAT, every Must requirement gets at least one acceptance test. If a requirement has no test, either it isn't a requirement (delete it) or you forgot to write the test (add it). The test scenarios template lives at Test scenarios template.

Change control — the discipline that keeps the spec honest

The biggest waterfall failure mode is the spec becoming a contract instead of a conversation. Once signed, no one wants to admit any line in it was wrong — so the team ships the documented system rather than the right one.

The countermeasure is to build a Change Request (CR) process from day one and use it without shame:

1. Anyone can raise a CR — stakeholder, developer, BA.
2. The BA writes up the CR using the change request template: what's changing, why, impact on cost / time / scope / risk.
3. The Change Control Board (CCB) decides: yes (rebaseline the spec), no (record the decision and move on), or defer (capture as Won't this time).
4. If yes: version up the spec and name the change request in the version history, so every change stays traceable to the decision that approved it.

The same need, expressed both ways

Most teaching about "waterfall vs agile" stays at the level of the methodology. What changes day-to-day for a BA is the shape of the requirement — how it's written, how it's signed off, how it's allowed to change. Here's one need expressed both ways, with the BA's job called out on each side.

The same need, two forms

Ben Carlisle (senior customer service agent, 12 years) said this in discovery:

Same need. Two ways to write it down:

What changes between them — for the BA

When each is the right answer

Both shapes are professional artefacts — the question is which fits the context.

Why every business case shows three options

A business case with only one option is a sales pitch. Sponsors who matter have been around the block — they will reject a one-option case on principle, because they know they're being railroaded. Show three: Do Nothing, a lighter alternative, your recommendation. Then your case has integrity.

The pattern

The credibility test

For each option, you need three numbers: cost, benefit, time to value. If you can't fill those in honestly for the alternative options, you haven't actually considered them.

Consumer Duty — what it actually means for the system you're building

The FCA's Consumer Duty (in force since 2023) requires regulated firms to demonstrate they're delivering good outcomes for customers — not just following processes. For BAs in financial services this changes requirements work: every system needs to evidence outcome quality, not just transaction completeness.

The four outcomes you need to evidence

What BAs on a project like this need to capture

• Vulnerability flags on the customer/case record (financial difficulty, bereavement, low capability, disability) — visible to every agent without re-asking the customer.
• Outcome categorisation per case: resolved, partially resolved, unresolved, escalated. Reportable to the FCA on request.
• Repeated-contact tracking: same customer contacting multiple times for the same issue is a red flag.
• Time-to-acknowledge vs time-to-resolve as separate metrics: regulators care about both.
• Audit trail immutable for at least 6 years after the policy lapses. ICOBS requires this; FOS will ask for it.

The conversation to have with compliance

Compliance officers are usually brought in too late on projects. Ask:

• Which Consumer Duty outcome does this project most affect?
• What would you need the system to evidence for an FCA thematic review?
• Are there vulnerability indicators we should automatically flag, or is that a manual judgement?
• What's the worst-case scenario — and what's the smallest thing the system could do to prevent it?

How to get the most out of a tech-lead conversation

Tech leads will give you more value per minute than any other stakeholder — IF you ask the right questions. They'll also bury a project with risks unless you frame those risks as solvable problems. Good technique: separate the technical surfacing from the risk-management response.

The four questions to always ask a tech lead

1. "Walk me through the integration risk." The honest answer tells you whether build/buy/integrate decisions are real or fake.
2. "What NFRs would you set, in your perfect world?" They'll usually overscope — but you'll learn what they actually care about, which becomes your minimum.
3. "What are you assuming that might not hold?" Tech leads have more assumptions than anyone. Capture every one for the assumptions log.
4. "If the wrapper / integration / system breaks at 2am, what's the fallback?" Surfaces resilience requirements you'd otherwise miss.

How to frame what you hear back to the sponsor

Tech leads talk about risks; sponsors hear "this project might fail". Translate:

Making compliance a partner rather than an obstacle

Compliance officers get involved late because BAs treat them as a box-tick at the end. Good technique: bring them in during discovery, not at sign-off. They'll surface requirements that save you weeks of rework — and they're more accommodating than their reputation suggests when treated as colleagues.

Three questions that change the relationship

1. "What would a thematic review of this area look for?" Tells you what evidence the system needs to produce.
2. "What's the worst-case compliance scenario and what's the smallest mitigation?" Forces the conversation onto risk-proportionate design instead of belt-and-braces over-engineering.
3. "Where have similar projects in this firm got compliance wrong before?" Institutional memory you'd otherwise miss.

The phrases to listen for

• "We have to demonstrate" — there's a regulatory test you'll need to evidence.
• "The regulator will ask" — a real ask, not a theoretical one. Capture verbatim.
• "It's a six-week process" — a hard dependency on your timeline. Put it on the critical path now.
• "We've done it before" — there's an existing pattern. Get the documents.

Working with a Product Owner and Scrum Master

Most software BAs don't work alone — they work alongside a Product Owner and a Scrum Master in an agile team. Knowing where each role starts and stops is the difference between adding value and getting in the way. Good BAs learn to navigate these boundaries instinctively.

The three roles in one sentence each

The BA / PO boundary — where it gets blurry

The Business Analyst and Product Owner often overlap on story shaping. The right split:

Ceremonies — what you attend, what you skip

How to make a good first impression with the engineers

• Sit in on refinement before bringing any requirements. Learn how they think before you ask them to think differently.
• Ask the engineers what makes their job harder. They'll tell you everything you need to know about the product, the stakeholders, and the team in 30 minutes.
• Don't pretend to understand tech you don't. "I don't fully understand — explain it to me" earns respect. Bluffing loses it.
• Never say "can't you just…" — those three words destroy a BA's credibility faster than any other. There's always a reason it's harder than you think.
• Show up to demos with working software, not slides. Always.

Four mistakes new BAs in agile teams most often make

1. Writing big documents nobody reads. Replace the 20-page requirements doc with a refined backlog and a sequence of conversations.
2. Trying to do refinement alone. Refinement is a team sport — BA + PO + 2-3 engineers + QA. Solo refinement produces stories that fall apart.
3. Coming to demos with slides instead of working software. The team's done the hard part — let it speak for itself.
4. Believing "the requirements are signed off" means anything. In agile, requirements get refined every two weeks. Plan for that, don't fight it.

The question that separates senior BAs

When a sponsor introduces a project, they name the people they think about every day — their team, their peers, the people whose desks they walk past. The people they don't name are the ones who'll derail the project at month four. Good BAs ask "who's not in the room?" deliberately, in every kick-off, every workshop, every steering meeting. It's the single highest-leverage question in the discipline.

The four groups sponsors usually forget

• The end customer. You're designing for them and they're never in the room. Complaints data, customer panels, journey-mapping research, NPS verbatim — they have to feed in somehow or the design is guesswork.
• IT Operations / run-the-business teams. Not the build team — the people who'll get paged at 2am when production breaks. They almost never sit in early discovery sessions and they will block go-live if they've been ignored. Find them in week one and bring them in.
• Compliance · Risk · Legal · Audit. Sometimes only one of these is named; the others get a token tick at the end. In regulated industries (finance, health, gov) they need to be in shaping the requirements, not signing off the finished thing.
• People who lost the last fight. If a previous project was rejected, replaced, or quietly abandoned, the people who built it usually have institutional memory of why. They're often deliberately excluded because "we tried that already". They're the cheapest source of insight you have.

How to ask it without sounding accusatory

Sponsors don't react well to "you missed someone". Reframe it as a check on yourself:

• "I want to make sure I've got the picture right — who haven't you mentioned that I should still be aware of?"
• "If we got to month four and someone said 'why didn't you talk to X?', who is X most likely to be?"
• "Who's the person who, if we don't include them, this project quietly dies?"
• "Who runs the system in production once we hand it over?"
• "Where's the customer voice coming from on this?"

What to do once you've found them

Add them to the stakeholder grid (power × interest) within 48 hours. Put them on the comms plan with a cadence. Get the introduction email from the sponsor while it's fresh — sponsors forget within a week. Capture the conversation in HubNote and tag the theme (stakeholder management).

Waterfall · Agile · Hybrid — and how to pick

Methodology isn't a religion — it's a delivery decision. The same project run waterfall, agile, or hybrid will produce very different artefacts, conversations, and risks. BAs are expected to recognise which approach the project actually fits, even when the org has a default.

The three approaches at a glance

Which artefact does each methodology produce?

Your requirements documentation pattern is a function of your methodology — not the other way around. Picking the wrong artefact for the methodology is one of the most common BA mistakes.

Six-question decision framework

Ask yourself these about the project in front of you. The pattern of answers points to the right approach.

If you score 4+ "waterfall signals" your project is genuinely waterfall — don't fake-agile it. If 4+ "agile signals", commit to agile properly. If you're 3-3, you're a hybrid project; name it honestly.

Waterfall — done well, not as a punchline

Waterfall has a bad reputation it doesn't entirely deserve. When the domain is well-understood and the cost of change is genuinely high, sequential delivery with up-front requirements is the right answer. The reputation comes from waterfall being misapplied to software product work where it's the wrong fit.

The phases (and what the BA does in each)

The Specification Document — what's in it

The BRD or SRS is the central artefact. A well-structured spec includes:

• 1. Executive summary — what the system does, why, for whom.
• 2. Context & scope — in-scope and explicitly out-of-scope.
• 3. Stakeholders — full list with roles, sign-off responsibilities, RACI.
• 4. Business requirements — what the business needs the system to enable.
• 5. Functional requirements — what the system must do, in numbered list. Often with use cases.
• 6. Non-functional requirements — performance, security, availability, etc.
• 7. Data requirements — entities, attributes, retention, governance.
• 8. Constraints — regulatory, technical, organisational, contractual.
• 9. Assumptions & dependencies — what must be true / what else has to happen.
• 10. Acceptance criteria / sign-off — how we know it's done.
• 11. Glossary — for the love of all that's holy.
• Appendices — use cases, process maps, mockups, data flows.

The conversations that matter most in waterfall

• Workshops — multi-stakeholder, longer sessions, lots of upfront elicitation. The BA leads, captures everything.
• Stakeholder interviews — 1-1, deep dives. Used for nuance the workshop missed.
• Sign-off meetings — chase, chase, chase. A signed BRD that no one read is worse than no sign-off.
• Change Control Board (CCB) — when scope changes, this group decides. The BA brings the change request, the CCB decides yes / no / defer.

Agile — the principles, not just the ceremonies

Agile isn't a process — it's a set of principles about how to handle uncertainty. The Manifesto for Agile Software Development (2001) sets out four values. Most of what people call "agile" is a particular framework (Scrum, Kanban, SAFe) that puts those values into practice.

The four agile values (from the Manifesto)

• Individuals and interactions over processes and tools — people make software, not Jira tickets.
• Working software over comprehensive documentation — a thing that runs is worth more than a doc that describes a thing.
• Customer collaboration over contract negotiation — the customer is in the room, not at the end of a fax line.
• Responding to change over following a plan — the plan was your best guess at the start, not a contract.

The crucial line in the Manifesto: "While there is value in the items on the right, we value the items on the left more." It doesn't say documentation is bad — it says working software matters more than the documentation.

What changes about the BA's job in agile

The requirements artefact in agile — the product backlog

Instead of a single document, agile teams maintain a product backlog — a prioritised list of work, typically as user stories. The backlog is constantly refined and re-prioritised. The Product Owner owns priority; the BA brings the stakeholder context that informs it.

Key practices around the backlog:

• Definition of Ready (DoR) — agreed criteria a story must meet before entering a sprint. Typically: clear AC, dependencies known, sized, no open questions.
• Definition of Done (DoD) — agreed criteria a story must meet before being called complete. Typically: code reviewed, tested, deployed to staging, AC met, accessibility checked.
• Backlog refinement — weekly ceremony where the team grooms upcoming stories with the BA + PO.
• Story splitting — taking a too-big story and splitting it (by workflow step, data type, user role, happy path vs edge case).

Common myths about agile

Hybrid — the honest answer for most real projects

Most real-world projects aren't pure waterfall or pure agile. They have a regulated frame (waterfall) with iterative delivery inside it (agile). Saying "hybrid" out loud is often more credible than pretending it's one or the other.

What a hybrid looks like in practice

• Programme-level — stage gates at quarterly intervals. Steering committee. Budget tranches. Capability roadmap. (Waterfall-shaped.)
• Team-level — sprints, daily stand-ups, refinement, demos, retros. Backlog of stories. (Agile-shaped.)
• Requirements — a high-level capability spec OR PID at the programme level (signed off) AND user stories at the team level (continuously refined).
• Governance — change-control board for programme-level scope changes; PO-led re-prioritisation for story-level changes.

When hybrid is right

• Regulated industries (financial services, healthcare, public sector) — the regulator wants a spec; the team needs iterative delivery.
• Large programmes with multiple teams — programme-level coordination has to be more structured than story-level work.
• Fixed-deadline projects where scope can flex — the date is locked (waterfall), the scope flexes (agile).
• Organisations with mixed maturity — some teams are agile-fluent, others aren't. The hybrid frame works for both.

Where hybrid goes wrong

• Mini-waterfalls inside sprints. Two-week mini-spec-then-build cycles. Worst of both worlds.
• Documentation that contradicts itself. The PID says one thing; the stories say another. Maintain both — but keep them aligned.
• Mixed sign-off models confusing the team. Be explicit: who signs off what, at what level?

Scrum — the most common agile framework

Scrum is one of several agile frameworks. It's the most widely adopted because it's prescriptive enough to teach but light enough to scale. If a job description says "agile" without specifying further, it almost certainly means Scrum.

The three roles

Strictly speaking, "Business Analyst" isn't a Scrum role — the framework assumes the PO does the BA's job. In practice that doesn't scale; mid-size and large orgs have BAs alongside POs. See the BA/PO split.

The five events

Plus backlog refinement, which strictly isn't a Scrum event but every team runs it weekly. The BA's home ceremony.

The three artefacts

• Product Backlog — the prioritised list of everything that might be in the product. Owned by the PO.
• Sprint Backlog — what the team committed to this sprint. Owned by the team.
• Increment — working software, shippable, at end of every sprint. The thing that actually matters.

Where Scrum gets misapplied

• One-person "Scrum teams". Scrum is a team framework — needs at least 3-9 people.
• Hardware projects. Scrum assumes you can release working software every sprint. Hardware can't.
• Fixed-everything contracts. If scope, time, and cost are all locked, you can't have agile — Scrum's flex is the scope dimension.
• "Scrum-but" — "We do Scrum but skip retros / but have a fixed scope / but ship every six months". Three "buts" means you don't do Scrum.

Kanban — agile without sprints

Kanban is the other major agile framework. Where Scrum batches work into sprints, Kanban runs continuously — work flows when the team has capacity. Often the right answer for ops-heavy or support-heavy teams where unplanned work dominates.

The core practices

• Visualise the work — a board with columns for each stage (Backlog → In Progress → Review → Done).
• Limit Work In Progress (WIP) — only X items in each column at once. Forces focus. Stops scope creep at the team level.
• Manage flow — measure cycle time (story to done). Optimise for smooth flow, not for sprint-end heroics.
• Make policies explicit — what does "Done" mean for this column? Written on the board.
• Improve collaboratively — retro the system, not the people.

When Kanban fits better than Scrum

• Support / operations teams (Bug fixes don't fit sprints.)
• Marketing or content teams (Work types vary wildly in size.)
• Mature teams that find sprint planning overhead exceeds its value.
• Teams with mixed planned + unplanned work.

Where Kanban falls short

• New teams — sprints give cadence and predictability that Kanban doesn't enforce.
• Stakeholder expectations of regular demos — Kanban demos when work's ready, which is uneven.
• Teams that need external commitments — Scrum's sprint goal is easier to "sell" upstream than "we'll get to it when we get to it".

Lean — the parent of agile

Lean started in Toyota manufacturing in the 1950s — eliminate waste, deliver value continuously, respect the people doing the work. Most agile principles trace back to Lean. Lean Startup (Eric Ries, 2011) applies the same ideas to product development under uncertainty.

The five Lean principles

1. Define value from the customer's perspective.
2. Map the value stream — every step from start to finish.
3. Create flow — eliminate the queues and waits between steps.
4. Establish pull — work moves when the next step can take it.
5. Pursue perfection — continuous improvement, never finished.

The Lean Startup loop (Build → Measure → Learn)

For product BAs, this is the bit worth knowing:

• Build the smallest thing that lets you test your assumption (an MVP).
• Measure what happened when real customers used it. Quantitative metrics where possible.
• Learn what the result tells you about your hypothesis — and decide to pivot (change direction) or persevere (keep going).

Lean BA techniques worth borrowing

• Value Stream Mapping — map the entire flow of work, identify which steps add value and which are waste. Brilliant for process-improvement projects.
• Eight wastes (TIMWOODS — Transport, Inventory, Motion, Waiting, Over-production, Over-processing, Defects, Skills) — a checklist for finding inefficiency.
• A3 problem-solving — structured one-page problem statement.
• Genchi Genbutsu ("go and see") — don't theorise about the work, go and watch it being done. This is what Sandra's 2019 advice was about.