Business analyst roadmap: a six-month plan for beginners

How to use this roadmap

This roadmap is a learning order, not a course. It suits freshers, students and career changers who want to move towards a business analyst role and prefer a clear sequence to a pile of random tutorials. It follows the order in which business analysis work happens on a real project, so each month builds on the last.

We have planned it around six to eight focused hours a week, which is realistic alongside study or a full-time job. If you have more time, compress it; if you have less, stretch each month to six weeks. What matters is that every month ends with an output you could show someone: a document, a diagram, a query or a short write-up. By the end you have the start of a portfolio, not only notes.

Two honest points before you begin. First, no roadmap can promise a job; employers hire on evidence, interviews and fit. Second, most people reach a business analyst title through a related first role, such as support, operations, testing or a junior analyst post. Our guide on how to become a business analyst with no experience covers those routes, and this roadmap is the learning plan that sits alongside it.

Month 1: foundations and the BA mindset

Start by understanding what the job is and why it exists. Read what business analysis is and what a business analyst does, then learn the core vocabulary from the business analysis glossary: stakeholder, problem statement, scope and requirement.

The habit to build this month is separating the problem from the requested solution. When someone says "we need a new app", a business analyst asks what problem the app would solve and how we would know it worked.

Output for month 1: pick an everyday process you know well, such as booking a doctor's appointment or returning an online order. Write a one-page problem statement and a list of the stakeholders involved, with what each one needs.

Month 2: requirements, user stories and stakeholders

Requirements are the heart of the role. Learn how to gather them with elicitation techniques such as interviews, workshops and observation, and how to analyse stakeholders with a stakeholder map and RACI matrix.

Then practise writing. Learn how to write user stories, add acceptance criteria with Given, When, Then examples, and understand when a team uses a BRD, FRD or SRS instead (see BRD vs FRD vs SRS).

Output for month 2: for your month 1 process, write five user stories with acceptance criteria and one short requirements page. Ask a friend to read a story and tell you what they would build. Where they guess, your story needs another example.

Month 3: process modelling and data basics

This month adds two skills that make an analyst far more credible. First, process modelling: learn the basic shapes from BPMN for beginners and compare the current and future way of working with AS-IS and TO-BE analysis. A gap analysis then lists what has to change.

Second, data. Learn enough SQL to read a table, filter rows, join two tables and count by group. Our SQL for business analysts guide and the free SQL practice exercise are designed for this stage.

Output for month 3: an as-is and a to-be swimlane diagram for your process, plus three SQL queries on a small invented dataset that answer a business question, each with one sentence explaining what the result means.

Month 4: delivery, testing and the everyday tools

Now learn how requirements turn into working software and how teams check it. Read how business analysts work in agile teams with a product owner, then learn the tools most teams use: a ticket tracker such as Jira and a wiki such as Confluence. The business analyst tools guide puts these in context.

Testing is where analysts prove that what was built matches what was needed. Learn user acceptance testing and how a requirements traceability matrix links each requirement to its tests.

Output for month 4: a small board with your user stories, two invented bugs written clearly, and a traceability table linking each story to at least one UAT test case.

Month 5: a domain, KPIs and dashboards

Generalists struggle to stand out. Choose one domain that interests you or that matches your background, such as banking, insurance, e-commerce, healthcare or logistics, and learn its main processes and vocabulary. Our guide to domain knowledge for business analysts suggests where to start for seven industries.

In the same month, learn how organisations measure success. Understand the difference between a KPI and a metric with our dashboard design guide, and learn enough Power BI or a similar tool to build a simple dashboard from a clear definition.

Output for month 5: a one-page domain summary (key processes, terms and rules) and a dashboard specification for your process: three KPIs with their exact calculations, data sources and the decision each one supports.

Month 6: portfolio, CV and interview practice

Turn five months of outputs into evidence. Combine the best pieces into one or two portfolio case studies, following our guide to a business analyst portfolio without experience. Label practice work honestly as practice; employers respect that far more than vague claims.

Update your CV and LinkedIn profile to describe what you did and what you learned, using the same honest language. Then practise interviews out loud with our interview questions and model answers and the free interview preparation guide. Our salary and career path guide explains how to read salary data and offers when you get that far.

Apply steadily rather than in one burst. A small number of tailored applications, each matched to the verbs in the advert and backed by one relevant example from your portfolio, usually works better than a hundred identical ones. Keep a simple tracker of where you applied, what they asked for and what you learned from each conversation, and treat every interview as practice that improves the next one. If you already work in a company with analysts, ask to shadow one for a day or help with a small piece of their work; internal moves are one of the most common routes into the role.

Output for month 6: a portfolio with one or two case studies, an updated CV, and recorded answers to ten common interview questions that you have reviewed and improved.

Checkpoints: are you on track?

At the end of each month, ask yourself these questions. If the answer is no, spend another week on that month before moving on.

• Can I explain this month's topic to a friend in two minutes, in plain English?
• Did I produce the output, and would I be comfortable showing it to an interviewer?
• Did I use at least one real or realistic example, not only definitions?
• Can I name one mistake I made and what I changed afterwards?

If you are a student in India, line the plan up with your placement calendar: aim to finish months one to four before applications open, so you can talk about real outputs in your first interviews. If you are changing careers, start month five early with the domain you already know; it is your biggest advantage. And if you want structured practice with feedback, the BA Lab follows the same order on a simulated company project.

Common mistakes on the way

• Collecting courses instead of producing outputs. Watching videos feels productive, but employers need to see what you can do.
• Starting with a certification. Certifications can help later, but they are not a substitute for practice. See our certification guide for an honest view of when they fit.
• Skipping data. Many beginners avoid SQL. A small amount of SQL sets you apart quickly.
• Trying every tool. Learn one tool per category well enough to use it, then move on.
• Working alone. Ask friends, colleagues or online communities to review your stories and diagrams. Feedback is where most of the learning happens.

Frequently asked questions