What Makes a Good Agile Business Analyst?

Written by Jude Mahoney

Agile Delivery Lead | Business Analyst Mentor | 20 Years Experience

LinkedIn: Jude Mahoney

Agile changed the way Business Analysts work, but it did not remove the need for Business Analysis. If anything, working in short delivery cycles makes good analysis more important because teams can now build the wrong thing remarkably quickly. That said, it's amazing how few BA's can adapt to the pace of delivering working software in an agile environment. 

There is a version of the Agile BA role that amounts to little more than backlog administration. A requirement arrives from a Product Owner, the analyst converts it into “As a... I want... So that...”, adds some acceptance criteria, puts it into Jira and moves it through refinement. The team may be working in sprints, attending stand-ups and delivering regularly, but very little Business Analysis may actually be taking place.

A good Agile Business Analyst does something much more valuable. They help the team understand what problem is worth solving, who it affects, what outcome the organisation needs, what should change, what should be delivered first and whether the eventual solution actually improved anything.

The documentation may be lighter than it once was and requirements are more likely to evolve as the team learns. Analysis often happens collaboratively and progressively rather than being completed in a large phase before development begins. The fundamental purpose, however, remains the same: create enough understanding for better decisions to be made.

A useful way to think about Agile Business Analysis is:

Understand the outcome → Explore the problem → Engage the right people → Analyse → Break down the work → Create shared understanding → Support delivery → Validate → Learn and adapt

That is considerably more than writing user stories.

Start with the problem to solve, not the backlog

One of the easiest traps in Agile delivery is treating the backlog as though it represents reality. It doesn't. The backlog represents the team's current understanding of work that may need to be done, and everything within it should remain open to analysis and challenge.

Suppose a Product Owner says:

“We need a new dashboard showing customer applications.”

A weak response is to ask who the user is and begin drafting a story. A stronger BA asks what problem the dashboard is intended to solve.

Perhaps managers currently spend two hours every morning compiling application information from three different systems. That discovery creates a much more useful set of questions. What decisions are managers trying to make? Which information do they actually need? Why don't existing reports provide it? How quickly is the information required? Why are three systems involved? Is another dashboard really the best answer?

A dashboard may still prove to be the right solution, but it is now an analysed response to an understood problem, rather than an instruction somebody placed into Jira.

That distinction is fundamental to good Agile Business Analysis.

Understand the outcome the team is trying to achieve

Individual backlog items should make sense in the context of a wider objective. If the team is trying to reduce avoidable customer calls about delivery status, for example, a proposed requirement for SMS notifications can be evaluated against that outcome.

Why are customers calling? At what point in the journey do they call? What information are they looking for? Do they already receive emails? Would clearer tracking information solve the problem more effectively than introducing another communication channel?

Without that wider outcome, an Agile team can easily become a feature factory. Stories are completed, sprint goals are achieved and releases happen regularly, but nobody stops to ask whether the underlying situation actually improved.

A good Agile BA keeps bringing the team back to a deceptively simple question:

What are we trying to achieve?

That question provides context for requirements, prioritisation, acceptance criteria and later measurement.

Analyse ahead, but not months ahead

One of the harder Agile BA skills is judging how much analysis to do and when to do it.

Do too little and developers repeatedly encounter unclear requirements, missing decisions and unresolved dependencies halfway through a sprint. Do too much and you recreate a six-month requirements phase, only now with an Agile board sitting beside it.

The answer is progressive analysis.

For work further away from delivery, you may only need to understand the business objective, broad problem, stakeholders, scope and major dependencies. As the work moves closer, you can investigate processes, user needs, business rules, data and options in greater detail. When something approaches delivery, stories, scenarios, acceptance criteria, dependencies and important decisions should be sufficiently understood for the team to work effectively.

Analysis also continues during delivery. Developers and testers will uncover questions, technical investigation may reveal constraints and stakeholders may provide new information. After release, the BA should remain interested in whether the change produced the outcome everyone expected.

The skill is not defining everything as early as possible. It is knowing what needs to be understood now and what can safely remain uncertain until later.

Be comfortable with uncertainty

