r/businessanalysis

I'm continuing my battle within my IT team to write good-quality user stories.

Some of my challenges:

1. Until recently, we had Business Analysts and Systems Analysts as two distinct roles. Each side has a take on what a proper user story is.
2. We really write use cases more than we write user stories.
3. Our stories are often 8+ (sometimes easily 12-16) ACs written in the Given/When/Format and we also add in Dev notes and QM notes into some of the ACs.
4. We also have long technical specs in our stories as well.
5. DEV/QAs have told us they don't read our stories.
6. We are allergic to breaking down stories, so we make them crazy long.
7. We have no definition of a "good" story, so we use length or "that story is too detailed, so it's not good" as a measure of a good story.

An opportunity has arisen to review how we write user stories, but my team keeps trying to define "good" primarily by point #7.

So, if anyone has come across this challenge of trying to change people's minds on stories and has any feedback, let me know.

I'm aware there is no one-size-fits-all solution, but I also feel like ignoring industry and best practices, like we're doing right now, is not the way to go.

Pretty much the title. What are the different types of Business Analyst roles, and how do they differ like for example the Technical BA, Product BA, Domain BA, Functional Consultant

I have around 10 years of IT experience mostly in IT Ops and I’m trying to understand whether Business Analyst roles are actually domain-specific, or whether some BA tracks are portable across industries.

Looking to transition myself into BA so trying to understand where would I best fit in

Hey everyone,

I have been thinking a lot about method selection in business analysis. In practice, the challenge often does not feel like a lack of methods. There are requirements workshops, stakeholder maps, process models, journey maps, root cause analysis, decision matrices, assumption mapping, risk workshops, prioritization frameworks and many other approaches.

The harder question for me is: which method fits this specific situation?

I know this from architecture, product and analysis work. You start with an unclear problem, conflicting stakeholder statements, a scope that is too broad, a missing decision basis or a process that everyone describes differently. Of course, you can start with conversations, notes and documentation. Sometimes that is enough. Sometimes a more structured approach would be much more productive if it was available at the right moment.

I am currently building my own kind of method catalog for this, mainly to structure these choices better. What I notice is that the interesting BA question is not only the individual method. The interesting part is the heuristic behind it: how do you recognize whether you are dealing with a requirements problem, an alignment problem, a scope problem, a process problem, a decision problem or a stakeholder conflict problem?

I would be curious how you handle this in practice:

• Do you choose methods consciously, or does it mostly come from experience and habit?
• Which situations almost always need a structured method in your work?
• Which method do you use more often than outsiders would expect?
• Would you search by problem type, artifact, project phase, stakeholder situation or desired outcome?
• Are there methods that are overrated or underrated in BA contexts?

I am not looking for a method collection here. I am trying to understand the decision logic behind it: how experienced BAs move from a vague work situation to a useful way of approaching it.

Best,
Micha

Hello guys,

I'm a Junior BA at an IT consulting firm but haven't actually worked a real BA project yet. Now they're telling me there's no BA work available and want to shift me into a Deployment/Implementation Consultant role instead (travel tech, GDS, configuring booking tools for clients incl. deployment checklists, testing, client-facing troubleshooting).

There's some overlap with BA skills like client interaction and document analysis (e.g which business rules the tool should have implemented), and cross-team coordination) but it's clearly more hands-on execution than analysis.

Since I have zero BA experience to fall back on, I don't know if I should take this as a way to build relevant experience while I wait, or push back for an actual BA assignment. Another option would be changing the company. But I want to last at least one year till switching.

What do you think? Will it help or hurt your path to becoming a "real" BA? Maybe someone here with Implementation experience who pivoted later to BA?

Hi, I have about 2and half years of experience as a supply chain analyst at a big e commerce firm and I have been thinking of getting into BA side, currently i use excel, sql, python(mostly claude), tableau, AWS and BI on a day to day basis. What would you recommend for me to improve my skillset on? I know it takes a lot of communication and understanding customers and stakeholders, I’m usually more of an introvert but I’ve been working on my communication skills. Any kind of advice would be much appreciated, I’m hoping to move into next job as a BA by January 27’ hopefully.

I have an interview coming up for juspay PSE. Can anyone tell me about the process, what do they ask, is DSA get asked? What topics to focus on?

Thanks in advance!

I joined earlier today and then all of a sudden it said I wasn’t joined anymore? So I joined again and now whenever I scroll down this subreddit or exit out of it, I’m not joined anymore??

