In agile environments, the details within user stories are the primary vehicle for expressing requirements. Those details are usually called acceptance criteria. When the acceptance criteria are clear, valuable, and testable, teams have a better chance of delivering valuable outcomes. When they are vague, disconnected, or overly technical, teams struggle with rework, misalignment, and missed expectations. One of the most effective ways to improve the quality of user stories is through solid business process analysis—and this is where the business analyst plays a critical role.
A business analyst bridges the gap between how the business operates today, how it needs to operate in the future, and how the agile team translates those needs into working software. By grounding user stories in a deep understanding of business processes, the BA ensures that stories reflect real workflows, stakeholder needs, and business value rather than isolated features or assumptions.
By passing that deep understanding along to the team that will build the solution, the entire team will better focus on those workflows and true stakeholder needs and will deliver the value expected, or even beyond expectations.
I have witnessed the reactions of stakeholders and users that teams serve when the team has this focus. It is a wonderful, amazing thing to behold. They are more involved, happier with outcomes, and willing to collaborate to get even more done for their organization. Let’s go through how to get there. I’ll sprinkle in examples from an Employee Onboarding project.
Start with Scoping the Effort
Going from business processes to user stories is about progressively narrowing scope from how the business works to what specific users need from a system. A clear, repeatable flow helps teams avoid either writing stories that are too vague (“manage employee”) or too technical (“build an interface that sends a CSV file to an SFTP server”).
One piece of the scope of an initiative or project is the set of high-level processes targeted for improvement or development. Identify the business processes, not the system actions. You can create a lightweight process diagram. You don’t want to over-document, but to establish shared understanding with stakeholders and team members. The overall process can be captured on a whiteboard, a tool like Visio, or a virtual collaboration tool, like Miro.
Understand Business Processes as the Foundation
Business processes describe what work needs to be accomplished for the organization to succeed: the sequence of activities, decisions, roles, inputs, outputs, and handoffs required to achieve a business outcome. Examples include onboarding a new customer, processing a loan application, handling an insurance claim, or resolving a customer service issue.
A BA begins by analyzing these processes at an appropriate level of detail. This does not mean creating massive documentation but rather identifying:
- The trigger that starts the process
- The key steps and decision points
- The actors involved (people, systems, external parties)
- The business rules that govern behavior and data
- The data needed to perform the work
- The desired outcomes and success measures, including any key performance indicators
- Pain points, delays, errors, and inefficiencies
This analysis helps the BA see the “whole system” rather than just individual features. Without this context, user stories can easily become disconnected tasks that optimize one step while breaking another.
For our Employee Onboarding project, you could take each of the steps in the processes, represented by the rectangles in my diagram, and identify the six bullet items listed above.
Business Process Template Download
If you want more formal documentation, our Business Process Template can be used to capture these details.
Translating Processes into User-Centered Perspectives
One of the BA’s most important contributions is shifting the conversation from “what the system should do” to “what the user needs to accomplish.” Business processes are often described from an organizational or functional perspective, but user stories require a user-centered lens.
The BA helps identify the true users within each process. These may include:
- Frontline employees
- Supervisors or managers
- Customers or members
- Back-office processors
- External partners or vendors
For each role, the BA asks questions such as:
- What goal is this person trying to achieve at this step?
- What information do they need to make a decision?
- What slows them down or causes frustration today?
- What errors or rework commonly occur?
By mapping process steps to user goals, the BA creates a natural pathway to high-quality user stories. Each meaningful interaction in the process becomes a candidate for one or more stories, framed around user value rather than system functions.
For our Employee Onboarding example, we could break our flowchart down into these major processes based on the steps performed:
Identify the Roles
Identify the roles (sometimes called actors or personas) in the processes and the goals for each role. For each process step, ask: Who is responsible for this step? Who performs this step? Who benefits from it?
Role
Goals
New Hire
Wants to have all the resources they need to start their role effectively
HR Representative
Hiring Manager
Wants to be able to help the new hire transition smoothly into their role
IT
Wants to ensure that the new hire has technology equipment and security access appropriately assigned and provisioned
Facilities
Wants to ensure that the new hire has the correct physical access to the buildings and office space that they need, including any special needs
Identify the Features Based on the Processes and Roles
One process may become one feature if there is only one role. Typically, you have multiple roles involved in high-level process, so you’ll typically have multiple features per process. You may be making technical decisions at this point, so you may be deciding if the system will “automatically” perform some features or parts of features, where there is no human role involved.
Example for Initiate Onboarding
Decompose the Features into Stories
Depending on the size of the project, you might start with just a few, perhaps even one or two, features to decompose. Some features might not need further breakdown; they become stories. You might leave the remaining features, not decomposed, in your backlog.
Establish the Story Boundaries
A common agile challenge is writing user stories that are either too large (epics or features disguised as stories) or too small (technical tasks with little business meaning). Business process analysis helps the BA define appropriate story boundaries.
Using the process as a guide, the BA can:
- Group related steps that together deliver a meaningful outcome
- Separate alternative flows and exceptions into distinct stories
- Identify where a story should end from a business perspective, not a technical one
For example, instead of a single story like “As a new hire, I want to be able to start work,” a BA informed by process analysis might help the team create stories such as:
- Capture new hire acceptance of job
- Validate new hire information
- Send request to IT to set up new hire with technology
- Provide new hire with building access
Each story aligns to a logical segment of the process and delivers observable value, making it easier to estimate, build, and test.
Ensure Stories Reflect Real Business Rules
Business processes are governed by rules: eligibility criteria, approval thresholds, compliance requirements, timing constraints, and exceptions. These rules are often implicit in how work is done today and may not surface unless someone deliberately uncovers them. What I often encounter in user stories are system rules disguised as business rules. For example, “Insert a new row into the EMPLOYEE table with status = ‘PENDING’” is NOT a business rule, it’s a system action. The business rule that drives that system action would be something like “onboarding is initiated only after a hire is approved by the Hiring Manager and the HR Representative”. Connect User Stories to End-to-End Value
Agile teams often work incrementally, but the business experiences outcomes end to end. Process analysis helps the BA keep the team focused on the full value stream, even while delivering in small slices.
The BA can help the team understand:
- How individual stories contribute to the overall process
- Which steps are most critical to business success
- Where bottlenecks or handoff issues exist
- How improvements in one area affect downstream work
This perspective allows the BA to support better backlog prioritization. Stories are not just ordered by stakeholder preference or technical convenience, but by their impact on business outcomes such as cycle time, customer satisfaction, risk reduction, or revenue.
Support Testability and Shared Understanding
Strong user stories are testable. Business process analysis contributes directly to this by making expected behaviors explicit. The BA helps ensure that each story’s acceptance criteria describe observable outcomes tied to the process.
For example, acceptance criteria grounded in process analysis might include:
- Given specific inputs, the correct decision is made
- Required notifications are sent at the right time
- Data flows correctly to the next process step
- Exceptions are handled according to policy
This clarity benefits not only developers, but also testers, product owners, and stakeholders. Everyone can see how the story supports the business process and what “done” truly means.
Conclusion
A business analyst adds immense value to agile teams by grounding user stories in thoughtful business process analysis. By understanding how work actually flows through the organization, the BA ensures that user stories are user-centered, appropriately scoped, rule-aware, and aligned to real business outcomes.
Good user stories are not written in isolation. They emerge from a deep understanding of people, processes, and purpose. Through effective process analysis and collaboration, the business analyst helps transform business complexity into clear, actionable user stories that enable agile teams to deliver meaningful value—increment by increment.
Ali Cox
LEAD EXPERT
Alison (Ali) Cox has experience since the mid-1980s in various areas, including business agility, business analysis, project methodology development and training, systems development (mainframe, client-server, and web), and telecommunication expense management. She began her career in the financial services area, and then moved into systems development for accounting systems.
Ali has lived through IT and operational initiatives from waterfall to implementing agile in her own small business, then helping other companies do the same through training and mentoring. She believes that having the small business mentality (everyone has to pitch in on everything) is the right kind of mindset for all organizations, no matter the size or industry.
Ali is the author of Business Analysis for Dummies, 2nd Edition.