Agile exposes something that traditional requirements processes could sometimes disguise: you will not know everything at the beginning.

A stakeholder may not yet have made a decision. User research may still be underway. A technical spike may change what is feasible. An early release may reveal behaviour nobody predicted.

Rather than hiding that uncertainty inside apparently definitive requirements, a good Agile BA makes it visible. A simple distinction can be extremely useful:

• Known: what evidence already supports.

• Assumed: what the team currently believes but has not established.

• Unknown: what still needs investigation.

• Decision required: something that the appropriate person needs to resolve.

For example, the team may know that customers frequently telephone Customer Service for application updates because call data demonstrates it. They might assume that customers call because the online account does not provide sufficiently clear progress information. What they do not yet know is precisely which information customers need.

That suggests a sensible next step: investigate customer behaviour before deciding that a particular feature is the answer.

Good BAs reduce uncertainty rather than disguising it.

Work with the Product Owner, but don't become their secretary

The Product Owner and Business Analyst can form an extremely effective partnership. The Product Owner may focus heavily on direction, value and priority while the BA investigates needs, processes, rules, stakeholders and the detail required for delivery.

That relationship breaks down when the BA becomes somebody whose job is simply to document what the Product Owner says. Remember, you're a BA, not a PA! 

If the Product Owner says:

“Customers need to upload three documents here.”

the BA should be capable of asking why three documents are required. Perhaps regulation genuinely requires all three. Perhaps Operations asks for three because an old system cannot retrieve information the organisation already possesses. Perhaps the third document is only necessary in particular circumstances.

Constructive challenge is not an obstacle to Agile delivery. It is one of the ways Business Analysis prevents the team from efficiently delivering unnecessary work.

Create shared understanding rather than perfect documentation

Agile places considerable emphasis on conversation and collaboration, but this is sometimes distorted into the idea that documentation itself is undesirable.

It isn't.

Unnecessary documentation is undesirable.

A user story and a handful of acceptance criteria may be enough for a straightforward change. A complicated operational problem might be far easier to understand with a process map. A decision table can explain complex combinations of business rules more clearly than paragraphs of prose, while a wireframe can remove ambiguity from a user interaction. Data models, examples, scenarios and diagrams all remain valuable when the problem calls for them.

The question should therefore be:

What is the clearest way to create and preserve the understanding we need?

A good Agile BA is not trying to produce the smallest possible amount of documentation or the largest. They are trying to create enough useful understanding for the team to make good decisions and deliver effectively.

Write useful user stories, not ceremonial ones

User stories can be extremely useful, but the format itself does not perform any analysis.

Consider:

As a customer

I want to receive notifications

So that I know what is happening.

It follows the familiar format perfectly while telling the team surprisingly little. Which customer? Notifications about what? At which points? Why do they need the information? What happens if delivery fails? Are there communication preferences? Are there regulatory constraints? What problem are we actually trying to solve?

A good Agile BA uses the story to represent a sufficiently understood piece of value or need. The sentence at the top of the ticket is not the requirement in its entirety; the conversations, scenarios, rules and shared understanding around it matter just as much.

A beautifully formatted user story based on a poorly understood need is still a poor requirement.

Write acceptance criteria that remove meaningful ambiguity

Acceptance criteria should help the team understand what must be true for the requirement to behave as intended. They should not merely repeat the story in slightly different language.

Suppose the story concerns an existing customer resetting their password. Analysis may need to consider how the customer is identified, which recovery methods are available, what happens when details do not match, whether recovery links expire, how repeated attempts are handled, what security controls apply and what confirmation the customer receives.

Not every question needs to become an acceptance criterion, but somebody needs to think about them.

Strong acceptance criteria describe important behaviours, rules and boundaries without unnecessarily dictating technical implementation.

Learn how to slice work meaningfully

Breaking a large requirement into eight technical tasks does not necessarily create eight useful increments of value.

Suppose the overall capability is:

Customers can manage their delivery preferences online.

The delivery work may involve a database, API, front end, validation and logging, but those are technical components rather than meaningful customer outcomes. From a Business Analysis perspective, more useful slices might allow a customer to nominate a safe place, choose delivery to a neighbour, select an alternative delivery date or change their preference before dispatch.

