Overview
Business analyst resumes tend to be either too technical or too vague. The technical ones read like a developer's resume ("wrote SQL queries, used Jira"). The vague ones read like a list of meetings ("facilitated workshops, gathered requirements"). Neither tells the hiring manager what you actually delivered.
This resume belongs to Sophie Mercer, a BA with five years of experience. She currently works at AO.com on the warehouse management platform that handles 35,000+ daily orders. Before that, she delivered requirements for Co-op's online grocery platform and worked on NHS digital projects at BJSS.
What works here is that every bullet ties the BA work to a business outcome. She does not just "gather requirements." She gathers requirements that lead to a 34% reduction in returns processing time, or a same-day delivery launch across 200 stores. That is the difference between a weak BA resume and a strong one.
Summary: the bridge between business and technology
The best BA summaries explain what kind of work you do and what kind of systems you work on. Not "I am a business analyst." More like "I untangle messy processes and turn them into user stories for engineering teams."
Sophie's summary:
Business analyst with five years of experience gathering requirements, mapping processes, and bridging the gap between business stakeholders and technical teams. Currently at AO.com working on the warehouse management platform that handles 35,000+ orders per day.
She names the company, the platform, and the daily order volume. That immediately tells the hiring manager the scale she operates at. The "bridging the gap" phrase is slightly generic but earns its place because it is followed by something specific.
For yours: State your years of experience. Name the domain or system you work on. Give a scale number (users, orders, transactions). Then add one sentence about your working style if you have space.
Experience: requirements are not the deliverable. The outcome is.
The mistake most BAs make is writing about their process instead of their results. "Gathered requirements and documented user stories" is your method. It is not your achievement. What happened because of those requirements?
Sophie at AO.com:
Gathered and documented requirements for a warehouse management system migration, 180+ user stories across 12 epics over 6 months
Facilitated 40+ workshops with warehouse operations, finance, and engineering stakeholders to map as-is processes and define target state
Reduced delivery returns processing time by 34% through process redesign and system changes identified during requirements analysis
The first two bullets describe the work. The third one describes the outcome. That 34% reduction is what makes the hiring manager pay attention. Without it, the resume reads like process documentation. With it, the resume reads like delivered impact.
The formula: What you analysed + Who you worked with + What changed because of your work.
"Gathered requirements for a new feature" becomes "Wrote 120+ user stories for the launch of a same-day delivery feature across 200 Co-op stores." Context makes all the difference.
Consulting vs. in-house: different strengths to show
Sophie has both. Her BJSS role was client-facing consulting on NHS projects. Her Co-op and AO.com roles are in-house product work. These require different skills and the resume shows both.
From the BJSS consulting role:
Supported requirements for an NHS digital appointment booking system used by 14 GP practices in Greater Manchester
Produced wireframes in Figma for clinician-facing screens, iterated through 3 rounds of user testing with 8 GPs
Consulting BA work is about adapting to new domains quickly and working with unfamiliar stakeholders. In-house BA work is about deep domain knowledge and long-term system ownership. If you have done both, your resume should reflect the different skills each required.
If you are a consulting BA applying for an in-house role, emphasise the projects where you spent the most time embedded with one client. If you are in-house applying for consulting, highlight your ability to ramp up quickly on new domains.
Skills: tools and techniques matter equally
Sophie's skills section is split between techniques and tools. Techniques: requirements gathering, user story writing (Gherkin/BDD), process mapping (BPMN 2.0), impact mapping, story mapping, UAT planning. Tools: Figma, Jira, Confluence, SQL, Miro, Visio.
This balance is important. A BA who only lists tools looks like a Jira administrator. A BA who only lists techniques looks theoretical. You need both.
One standout: "SQL (Intermediate, Data Queries & Validation)." BAs who can write SQL have a real advantage. It means they can pull their own data, validate acceptance criteria against the database, and work more independently with technical teams. If you can write SQL, even at an intermediate level, include it.
Certifications: BCS and IIBA are the industry standards
Sophie holds the BCS International Diploma in Business Analysis, a CSPO (Certified Scrum Product Owner), and an IIBA ECBA. These are the three most recognised certifications for BAs in the UK.
The BCS diploma is the most widely requested in BA job adverts. If you have it, put it front and centre. If you are working towards it, list it as in progress. The IIBA ECBA is a good entry-level certification that shows you understand the BA body of knowledge. And the CSPO shows you can operate in agile environments and understand the product owner role, which is adjacent to (and sometimes overlaps with) the BA role.
Mistakes business analysts make on their resume
Describing the process, not the outcome. "Facilitated workshops and documented requirements" is your day-to-day activity, not your achievement. Always connect the requirements work to a business result: a launch, a cost reduction, a time saving, or a defect reduction.
Not quantifying the work. "Wrote user stories" is less useful than "wrote 180+ user stories across 12 epics." "Ran workshops" is less useful than "facilitated 40+ workshops with operations, finance, and engineering." Numbers show scale.
Leaving out domain knowledge. If you have spent three years working on logistics technology, that domain expertise is valuable to any company in logistics, retail, or supply chain. Name the domain explicitly in your summary.
Listing "Agile" as a skill without context. Every BA job ad mentions agile. Just writing "Agile" on your resume tells the reader nothing. Instead, say "Agile & Scrum Methodologies" or, better yet, describe your agile practice in your experience bullets: sprint planning, backlog refinement, retrospectives.
One more thing
BA roles vary enormously between companies. Some BAs are basically project managers. Some are technical writers. Some are de facto product owners. Your resume should make clear which type of BA you are by the language you use. If you write user stories and run sprint planning, use product-oriented language. If you map processes and run discovery workshops, use analysis-oriented language. If you write test plans and coordinate UAT, use quality-oriented language. Match the language to the role you are applying for, and the hiring manager will see the fit immediately.
