Business Analyst Portfolio: The Six Artifacts I Look For

What a business analyst portfolio actually is, the six documents I look for when one lands on my desk in review, and the objections two reviewers raised.

You finished the course. Maybe you passed ECBA as well, and the certificate is sitting in your downloads folder under a filename you did not choose. Your CV says trained in business analysis, familiar with BPMN, BABOK aligned.

Then an application form asks for a link to your portfolio, and you look at what you actually have. Lecture notes. A completion badge. A folder of slide decks somebody else made.

A business analyst portfolio is a small set of documents, built on a case you are free to publish, that shows how you turned an ambiguous problem into something a team could act on. It is a work sample, not a record of what you were taught.

I run a business analysis training platform in Polish, with paying members, and some version of that message keeps arriving. The wording changes, the shape does not: I know the concepts, I cannot show the work.

I am not a recruiter and I have never run a hiring process, so I am not going to tell you what happens on the other side of the desk. What I do is write these documents on international projects, take other people's apart in review and have mine taken apart in return. So here is the narrower question I can answer. When a document lands on my desk and I have twenty minutes, what makes me believe the person who wrote it knows what they are doing?

In short

• One case taken far enough beats six half-finished ones, and the six artifacts that carry it are a stakeholder map, an as-is and to-be process, a requirements register with acceptance criteria, one business rule with its rationale, a review log and a one-page summary.
• Build the case on sources you are free to publish: a published returns policy, help centre articles, public complaint threads and your own attempt to use the process as a customer.
• Label what you cannot know from outside, because four of ten complaint threads I picked myself is a count with a method attached, while calling it 40% is the fastest way to lose the reader you were trying to impress.
• The review log is the artifact I read first, since a clean final draft is cheap and a document with the objections still visible in it is not.

Why is a BA portfolio harder to build than a designer's?

A designer shows the screen. A developer shows the repository. We write documents about somebody else's business, and most of them are the sort of thing you cannot show.

The last requirements pack I am proud of has a client name in it, transaction volumes, an internal cost figure and three screenshots of a system that is not public. None of that is mine to publish, and removing the names does not fix it. If a reader recognises the process, your best work sample turns into a reason not to hire you. It takes one reader who was on the other side of that project. The document can be good; that is not the problem.

So: you will not build a portfolio out of your paid work, and if you are new to the field you have no paid work anyway.

Build your own case on public sources instead.

Pick a process you can watch from the outside, as a customer, where the failures are visible and the rules are published somewhere. I use returns and refunds at a mid-size online retailer. Appointment booking at a clinic works. So does airline rebooking after a cancelled flight.

Then collect facts instead of inventing them.

Note the right-hand column. It is the more useful half and the half people skip. Write every gap down as an open question with an owner and a date. A case built this way is yours, it is publishable, and you can defend every decision in it.

Six artifacts turn that case into evidence somebody else can judge. Six, from one case, taken far enough that the seams show.

1. The stakeholder map

What it is. One page naming everyone who can approve, block or quietly sabotage the change, and what each of them stands to gain or lose.

What it tells me. Whether you have been in a room or only read about rooms. Anyone can list roles. Very few people write down who holds the decision right.

Bad version. The org chart with twelve boxes and job titles, or an influence grid with names in quadrants and no explanation of how they got there.

Good version. Every row carries a decision right and a piece of evidence. Not "Finance, interested", but "Whoever signs off refund policy in Finance: holds the decision right over the partial refund threshold. Evidence: the 40 EUR threshold appears in the published policy and in two help centre articles, always worded as a hard rule. No public source names the person, so the row stays open rather than being filled in with a plausible title."

In my returns case the row worth arguing about is the warehouse, not customer care. Somebody there has to physically receive the item that comes back, and nothing in the published policy suggests that person gets a say when the refund window is shortened. The row is an inference from how the process has to work, and the map says so on its face.

Time. Sixty to ninety minutes, once I have done the reading.

The one mistake. Listing who gains and leaving out who pays. The rows that matter are the ones where somebody stands to lose something when this succeeds.

2. The as-is and to-be process

What it is. Two models of the same process. How it runs today, and how you propose it should run.

What it tells me. Whether you can hold a system in your head and change one part of it on purpose.

Bad version. An as-is with no failure anywhere in it, followed by a to-be that changes everything and fixes everything. A model of the current state where nothing ever goes wrong is the first thing a reviewer goes after, and mine did.

Good version. The as-is shows where work stops. In my case there is a branch where nobody owns the outcome: the evidence is incomplete, the case is parked, and from there the customer has to chase it.

I wanted a number for how often that happens. Public sources will not give me one. Four of the first ten complaint threads I read ended there, which is a count of ten threads I picked myself and not a rate, so the model says exactly that on its face: parked branch, frequency unknown, flagged for measurement. Turning that into "40% of cases" would have been the easiest thing in the document for a reviewer to catch.