The team can now discuss which slice creates the greatest value, which dependencies exist and what could sensibly be delivered first.

A good Agile BA learns to help turn large needs into small, coherent increments that still mean something to the customer or organisation.

Know when work is sufficiently understood

“Ready” should not mean that every conceivable detail has been documented. It should mean the team understands enough to proceed intelligently.

Before work begins, there should normally be reasonable clarity around the problem or need, intended outcome, relevant user or stakeholder, important business rules, acceptance expectations, major scenarios, dependencies and significant unanswered questions.

If developers will spend half the sprint waiting for somebody to decide what the requirement means, the work probably wasn't sufficiently understood. Conversely, delaying useful work for weeks because one extremely unlikely exception has not been specified perfectly is unlikely to help either.

Again, judgement matters.

Treat refinement as collaborative analysis

Backlog refinement should not consist of the BA presenting completed requirements while everybody else estimates them.

Developers, testers, UX specialists and Product colleagues possess knowledge the BA does not. Developers may identify technical implications, QA may expose scenarios nobody has considered and UX may challenge assumptions about user behaviour.

Suppose a developer asks during refinement:

“What happens if the customer has two active applications?”

Nobody has considered it.

That is not necessarily evidence that the BA has failed. It is evidence that collaborative analysis has uncovered something useful before development.

Investigate it, resolve it and improve the requirement.

That is what refinement should achieve.

Work closely with developers and testers

A good Agile BA does not throw requirements over a digital wall and wait for the developers to return software.

Technical curiosity makes a BA considerably more effective. You do not need to become a software engineer, but understanding concepts such as APIs, integrations, databases, authentication, data flows and system dependencies allows you to have better conversations and ask better questions.

Developers also expose edge cases. If somebody asks what should happen when a customer's account closes between submitting a request and the request being processed, they may just have prevented a production defect.

Testers bring another valuable perspective because they naturally explore boundaries, failure and alternative scenarios. They ask what happens when there is no data, something fails, a user repeats an action or a rule reaches its boundary.

This is why conversations involving Business/Product, Development and Testing — often described as the Three Amigos — can be so useful. Different interpretations emerge before they become defects.

The ceremony is not the important part.

The shared understanding is.

Use workshops when collaboration will improve the answer

Agile teams already have plenty of meetings, so a workshop should earn its place in the calendar.

They are particularly useful when several people need to build a shared understanding, map a process, resolve conflicting requirements, explore scenarios, define rules, prioritise needs or break down a complicated area of work.

Start with the outcome. If you cannot explain what the participants need to understand, decide or produce by the end, the workshop probably isn't ready to be booked.

A focused hour with the right people and a clear analytical objective can resolve something that would otherwise generate days of separate messages and meetings.

Stay connected to stakeholders outside the delivery team

Working closely with a Product Owner does not remove the need for stakeholder analysis and engagement.

A Product Owner may understand priorities extremely well without knowing exactly how an operational employee handles an unusual case on a Friday afternoon. Compliance may understand a constraint that nobody in the delivery team knows exists. Customer Service may possess evidence about a problem that Product has only heard anecdotally.

The BA needs access to the real organisation surrounding the team. Depending on the change, that may include users, operational staff, managers, Finance, Compliance, Technology, Customer Service, Security, Data and external parties.

Agile should shorten feedback loops with these people, not isolate the team from them.

Facilitate rather than merely attend Agile ceremonies

Being present at stand-up, refinement, planning, review and retrospective does not make somebody an effective Agile BA.

Ask what value you are contributing.

During refinement, you may expose unanswered questions and clarify business needs. During planning, you may explain context or dependencies. During reviews, you may help stakeholders evaluate whether what has been delivered addresses the intended need. During retrospectives, you contribute as a team member to improving how everyone works.

The measure of a BA's contribution should never be how many Agile ceremonies they attend.

A BA who attends every ceremony but rarely investigates the underlying business problem is not doing strong Business Analysis.

Help the organisation prioritise intelligently

Prioritisation involves more than attaching MoSCoW labels to backlog items. If everything becomes a Must, the technique has told you nothing.