I don’t know if it’s a bug or if the mods think I’m spam but I promise I’m just a Information Systems student who wants to learn more about business analysis 😭 please let me join 🙏

Hi All,

I have been a Business Analyst for the past 10 years. I am thinking off pivoting to try something else. I was wondering, what do you all reckon would be a sensible pivot? I don't like project management or delivery management btw lol. Keen to hear from anyone that has pivoted before.

Regards,

Rob

Hey everyone,

​I’ve been working as a Business Analyst at a startup for the past year. Because it’s a startup, I’ve handled a bit of everything, but I’m looking to plan my next career pivot.

​A lot of people are suggesting I look into Product Analyst roles. For those who have made this transition: Is it worth it? What does the day-to-day difference actually look like compared to a traditional BA, and what are the main benefits (pay, career growth, culture)?

​Also, if I don't go the Product Analyst route, what other roles should I be looking at given my 1-year startup BA background? I want to make sure I’m setting myself up for strong long-term future growth.

​Appreciate any advice or experiences you can share!

Some context.

Me: I've been doing BA work since 2006 and became a BA contractor/consultant in 2012.

My Market: I've spent my entire career doing BA work in the Greater Toronto Area for every type of company/sector imaginable (Public, Private, Nuclear Energy, Insurance, Investment Management, Education, Government Services, etc...).

My Specialty: Instead of specializing in a domain or system, like most BAs, I decided to choose "large scale projects/programs" as my "specialty".

My Current Gig: I've been brought in pre-project to help the Chief HR Officer and her leadership prepare for their upcoming HCM implementation. This is a pre-project Discovery & Solutioning engagement where I use what the BABOK would call "strategic analysis" (That is not what I call it in my own consulting practice)

EDIT: I'll be responding to comments/questions for the next 48 hours (ending on Thursday at lunchtime, Toronto time).

Disclosure: I am kind of all over the place.

I have an associates in mathematics, and this December, I graduate with my B.A. in Statistics with an emphasis in actuarial science. I went with the actuarial track because at my community college, I did an intro to statistics class and I really loved it. I was very good at it and my instructor actually had a char and encouraged me to be an actuary and I didn't know what else I would want to do. I transferred to a university around family out of state and did that track as I had no other idea what I want to do.

I did the sequence (3 classes), and quite frankly, I have no interest in that field nor do I have any interest in healthcare for anything, that's a different matter but part of it is because of ethical implications. I've taken all of my hardest classes and I am literally almost done! However my overall GPA is only a 3.51 but I do wanna bring it up as much as possible and finish my last semester, fall, strong! I also took up to Spanish IV and will take an advanced Spanish class, and perhaps even add one business Spanish class if it can fit in my schedule.

Currently, I have 6 years of retail experience at King Soopers as a cashier starting from courtesy clerk, and I have been taking what is called an educational leave of absence multiple times to keep my seniority and working there every single summer. When I graduate, if I can't get a better job, I plan to work for a year and live with my parents; I have made a budget to pay back all my student loans in less than a year. One other perk about the company is that they have something called 'Feed Your Future' which would cover the cost (except like $300 a year as it caps at $3500 but that is marginal and well worth it) and would cover a business analytics certificate. My store manager would let me be a customer relations manager when I graduate or do management if there is an opening once I graduate, I have asked. I will say I have grown sick and tired of retail, but this would make it worth it.

Specifically, I am interested in UCSD's business intelligence analysis certificate for a couple of reasons: one being that a dream job of mine is there in San Diego, and they have rejected my application. It was a risk analyst for a solar company and I was really excited once I applied and I sure did hope and pray for it. Another reason is that it is one of the best certificates in the country for it and it contains many skills such as SQL, R, and Python. My programming skills are a bit weak I confess. I have done one SQL class, some exposure to excel, and a tad bit of R, but I think it would also help me improve that. I wouldn't mind being a business analyst or a risk analyst for other industries including retail, although solar and renewable energy is something that captivates me for some reason. I have always been interested in large companies and how they operate/perform though.

Hi everyone,

I could really use some advice from seniors and experiences BAs.

I recently accepted a position as an IT Business Analyst at an insurance company, where I'll be working on fraud, KYC, and AML digitisation and automation initiatives.

I'm genuinely excited about the opportunity.

