In today’s fast-paced digital environment, the role of an Agile Business Analyst (BA) goes far beyond gathering requirements. BAs serve as the bridge between business needs and technical delivery, ensuring clarity around problems, stakeholders, value, change, context, and solutions aka the BA Core Concepts.

For large, complex organizations, analysts juggle multiple responsibilities across initiatives — from cross-platform projects to urgent “hot issue” fixes. Their days are filled with recurring team ceremonies like standups and backlog refinement, as well as deep-dive collaboration sessions to align stakeholders and clarify requirements.

AI is reshaping how these tasks are done. Instead of spending time taking and rewriting notes, BAs can use AI-powered transcription and summarization tools to stay engaged in discussions and generate structured insights afterward. In requirement modeling, AI helps analysts quickly structure user stories, explore scenarios, and identify edge cases. Visual modeling still requires human oversight, but tools like Mermaid syntax can accelerate diagram creation when paired with AI prompts.

When it comes to analysis work, AI offers major time savings. Analysts can prompt AI to scan through legacy documentation, extract key data relationships, or even generate technical scripts as I did when using GitHub Copilot to build a working Python script without being a developer.

For now, AI enhances, not replaces, the analyst. Success depends on giving AI quality input, validating its output, and applying human critical thinking to interpret results.

Ultimately, an Agile Business Analyst’s value remains in bringing clarity and AI can help handle the tedious parts, allowing analysts to focus on human insight, collaboration, and the strategy that drives real business outcomes.

Ambiguous requirements are part of the job for every business analyst. When an interviewer asks “How do you handle ambiguous requirements?”, they’re really asking: “How do you do your job?”

In this guide, we’ll break it down with an easy example, then look at a real-world case from business systems.

Start with Why

Imagine your boss says: “I want to go on a trip.”

That’s a vague requirement. The first step is to ask why.

• Is it to relax?
• To sightsee?
• To hike and camp?

Each reason leads to a completely different type of trip—and the same is true with business requirements. Understanding why sets the foundation for clarifying everything else.

Identify Stakeholders

Next, ask who’s involved.

• Who’s coming on the trip (friends = stakeholders)?
• Who else is impacted (kids needing childcare, someone covering at work, etc.)?

Stakeholders may include not only the requester but also everyone affected by the process or outcome.

Clarify Needs and Preferences

With stakeholders identified, drill into what they want.

• Do they want active days (hiking, jet skiing)?
• Relaxation (spa, beach)?
• Nightlife (clubs, karaoke)?

This is the equivalent of defining functional and non-functional requirements in a business project.

Organize and Validate

Once preferences are clear, group them into a structured plan:

• Day 1: Spa + dinner out
• Day 2: Beach activities
• Day 3: Sightseeing and nightlife

Then, validate with stakeholders: “Does this capture what you want?”

Only after confirming the requirements do you move on to solutions (booking a resort, cruise, etc.).

Translate to Business Analysis

In BA terms, you’re applying six key concepts:

• Context – Why does this matter?
• Problem – What’s driving the request?
• Need – What outcome is desired?
• Stakeholders – Who’s impacted?
• Value – What’s the benefit?
• Solution – What options meet the need?

By systematically questioning and clarifying, you turn ambiguity into actionable requirements.

Real-World Example: CRM + Contract Management Integration

In one project, the requirement was: “Integrate contract lifecycle management with Salesforce.”

At first glance, that’s vague. Here’s how to break it down:

1. Ask Why – In this case, the need was to ensure contracts were tied to closed opportunities, so future teams could easily find agreements without hunting across systems.
2. Identify Stakeholders – Salespeople, customer success teams, service fulfillment teams, and leadership.
3. Clarify Needs – Sales must not be slowed down; other teams need reliable access to contracts.
4. Design Within Constraints – Integration should enforce rules (e.g., an opportunity can’t close without a linked contract) while keeping sales efficient.
5. Validate – Ensure all stakeholders agree the solution fits their processes.

The vague requirement (“integrate systems”) became a clear set of functional rules and user needs.

Where AI Fits In

AI can help brainstorm questions to ask when you’re new to a domain. For example, ChatGPT can suggest common considerations for integrating systems.

But AI can’t replace the human role:

• Digging deeper when answers are political, not logical.
• Navigating organizational dynamics.
• Building trust with stakeholders.