Real prioritisation involves trade-offs. Depending on the context, the team may need to consider value, risk, urgency, cost, customer impact, operational impact, regulatory need, dependencies and learning value.

A feature with modest immediate value might deserve early delivery because it tests an important assumption. Another might promise considerable benefit but require six months of technical work. A regulatory change may provide no obvious customer benefit while remaining completely non-negotiable.

The BA does not necessarily own the final decision, but they can make the evidence and trade-offs much clearer for the person who does.

Use evidence rather than accepting confident opinions

Agile delivery can become heavily conversation-driven, and conversations are useful. They are not always evidence.

If somebody says that customers “constantly complain” about something, investigate. How many complaints are there? What are they actually about? Which customers are affected? Has the situation changed over time?

Likewise, if somebody claims that nobody uses a feature, look at usage data if it exists.

Modern Business Analysts benefit enormously from enough data literacy to investigate claims rather than simply documenting them. That might involve Excel, SQL, analytics platforms, operational reports or collaboration with Data Analysts.

You don't need to become a data scientist. You do need to become comfortable asking:

What does the evidence tell us?

Challenge assumptions and proposed solutions

This is one of the most commercially valuable things a good BA can do.

Agile teams can deliver quickly. That is excellent when the direction is right and expensive when it isn't.

Suppose somebody proposes an AI chatbot because customers keep telephoning the organisation. Instead of immediately creating an epic for the chatbot, investigate why customers are calling. Which reasons generate the greatest volume? Can customers already find the information online? Are calls caused by missing information, a broken process, poor wording, technical failure or a genuine need for human assistance?

Perhaps a chatbot is appropriate.

Perhaps changing three sentences on a confirmation page eliminates thousands of calls for a fraction of the cost.

Speed of delivery does not compensate for poor problem definition.

Treat uncertain ideas as hypotheses

Not every proposed change deserves to be treated as established fact.

Suppose the team believes that showing customers an expected completion date will reduce status enquiries. That can be expressed as a hypothesis: if customers receive a reliable completion date, status-related contacts before that date should decrease.

Now the team has something it can measure.

This changes the conversation from:

“Did we deliver the feature?”

to:

“Did the feature create the change we expected?”

That is a much healthier relationship between requirements, delivery and evidence.

Validate outcomes, not just acceptance criteria

A story passing its acceptance criteria demonstrates that agreed behaviour was delivered. It does not demonstrate that the underlying business problem was solved.

Imagine the team introduces application-status notifications. The functionality works perfectly and every acceptance criterion passes, but Customer Service receives exactly the same number of status calls afterwards.

Technically, the story may be done.

Commercially, something has gone wrong.

Perhaps the notifications contain the wrong information. Perhaps customers don't trust them. Perhaps the calls relate to a different part of the process.

A good Agile BA remains interested after release. Did customer behaviour change? Did the process improve? Did the expected benefit materialise? What did the organisation learn?

Delivery creates new evidence. Use it.

Adapt when new evidence changes the requirement

Agile accepts that understanding evolves, but this does not mean requirements should change randomly.

Change may be entirely justified because user research reveals a different need, technical investigation exposes a constraint, regulation changes, testing uncovers an important scenario, priorities shift or an assumption proves false.

The BA should help preserve the reasoning behind significant changes. Otherwise the backlog eventually becomes a collection of decisions whose history nobody remembers.

Adaptation should come from learning, not chaos.

Use BA techniques without worshipping methodology

A good Agile BA understands Agile principles without becoming trapped by Agile terminology. The business stakeholder may not care whether something is technically classified as an Epic, Capability, Feature, Story or Enabler; they care whether their problem is understood and solved.

The same applies to traditional Business Analysis techniques. Agile has not made process mapping, gap analysis, stakeholder analysis, qualitative interviews, data modelling, workshops or business cases obsolete. All of them can still be useful. What changes is how much of each technique you use, when you use it and what purpose it serves.

A good BA therefore develops a toolkit rather than a script. If the problem concerns a complicated operational process, map it. If stakeholders disagree, facilitate the conversation. If you don't understand customer behaviour, conduct qualitative interviews or work with User Research. If a business rule contains numerous combinations, a decision table may help. If somebody's claim can be tested with data, analyse the data.