For some background, I graduated from university about a year ago (Jan 2025) and started working at an IT consulting firm on a project for a public-sector organisation as a Junior BA. Unfortunately, it's been a difficult first experience. The company went through an acquisition, onboarding and learning opportunities were limited, and I've often felt like I've had to figure things out on my own. On top of that, I found the public-sector environment to be very slow, process-heavy, and extremely bureaucratic.

One of the concerns I raised during my interviews was that I wanted to work in a more agile environment. The insurance company reassured me that, while they still have governance and regulations to follow, projects generally move faster and teams are able to make progress more efficiently (my new director has worked in public institutions before so he knew what I was referring to).

That said, I still feel like a complete beginner. My current role hasn't given me the foundation I hoped for, and over the past year my motivation has taken a hit. I don't want that experience to define me, though. I'm motivated to learn, improve, and do well in this new role. I want to make that boss proud because apparently he rejected other more experienced BAs for me as he enjoyed our discussion and the ideas I was putting on the table (I worked as an AML/KYC agent at a bank during university).

I have about three weeks before I start, and I've been using the time to read books on IT automation, digitisation, and business analysis to build my knowledge before day one.

For those of you with experience as Business Analysts, particularly in insurance, fraud, KYC, AML, or automation: what habits, skills, or resources would you recommend to help me become someone my team can genuinely rely on? I'd love to hear what made the biggest difference in your own career, especially early on.

Thanks in advance for any advice!

Genuine question for the BAs here who present to senior committees regularly, because I keep going back and forth and want to know how others have actually landed.

I've spent the last few weeks pulling together findings on a process that's been quietly bleeding money. It's data-heavy. Cycle times across four regions, cost-per-transaction trends, a correlation between one handoff and most of the rework. The analysis is solid. The question is the format for the findings presentation to the steering committee next week.

Option one is a live dashboard. Filterable, drill-down, they can poke at the regions themselves. It's honest, it's the real data, and it shows the depth of the work.

Option two is a static slide deck. I pick the cuts that matter, build the story, and the committee sees exactly what I want them to see in the order I want them to see it.

I've been burned both ways. Last year I brought a dashboard to a committee and lost the room inside five minutes. One director started filtering to his own region, ignored my actual finding, and the meeting became about his pet number instead of the decision I needed. The interactivity worked against me. But I've also built tidy decks that got dismissed as "too cooked," like I'd cherry-picked the slides, and they didn't trust it.

Where I'm leaning now is a deck for the story with the dashboard open in a tab as backup if someone challenges a number. But that feels like a hedge.

So for people who present data-heavy findings to steering committees: dashboard, slides, or some combination? When does interactivity help you and when does it hand the room to whoever wants to derail it?

Hi, need advice on how to pivot from development to business analysis.

My partner was a web and software developer and now it looking to make a pivot to business analysis. He has NET stack and really solid SQL skills. He worked as a dev for 7 years. Prior to that he worked 4 years as a k-12 educator. He has excellent organization, communication, documentation skills and can translate complex technical concepts into everyday language.

In a past role he worked on gathering requirements, designing solutions, coding them out, then presenting them to stakeholders, so already had experience with BA type job functions.

The resume looks strong but he's having a hell of a time getting callbacks or follow up interviews. He's gotten 2 screeners in as many months.

What are steps he can take to make himself a stronger candidate? Any and all advice would be greatly appreciated. TIA!!

I do a lot of work where a 50-plus page BRD already exists and someone needs it turned into something the steering committee will actually engage with. Over enough of these I've landed on a rough method for the cut, so sharing it, and because I want to hear where others draw the line differently.

The mistake I made early was treating the stakeholder presentation as a summary of the BRD. Shorter version, same shape. It never worked, because a BRD is organised for completeness and traceability, and a presentation has to be organised for a decision. Different jobs. You can't just compress one into the other.

What I cut, every time: the full requirement catalogue, the traceability matrix, the detailed acceptance criteria, the glossary, anything that exists for the build team or for audit. None of it earns a place in front of a sponsor. It all stays in the BRD where it belongs and gets referenced, not shown.

What I keep, and lead with: the problem the project exists to solve, stated in business terms, not system terms. The two or three decisions that genuinely change the shape of the solution. The scope boundary, specifically what's out, because that's where stakeholders get surprised six months later. And the assumptions that, if wrong, blow up the estimate. That last one I learned the hard way.

The reframe that made the difference: every slide in the stakeholder presentation has to be something a sponsor needs to know to approve, fund, or scope the work. If a slide only proves the BA did their homework, it's for me, not for them, and it comes out.