The BA’s value lies in asking the right questions and interpreting answers in context.

Key Takeaway

To handle ambiguous requirements:

1. Focus on context, problem, need, stakeholders, value, and solution.
2. Ask questions until the ambiguity disappears.
3. Structure and validate requirements before jumping into solutions.

That’s how you turn “I want a trip” or “integrate this system” into clear, actionable requirements.

These are a form of Requirement  that must be met to give a solution, feature, or functionality a pass or fail. You should expect to do this a lot as a BA as it is core to writing requirements.

The BRD or business requirements document is one of the original standard business analysis deliverables in a waterfall methodology. It is typically the result of weeks or months of work. As you will see, it represents a very formal document that essentially becomes a contract between the business owners who want the software or features and the designers and developers who will be creating it.  

Download Here

>> Business Analysis Template <<

(Google Doc)

10.26 Item Tracking is really just following or monitoring something until completion. It could be requests, issues, or any work you are doing. It usually helps keep you or the team focused and if shared it creates transparency. A user story moving from creation through completion is an example of item tracking.

10.27 Lessons Learned is basically something you do after the completion of a project or program to talk about everything that basically sucked about the project or program. Things that could have been done better. This is analogous to the retrospective in agile scrum

10.28 Metrics and Key Performance Indicators (KPIs) are basically what you keep track of to ensure something is performing well. As a BA part of your job is making sure the right things get measured. For example, many people who begin exercising to achieve a smaller waist will measure how much they weigh instead of the change in circumference of their waist, which is a poor indicator if you are increasing muscle as you decrease fat.

10.29 Mind Mapping is a form of concept modeling that basically shows parent-child relationships of ideas or concepts. It’s helpful in getting organized especially at the beginning of an initiative and its one of the easier style of models to create live with a group of people to keep them focused

10.30 Non-Functional Requirements Analysis is basically about making sure the functionality or systems meet requirements that are kind of outside what something does and more concerned with the how. It usually has to do with future-proofing, quality, and compliance. Examples might be scalable, portable, maintainable, usable, have good performance, compliant, etc. 

10.31 Observation is pretty straight forward. It basically means to watch a process happen live to understand it. This can be valuable because people who have been a part of a process for so long can overlook parts that they just take for granted and not mention whereas you’d see it for yourself if you were observing.

10.32 Organizational Modelling is basically like creating a family tree of your organization. There are a few different versions and styles depending on what you want to get out of it and are typically created to help gain and facilitate understanding of how things are aligned in your business. Also, knowing who people report to will also help you understand their priorities and communicate better with them.

10.33 Prioritization is exactly what it sounds like but from a BAs perspective, its finding and providing the right information so that decision-makers can make good decisions in prioritizing things. It can sometimes include negotiating with stakeholders and the importance of things and the more information you have the better you can lead the discussion.

10.34 Process Analysis is looking at a process and determining how to make it more efficient. There are a few techniques to do this and process analysis is kinda the whole shebang with lean and six sigma. If you are interested in process analysis, certifications in those spaces might be a good choice

10.35 Process Modelling is a specific technique to visually model a process for process analysis. Process models can be created in many ways, but if you want to benefit from tools that simulate your process to find efficiencies, it would be valuable to learn BPMN standard notation.

10.36 Prototyping is creating a light version of something to essentially test out something. A prototype can be as light as a sketch on a piece of paper or a fully functioning application that just isn’t connected to real data. Prototyping is one of the most valuable and reliable ways to save time and effort on rework and should be something more BAs should explore.

10.37 Reviews are a pretty basic technique, but it’s basically asking someone else to look at something to give an opinion or confirm that it what they expect. It could be a requirement, user story, prototype, etc. Reviews can be informal like hey does this look right, or very formal with a documented process and method for approval common in the water development lifecycle. 

10.38 Risk Analysis and Management involves documenting major things that can make the project go wrong a basically how screwed you’d be if they did. Basically if things change or don’t change when you need them to, if something is late or doesn’t get done, if people aren’t available, etc how it will impact the project. Usually, this is communicated up to the powers that be to try to reduce the chances of impacts of those risks.

10.39 Roles and Permissions Matrix is basically a way to document features or activities in an application and which user roles can see or use those features. Valuable for comprehensive testing later on