Don't begin with:

“Which BA template should I use?”

Begin with:

“What am I trying to understand?”

Then choose the technique that helps you understand it.

Communicate differently with different audiences

A developer may need detailed behaviour. A sponsor may need a concise explanation of value, risk and the decision required. An operational user may find a process map more useful than a user story, while QA may need scenarios and boundaries.

The BA often sits between these different worlds.

One of the most valuable Agile BA skills is being able to take complexity from one area and make it understandable to another without stripping away what matters.

That is more than communication.

It is translation.

Understand the business, not just the requirement

A BA who understands Jira perfectly but knows little about how the organisation makes money, serves customers, controls risk or operates will eventually limit their own value.

Ask broader questions. How does the organisation make money? What creates unnecessary cost? What matters to its customers? Which processes are critical? What risks concern leadership? What regulatory constraints exist? What is the organisation actually trying to improve?

Imagine a proposed feature costs £50,000 and saves one employee five minutes each month. It may be technically feasible and perfectly specified, but it could still be a dreadful investment.

Business Analysis should include commercial judgement.

Be willing to say “I don't know”

Agile environments can create pressure for quick answers, particularly when a development team is waiting.

Sometimes the correct answer is:

“I don't know yet. I need to speak to Operations and check the data.”

That is considerably better than inventing certainty simply to keep the sprint moving.

The important part is what happens afterwards.

Go and find out.

A good BA does not need to know everything. They need to recognise what needs to be known and how to obtain the answer.

A Structured Agile Business Analysis Approach

A practical Agile BA workflow might look like this:

Stage	Key question	Typical BA activity	Useful output
1. Outcome	What are we trying to achieve?	Objectives, measures, context	Clear outcome
2. Problem	What is actually happening?	Research, data, process analysis	Problem understanding
3. People	Who is affected or involved?	Stakeholder/user analysis	Relevant perspectives
4. Explore	What do we need to understand?	Interviews, workshops, analysis	Needs and insights
5. Options	What could change?	Gap/process/options analysis	Possible approaches
6. Break Down	What can we deliver usefully?	Story mapping and slicing	Prioritised increments
7. Clarify	Do we understand enough?	Stories, criteria and scenarios	Delivery-ready understanding
8. Collaborate	What are we learning during delivery?	Refinement, Three Amigos, Q&A	Improved understanding
9. Validate	Did we build what was intended?	Review and testing support	Validated behaviour
10. Measure	Did it improve the outcome?	Data, feedback and research	Evidence of impact
11. Adapt	What should we change next?	Analysis and reprioritisation	Next best action

In shorthand:

OUTCOME → PROBLEM → PEOPLE → ANALYSE → SLICE → CLARIFY → COLLABORATE → DELIVER → VALIDATE → LEARN

That is a much richer description of Agile Business Analysis than simply:

Epic → Story → Acceptance Criteria → Jira → Done

What Does a Good Agile BA Look Like in Practice?

Imagine a delivery team is told:

“We need customers to be able to change their delivery date online.”

The BA does not immediately write a story. They establish why.

Customer Service is receiving 12,000 calls each month relating to delivery changes. Those calls are expensive, and customers frequently wait several minutes to speak to an adviser.

The BA analyses the calls and discovers that customers mainly want three things: to change their delivery date, nominate a safe place or check when their delivery is due. They speak to customers and operational stakeholders, map the existing process and discover that delivery dates can only be changed before the parcel reaches a particular stage. They then work with Technology to understand the carrier integration.

Now the team has genuine analysis.

The BA and Product Owner can discuss which capability provides the greatest value first. Developers can explain technical constraints, QA can explore edge cases and the team can slice the work into meaningful increments.

The first release allows eligible customers to select an alternative delivery date before dispatch.

After release, the team measures whether related calls decrease. They discover that customers use the feature heavily but a significant number still telephone because they cannot understand why some dates are unavailable.

That creates new evidence and the team adapts.

The cycle is simple:

