Every list of business analyst portfolio projects tells you to analyse a public dataset, redesign a checkout, or write requirements for an imaginary app. Then it stops, because the person writing it has never had to sit opposite an interviewer and defend one.
Here is what a portfolio project is actually for, and what to build.
What the portfolio is really for
It is not proof that you can do the job. Nobody believes a practice project proves that, and you should not claim it does.
It is something to answer from.
Every business analyst interview question assumes you have a project in your head. Walk me through a requirement you wrote. Tell me about a stakeholder who wanted something you disagreed with. How did you know the requirement was finished. A career changer with no project answers those questions in the abstract, and abstract answers sound like reading.
The project’s job is to turn “I would gather requirements from stakeholders” into “on this story, the contact centre wanted free text and I gave them a fixed list, and here is what that bought us three sprints later.”
The four mistakes
- Too big. A twelve epic imaginary enterprise programme. Nobody will read it and you will not remember it under pressure.
- Too tidy. Every sprint hitting exactly one hundred percent. Nobody who has worked on a delivery believes that board, and it tells the interviewer you have never seen one.
- No artefacts. A written case study with no board behind it. The board is the thing you screen share.
- Dishonest framing. Listing it under employment, giving it a company name, attaching a result. That is the one that ends interviews rather than just losing them.
What to build instead
One project. One domain you understand. Small enough to hold in your head.
Here is the specification I would give anyone starting from nothing.
- Four epics. Enough to show you can group work. Not so many that you lose the thread.
- Twelve user stories. Each one with acceptance criteria in Given, When, Then form, covering the unhappy path and not just the happy one.
- Three sprints. Long enough to produce a velocity chart, which is the artefact interviewers actually recognise.
- One thing that went wrong. Documented, with dates, with a cost, and with what changed afterwards.
- A sprint that misses. Deliberately. See below.
The detail that makes it believable
Make one sprint miss, and make the reason boring.
Not a heroic technical problem. A decision nobody made. A vendor who could not confirm a date. Two departments using different rules and neither knowing. That is what actually stops delivery work, and an interviewer who has lived it will recognise it in the first sentence.
Then be able to say what you did on day two, day five and day eight. Not “I escalated it”. What you asked for, who you asked, what it cost when the answer did not come, and what the retrospective changed.
That single story is worth more than the other eleven put together.
Write the acceptance criteria properly, because that is the actual test
This is where business analyst candidates separate. Most write the happy path and stop.
Take a story like “the customer chooses a reason for their return from a list”. The happy path takes ten minutes. The work is in the rest:
- What happens when the reason is Faulty and you need a free text note that the other reasons do not require
- What happens to reporting three sprints later if the reason is free text rather than a fixed value
- What happens when the discount was applied across the whole order rather than the item being returned
- What happens when the system the story depends on is unavailable mid-transaction
If you cannot name at least two ways a story goes wrong, you have not finished writing it. That sentence, said in an interview, does more for you than a certificate.
Put it in Jira, not in a document
A Word document of requirements is a document. A Jira board with three closed sprints, a velocity chart and a burndown is an artefact you can screen share while you talk.
The free Jira plan covers all of it. Create a Scrum project, put the stories in, run the sprints, close them in order. Closing them matters, because Jira will not draw a velocity chart for a sprint that is still open.
Then actually move the cards around and comment on them. A board that was imported and never touched looks exactly like a board that was imported and never touched.
How to put it on your CV without lying
There is one correct format and several wrong ones.
Correct: a Projects section, above employment, with the words practice project and simulated on the line itself. No company name. No job title. No claimed business outcome.
Wrong, in increasing order of damage: leaving out the word practice and hoping; giving yourself a title you never held; listing it under Employment with a company name that does not exist. The last one is a fabricated employment record.
And say it out loud in the interview, once, early, calmly: this is a simulated delivery I built to work through a full cycle end to end. It feels like it will sink you. It does the opposite, because almost nobody volunteers the limits of their own evidence.
How long it takes
Building the board from scratch is a weekend if you know what you are doing and considerably longer if you do not, mostly because writing twelve sets of acceptance criteria that survive scrutiny is harder than it looks.
Running the sprints afterwards is a few sittings. That part you should not skip, because the velocity chart is the artefact and it only exists once the sprints are closed.
If you would rather not build the board from scratch
The Portfolio Project Kit is a complete agile delivery project you import into your own Jira in one click. Four epics, twelve user stories, one impediment, three sprints, 56 story points, with full Given, When, Then acceptance criteria already written. Every story is labelled by the role it demonstrates, so one board gives you four different interviews.
It is a practice project and you say so every time you present it. See the Portfolio Project Kit, $49
Not sure which of the four you are aiming at?
The Role Fit Diagnostic is sixteen statements. You tick the ones that are true of you now, count your ticks by letter, and read the page for whichever role you already work like. Ten pages, printable, free, about six minutes.