10.40 Root Cause Analysis is just like it sounds, it’s to figures out why something might be happening. This is another big part of process analysis and leans six sigma. You should expect to do a lot of root cause analysis in your detective work as a business analyst

10.41 Scope Modelling is a way to keep people focused on a project. It basically says these are the areas we are willing to change or in scope, vs areas we can’t or won’t change aka out of scope. A simple real-life example is if the project was to make someone look better. Exercise, diet and a haircut might be in-scope, but plastic surgery might be out of scope

10.42 Sequence Diagrams is a form of a diagram that basically depicts several things that have to happen in conjunction and the timing of those things can be important. Think if something starts happening, halfway through triggers another thing, but is still happening. Process models don’t do a great job of depicting such timings visually.

10.43 Stakeholder List, Map, or Personas are a few more ways to document the people impacted by your project. Stakeholder lists and maps typically include all players involved so they can have a good communication plan. Personas tend to be end-user of the system you are designing.

10.44 State Modelling is a technique used to understand the states of particular entities within a system. The purpose is to understand all the different states a thing can exist and the rules and how or why it might change. For example, something might go from open, to pending, to closed. What determines how it shifts between those states? 

10.45 Survey or Questionnaire are pretty familiar concepts for most of us. As a BA you might use one if you need to get information from lots of people once. It’s great for quantifiable data. The only caveat is that you need to be 100% sure your questions are super clear otherwise your data could be off because people misunderstood the question.

10.46 SWOT Analysis is basically an ungraded or robust version of a pros and cons list. SWOT stands for strengths, weaknesses, opportunities, and threats. This is another activity that typically happens early on to help determine the strategy and direction for an initiative.

10.47 Use Cases and Scenarios are to model interactions with a system and are very valuable to developers and testers if a BA takes the time to write these well. Each use case or scenario should center around one task and layout the back and forth between the user and system to complete the tasks. It should also include what happens if there is a failure, like an invalid credit card number, not old enough, or etc.

10.48 User Stories are basically the format of agile requirements. They require the writer to document who the requirement is for, what they want to happen, and why they want it to happen. Traditional requirements often just have the what, which doesn’t always help you design the best solution if you don’t know who is using it and why they need it. 

10.49 Vendor Assessments as a business analysis usually involve documenting what the business needs and then evaluating different solutions from vendors on how well they meet them. This would use evaluation criteria which were in the first technique of this video series. Usually, the organization will have a defined process for this, but you will be likely responsible for creating the evaluation criteria.

10.50 Workshops are another mechanism to get a group of people together to reach a specific goal. Often times is the many stakeholders coming together to agree on a future state of a process that likely impacts all of them in some way. Being able to facilitate something like this is an extremely valuable skill and something you should practice whenever possible. They even have certifications for meeting facilitation

Transcript of 1-25

10.1 acceptance & or evaluation criteria. These are really just requirements that must be met in order to give a solution, feature, or a pass or fail. The difference between the two is that acceptance criteria are typically used for something under development, as a user story in a sprint and evaluation criteria are more common when you are comparing features of different software that you are potentially acquiring. You should expect to do this a lot as a BA.

10.2 Backlog management is basically how your scrum team manages your backlog in terms of definitions of ready, definitions of done, and so forth. I would definitely look into researching scrum backlog practices for this one.

10.3 Balanced scorecard is a technique intended to gauge the health of your organization. It involves measuring 4 categories. Customer Satisfaction, Employee Growth, Business Process Efficiency, and Financials. I honestly can’t imagine an entry-level business analyst being asked to do this, because it might include some tough conversations with some high-level people. In fact, to truly be unbiased, I could see a consulting agency doing this for a company

10.4 Benchmarking and marketing analysis is simply a way of comparing how you are doing to industry standards. The important thing here is to make sure you are comparing the right measures, but otherwise, conceptually it is pretty straight forward. If every competitor does A, B, and C, you have to measure how well you are doing A, B, and C.

10.5 Brainstorming is an umbrella term for coming up with ideas. You can brainstorm alone or you can facilitate brainstorming with a group.It involves good preparation with context areas and having the right people involved. It involves creating an environment for all people to share and explore freely and without judgment and finally, it involves outputting everything that was collected in a valuable manner.