Understand → Analyse → Deliver → Learn → Improve

The skill lies in doing each part well.

Common Agile BA Mistakes

There are several warning signs that Business Analysis is being reduced to Agile administration:

• Becoming a Jira administrator: maintaining tickets begins consuming more effort than understanding problems.

• Treating the Product Owner as the only stakeholder: valuable customer and operational knowledge is missed.

• Writing stories too early: proposed solutions are documented before the underlying need has been explored.

• Using the user-story format as a substitute for analysis: correct syntax creates an illusion of clarity.

• Over-analysing everything upfront: detailed work is completed for requirements that may change or never be delivered.

• Under-analysing everything: developers repeatedly encounter basic unanswered questions during delivery.

• Treating Agile as documentation-free: important knowledge disappears into conversations nobody can later reconstruct.

• Accepting stakeholder requests without challenge: the backlog fills with features rather than outcomes.

• Ignoring evidence: decisions are driven by whoever speaks most confidently.

• Stopping at delivery: “Done” becomes more important than whether anything actually improved.

• Hiding uncertainty: assumptions quietly turn into requirements.

• Obsessing over Agile terminology: methodology becomes more important than useful analysis.

A more useful question than “Are we doing Agile correctly?” is:

Are we learning quickly enough to make good decisions and deliver something valuable?

A Practical Agile BA Checklist

Before work enters delivery, make sure you understand the business outcome, underlying problem and people affected. Check whether assumptions have been separated from evidence and whether the team understands enough to begin without pretending that every future detail is already known.

During delivery, stay close to Product, Development and QA. Use refinement and Three Amigos conversations to expose different interpretations before they become defects. When questions emerge, answer them quickly where you genuinely know the answer, but investigate rather than guess where you don't.

Stay connected to stakeholders and users outside the immediate team. Keep important decisions and requirements understandable, and choose analytical techniques because they suit the problem rather than because a template says you should use them.

After delivery, look beyond whether the acceptance criteria passed. Ask whether the expected behaviour or business outcome changed, what the evidence now tells you and whether the next priority should change as a result.

Then feed that learning back into the next piece of work.

Agile Business Analysis Is Still Business Analysis

The strongest Agile Business Analysts are not defined by how quickly they can write user stories.

They are defined by the quality of the questions they ask, the problems they uncover and the clarity they create.

A good Agile BA understands the business problem before rushing towards a feature. They can speak to a senior sponsor about outcomes and commercial value, then spend the afternoon working through a difficult edge case with a developer and tester. They know when a conversation is sufficient and when the team needs a process map, data analysis, workshop, business rule or more detailed requirement.

They challenge without becoming obstructive, document without becoming bureaucratic and analyse ahead without trying to predict the entire future. They collaborate without becoming passive and recognise that delivering more things is not necessarily the same as creating more value.

Agile should shorten the distance between an idea, delivery, evidence and learning. A good Agile BA helps make that loop intelligent.

So perhaps the best test of an Agile Business Analyst is whether they consistently help the team answer five questions:

• What problem are we actually solving?

• What evidence do we have?

• What don't we know yet?

• What is the smallest useful thing we can do next?

• How will we know whether it worked?

If those questions remain unanswered, there is still analysis to be done.

Developing Your Agile Business Analysis Skills

Learning Agile terminology is relatively easy. Understanding Scrum events, writing a user story and using Jira are not the difficult parts of becoming a capable Agile Business Analyst.

The harder part is applying Business Analysis when the problem is ambiguous, priorities change, stakeholders disagree, developers uncover new constraints and the team needs an answer quickly. That requires judgement, and judgement develops through applying techniques to real situations rather than simply memorising definitions.

Elisto's Business Analyst training focuses on practical Business Analysis within real delivery environments, including requirements analysis, stakeholder engagement, process analysis, workshops, user stories, acceptance criteria and working effectively with Agile delivery teams.

The Knowledge Hub can give you structures, examples and techniques. Training and practice develop the ability to decide which technique to use, how deeply to analyse and when the team knows enough to move forward.

That is where a genuinely good Agile Business Analyst becomes considerably more valuable than somebody who simply knows how to populate a backlog.