The to-be then changes as little as possible. Evidence is collected before a human sees the case, and the parked branch gets a named owner and a clock. The branch still exists in the to-be. Pretending it will not is how you lose the first review.

Use BPMN if you know it, plain boxes if you do not. Consistency beats notation purity, and a reviewer who cares more about your gateway symbols than your exception path is telling you something about the team.

Time. Three to four hours for a process this size, including one full redraw. There is always one full redraw.

The one mistake. Modelling what should happen instead of what does.

3. The requirements register with acceptance criteria

What it is. The numbered list of what the solution must do, each item written so it can be tested and traced back to a rule or a stakeholder need.

What it tells me. Most of what the job actually is.

Here is a row from the returns case, as it sits in the register after review.

REQ-014 - Refund on damaged delivery

Acceptance criteria:

1. Photo upload accepts up to 3 files, 10 MB each. A fourth file is rejected with a message that names the limit.
2. A refund decision is recorded within 48 hours of form submission. If it is not, the case escalates automatically to a named owner.
3. Partial refunds are permitted only when order value is above 40 EUR. At or below 40 EUR the refund is full or refused, never partial.

Open questions on this row: OQ-04, whether the duty rota covers weekends given a 48 clock hour window, and OQ-05, whether partial refunds ship in release 1. Both sit with the Head of Customer Care, each with a date and a fallback. The retention question lives one requirement further on, as OQ-01 against REQ-016: 90 days proposed, to be checked against the statutory limits, owner legal, due before build starts, and if it is not confirmed by then, photos default to the shortest defensible period and the decision goes up.

Bad version. "The system should handle refunds correctly and in a user friendly way." Three criteria that restate the requirement in different words. Anything containing "as appropriate", "if needed" or "etc".

Good version. Criteria a tester can run without asking what you meant, and every number traceable to somewhere you can name.

Time. Three to four hours for five requirements written this way. Most of that is not writing. Five, not fifteen: the case this row comes from carries five, and the register says on its own face that five must-haves in one release is a smell.

The one mistake. If someone has to phone you to know whether the criterion passed, it is a note, not a criterion.

4. The business rule with its rationale

What it is. A single rule, stated precisely, with the reason behind it and the person who owns it.

What it tells me. Whether you chase the why or settle for the what. Rules outlive the people who set them. I have sat in a workshop where a threshold nobody could explain survived the redesign, because changing it felt riskier than keeping it.

Bad version. "BR-11: partial refunds above 40 EUR only." Rule, no reason, no owner. It reads like a law of physics.

Good version.

BR-11 - Partial refund threshold. Partial refunds are permitted only above 40 EUR order value.

Established. The 40 EUR figure and its wording as a hard rule, from the published policy and two help centre articles.

Inferred, not confirmed. The rationale. Below 40 EUR, the handling cost of a split refund plausibly exceeds the amount recovered. I have no cost data. Flagged for the rule owner to confirm or kill.

Owner. Whoever signs off refund policy in finance. I could not name a person from public sources, so the row is open rather than blank.

Review trigger. A change in the payment provider's per-transaction fee.

Marking your own inference as an inference is not weakness. It is the difference between an analyst and someone who fills the gaps with confident guesses.

Time. Twenty to thirty minutes per rule, most of it spent chasing the why.

The one mistake. Accepting "that is our policy" as a rationale and writing it down as though it were one.

5. The review log

What it is. A short record of what a reviewer objected to, what you changed, and what you deliberately did not change.

What it tells me. More than the finished document does. Polished final drafts are cheap. A document with visible scars from a real argument is not, and it is the artifact I read first.

Bad version. No log, only the clean final draft. Or a log that records the objection and stops, so I cannot tell whether you agreed, disagreed or panicked.

Good version. Three to six entries, each one line of objection and two lines of consequence. At least one where you held your ground and said why.

Time. Thirty minutes after the review. The review itself costs you one favour from someone competent.

The one mistake. Publishing only the version that makes you look good. Hiding the objections hides the only proof that you can take feedback without collapsing.

6. The one-page summary for a decision maker

What it is. One page, written last, read first, addressed to the person who has to say yes or no.

What it tells me. Whether you can compress. I read plenty of forty-page documents and very few good one-page ones, and the one-pager is the harder of the two.

Bad version. "This document describes the current returns process and proposes improvements." That sentence asks for nothing and tells nobody anything.

Good version. The decision requested, in the first line. Two or three options, each with cost, risk and effect. A recommendation with your name against it. What happens if we do nothing. Decision owner and decision date.

For the returns case the first line reads: "Decision requested. Approve automatic escalation of undecided refund cases after 48 hours, with a named owner per case, and a self-service form that collects photographic evidence before a person sees the case. Cost: one process change and a queue configuration. Effect: cases that currently stall get an owner and a deadline. How many stall cannot be answered from outside the company, and it is the first thing I would measure."