10.6 Business Capability Analysis is similar to benchmarking in that you are essentially comparing to a standard of some kind. This is another thing I’d expect to happen with an experienced business analyst and likely from a consulting company. Often times its depicted as a bunch of boxes which organized by category and color-coded for like a pass, fail, and maybe some nuances in between.

10.7 Business Cases is basically something you write to justify spending time, resources, and money for a project to change something or buy something. It would likely include items from the balanced scorecard and how it’ll improve them.

10.8 Business Model Canvas is just a standard way to essentially show what your organization does and how it produces value. It very is reminiscent of what Enterprise Architects do which is a common career path for business analysts.

10.9 Business Rules Analysis basically documents the policies in which a business operates and helps inform how to formulate a business process. For example, a business rule might be that you don’t sell to people under 18. That might mean that the business process needs to have a step to validate age and paths for passing or failing age verification.

10.10 Collaborative Games are basically activities the help groups of people essentially create focus and direction for what the group needs to accomplish. In my own experience, I’ve used affinity mapping many times since its easy for people to understand and participate. It also gets people up and moving around.

10.11 Concept Modelling at a high level is just taking a bunch of terms or concepts from your domain and modeling out how they all relate to each other. I find them fun to make and extremely useful in understanding a new domain or helping others understand a domain. It is what I recommend BA when they first start a new project

10.12 Data Dictionary is basically a glossary for all your data. It often uses slightly more complex organization structures than say a dictionary and helps create an understanding of all the elements involved in a system. For example, you might define a person as a thing, and define a child as a subcategory of a person defined by an age range, then adult… you get the idea. Facilitates clarity.

10.13 Data Flow Diagrams are pretty key business analyst diagrams. They basically illustrate applications and what data flows between them. It helps create a sort of context in understanding what teams need to be worked with when something is going to change. 

10.14 Data Mining comes in two forms, looking at data to find an answer to a question, or look at data with no question to answer just to see what it tells you. Data helps inform a lot of decisions, so you should be comfortable doing some degree of data analysis to better perform your job as a business analyst. 

10.15 Data Modelling is a way to document how data is organized typically using standard notations. It often is used to model how databases structures will actually be organized. There is value in understanding data modeling to better understand and communicate constraints or opportunities in making decisions related to data.

10.16 Decision Analysis is about organizing information to make it easier to make a decision. There are different ways to accomplish this, but a common method is a scorecard with all the variables listed, values assigned and weighted, and seeing how different choices stack up side by side.

10.17 Decision Modelling is more focused on visualizing how the decisions are made and the outcomes. A decision model would theoretically be a big cascade of business rules.

10.18 Document Analysis is probably the most boring and one of the most used techniques of a business analyst. It’s literally learning from looking at existing documentation. Could be manuals, help documents, or documents created by a previous business analyst. It typically helps you build a degree of understanding so you can make the best of your time when in meetings and such.

10.19 Estimation for a business analyst is another big umbrella category of many techniques to estimate the future value of something. Most organizations have standards for how they prefer to estimate things, but if it’s something that impacts your work a lot, it could be valuable to explore different methods of estimation.

10.20 Financial Analysis revolves around assessing the benefit to the bottom line, usually over time and is one reason by business analyst new hires are business majors focused in IT because they would have had to take some finance and accounting classes. The more senior you become the more likely you’ll have to deal more and more with the financial aspects of projects.

10.21 Focus Groups are typically used to basically ask a group of people how they feel about something. For example, and HR business analyst working on a project for new hires onboarding might have a focus group with a bunch of new hires to ask how they felt about their experience.

10.22 Functional Decomposition is basically breaking down a high-level thing into its lower-level parts. This might mean breaking down a business requirement into the functional requirements for each part or system that needs to change, or Epics/Features down into user stories. You’ll be doing this a lot as a business analyst. It’s kinda like your main thing.

10.23 is a Glossary. Basically, if you have a bunch of nuanced terms or acronyms in your space, keeping a glossary will help you and anybody new to space.

10.24 Interface Analysis for a business analyst is looking at any interface whether its data interfaces, user interfaces, application interfaces, and basically documenting what’s there and why it exists. Very important to know before making changes to something.

10.25 is Interviews. Its how you learn stuff from people and I really hope you already knew that. The only thing I’ll say here is to make sure you have a goal for the interview before conducting it to help focus the conversation.