The BRD doesn't shrink. The presentation is a different artifact aimed at a different reader, drawn from the same source.

Where I'm still unsure is how much of the "how" to keep. Some sponsors want zero solution detail, some feel managed if there's none. Curious how others handle that line.

As a PO, I kept hitting the same wall: I’d spec out a feature, write it up as clearly as possible, and still get an implementation that handled edge cases differently than intended. Prose is just a terrible format for capturing complex decision logic.

Recently, I started experimenting with a different approach: forcing all decision logic into strict visual trees (conditions and outcomes) before drafting any text for tickets.

The original catalyst for this was actually AI. We wanted to map out logic so strictly that an AI agent couldn't "interpret" or hallucinate the rules. But something surprising happened when our BAs and testers got involved: the AI part became secondary, and the visual modeling became the actual value.

Building a decision tree collaboratively forces you to spot logical gaps before a single line of code is written. A missing branch stands out instantly in a diagram. In a Jira ticket, it just blends in as a sentence that made sense yesterday. It completely removed the ambiguity for our developers.

One specific practice that has been a game-changer for us: attaching concrete input examples directly to the consequence nodes. Basically forcing ourselves to answer "when exactly does this happen?" with real input values, which later serve as strict test cases.

I'm curious about the BA perspective on this. Have you completely moved to structured visual modeling (like DMN or custom decision trees) for complex logic, or do you still find yourselves writing extensive prose and hoping the developers interpret it correctly?

Hi everyone,

I have a B.Tech in ECE and currently work in Trade Finance Operations in a reputed MNC with experience of around 4 years.

I’ve been thinking about transitioning into a Business Analyst role, as I’m looking for work that’s more analytical and focused on process improvement.

For those who’ve made a similar transition, how did you do it? What skills, tools would you recommend? Is it a realistic move from a Trade Finance / Banking background?

Any guidance or roadmap would be greatly appreciated.

Thanks!

A while back I was asked to figure out why a company's sales had dropped.

The first request was, "Can you build a dashboard so we can track everything?"

After talking to a few people, it became clear they already had plenty of dashboards. Sales, inventory, marketing, finance. Nobody was short on numbers.

The real problem was that every team was looking at different metrics and making decisions independently. Marketing was celebrating lower acquisition costs while operations was struggling with stock shortages. Finance was focused on margins. Sales wanted volume.

The data wasn't wrong. The decisions just weren't connected.

That project changed how I approach reporting. I spend far more time asking what decision someone is trying to make than deciding which charts to build.

A simple report tied to one business decision is usually more valuable than a beautiful dashboard with fifty KPIs.

I've started to think that most companies don't actually have data problems. They have decision problems that happen to involve data.

Curious if others have seen the same thing, or if your experience has been different.

Is it better to be a scrum master in insurance operations or ba in digital experience?

I have few years of experience in quality management in manufacturing setting and some website/webapp for smaller business experience as a BA. I don’t have strong domain or enterprise system experience, so I’m split between the 2. It was really rough landing a role, and both have instability so wondering if I’m out after 1-2 years what experience would be better on my resume?

Most of my recommendation presentation work sits on data I don't fully trust. Manual exports, three source systems that disagree, a field that's been free-text since 2019 so half of it is garbage. The honest answer is often "the direction is clear, the precision isn't." The hard part has never been the analysis. It's the caveats slide.

For years I did the caveats wrong in one of two ways. Either I buried them, one grey line at the bottom nobody read, and then got ambushed in the room when a stakeholder who knew the data poked the soft spot. Or I overcorrected and front-loaded every limitation, at which point the whole recommendation read as "I'm not sure," and leadership tabled it.

What I do now is separate two things that I used to mash together. There's uncertainty that changes the decision, and there's uncertainty that doesn't. Those are different slides, and only one of them belongs near the recommendation.

So the caveats slide leads with the limitations that would actually flip the call if they broke the other way. "This holds unless the Q4 returns data is undercounting by more than 15 percent, and here's how we'd know." That's a real caveat with a threshold and a tripwire. The rest, the housekeeping about sample windows and field cleanliness, goes in an appendix the room can challenge me on but that doesn't derail the decision.

The reframe that helped: a caveat isn't a confession, it's a boundary on the claim. Stating the boundary precisely makes the claim inside it stronger, not weaker.

How do the BAs here structure this when the data is genuinely shaky? Specifically how you decide what's a decision-changing caveat versus housekeeping.