Time. Forty-five to sixty minutes, plus two rewrites, because the first draft is always half a page too long and one degree too polite.

The one mistake. If your page has no decision, no owner and no date, it is a covering note.

What did the reviewers actually object to?

I gave the case to two people and asked for the objections rather than the compliment. A developer on the delivery side, who reads process models before registers and has spent years being handed requirements that come apart in build. A business analyst who reviews requirements documents for a living. Two sessions, five objections. Four changed the case. One I accepted only in part, and the disagreement is written down instead of quietly dropped. Neither of them works at the retailer, and nobody there was asked about anything, at any point.

"Your as-is is the happy path, so your to-be looks better than it is." The first version of the as-is ran call, evidence, decision, refund, and stopped. It took about forty seconds to spot. If the as-is only shows the path where things go well, every benefit claimed for the to-be is unearned. The parked branch went into the model with no owner, no clock and its frequency marked unknown, and two further pieces fell out of it that had not existed before: an escalation requirement and the rule behind it.

"Under 48 hours from what moment?" The first draft said "within 48 hours" and never named the start event. Two readings both fit the sentence: one counts from the moment the customer presses submit, the other from the moment an agent opens the case. Between those two readings sits most of a working day. The clock is now anchored to the timestamp on the submitted form, in the criterion rather than in a note underneath it. Anchoring it immediately exposed a second decision the vague version had been hiding, clock hours against working hours, which is now an open question with an owner.

"Four in ten is a count, not a rate." An early draft said four in ten damaged-delivery cases end without an owner. I had ten complaint threads I selected myself, four of which ended that way, and I had turned that into a statement about all cases, two pages after my own source table said complaint threads are not a representative sample. Accepted on labelling: every use of the figure now names the denominator, the selection method and the date. Held on the number, and this is the one I did not fully accept. The stronger version of the objection was to cut the figure and say only that the branch exists. A labelled count with a stated method can be rechecked in twenty minutes; a shrug tells the reader less. The disagreement stands in the log, which is where a future reader should find it.

"A customer whose parcel never arrived has nothing to photograph." The to-be routes everything through a form built around photographic evidence. Somebody whose parcel was stolen or lost has no photograph, and on the phone they at least got a person who could improvise. The change quietly made one group worse off, and it was the group least able to argue about it. Non-delivery and lost parcels are now out of scope, with a reason and an owner. Deliberately not as a fourth acceptance criterion: an exception you exclude on purpose is a scope decision and belongs where a reviewer will find it.

"Why 40 EUR? Who set that?" The threshold was published but nothing public said who set it or why. Chasing the reason produced a rule with a page of its own: the figure and its wording as established, the rationale written down and labelled as my inference because I have no cost data, the owner slot left open rather than filled in with a plausible title, and a review trigger naming the input most likely to move it. The number itself did not change. It is published policy and I cannot improve on it from outside the company. What I could fix was the silence around it.

Not one of the five is about writing style. All five are about whether somebody can act on the document without me in the room. That is the standard.

How do you lay out a portfolio so it survives a skim?

Nobody reads a portfolio the way you wrote it. Assume a skim until something makes the reader stop.

One URL, not a zip file. A single page with the six artifacts on it, or one PDF. I close anything that needs downloading, unpacking or a login, and I doubt I am unusual.

Say what this is in the first two lines. "A self-directed case study on returns handling at a mid-size online retailer, built from public sources. Not client work." That sentence protects you and buys you trust at the same time.

Order for the reader, not for the process. One-page summary first, review log second, then the register, the models, the stakeholder map, the rules. Judgement at the top, diligence underneath, all of it still there for anyone who wants it.

Two sentences of context above each artifact. What the problem was, and one thing you would do differently now. That second sentence is worth more than the artifact under it.

Cut anything you cannot defend for five minutes. Every extra document is another surface for a question you cannot answer.

The blank templates for all six artifacts, plus the worked returns case in full, are on the downloads page. The scorecard is there too: twenty-five checks across the six artifacts, so you can be unkind to your own work before anybody else gets the chance.

What can you build this weekend?

Not all six. One.

Saturday morning, take something that went wrong for you as a customer in the last month. A return that took three weeks. A booking that made you phone somebody.

Write one requirement from it, in the format above, with three acceptance criteria and the business rule it traces to. Give yourself ninety minutes and stop when the time is up.

Then send it to one person who will tell you it is wrong, and write down what they said.

It is not a portfolio yet. It is the first thing you have made that somebody could read and form an opinion about, which is more than the certificate can do.

Your certificate says you learned. This is how you prove you can.

All field notes · The 25-check scorecard · More in The Case File