Agile & Scrum for Business Analysts

Agile is a mindset and set of practices that delivers software incrementally, adapting to change rather than following a rigid plan. Scrum is the most popular Agile framework. Most modern BA roles operate within Agile teams, making this topic essential for your career.

This topic teaches you the Agile principles, the Scrum framework (roles, ceremonies, artifacts), how user stories replace traditional requirements documents in Agile, how to groom and prioritize backlogs, and how the BA role adapts in Agile teams. You will also learn the basics of Kanban, the other popular Agile approach. By the end, you will be able to join any Agile team and contribute immediately.

Complete Documentation & Use Cases before starting this topic. A basic understanding of user stories and acceptance criteria is assumed.

The Agile Manifesto (2001) established four values that changed how software is built:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The Manifesto does not say documentation, processes, or plans are bad — it says the items on the right are valuable, but the items on the left are more valuable.

For a BA, this means: you still write requirements, but you write them as user stories (shorter, more conversational) rather than 50-page documents. You still plan, but you plan in short iterations rather than months. You still analyze, but you analyze just enough to support the next sprint, not everything up front.

Scrum is structured around roles, ceremonies (events), and artifacts:

Roles:

• Product Owner: Owns the product vision, prioritizes the backlog, and represents the customer. In many teams, the BA works closely with or is the Product Owner.
• Scrum Master: Facilitates Scrum ceremonies, removes impediments, and coaches the team on Agile practices.
• Development Team: Self-organizing team that builds the product (developers, QA, designers, and often the BA).

Ceremonies:

• Sprint Planning: The team selects items from the backlog for the upcoming sprint (typically 2 weeks).
• Daily Standup: 15-minute daily sync: What did I do? What will I do? What is blocking me?
• Sprint Review: The team demos working software to stakeholders and collects feedback.
• Sprint Retrospective: The team reflects on what went well, what did not, and what to improve.

Artifacts:

• Product Backlog: The ordered list of everything needed in the product.
• Sprint Backlog: The subset of items selected for the current sprint.
• Increment: The sum of all completed backlog items at the end of a sprint — must be "done" and usable.

In Agile, user stories replace traditional requirements documents. A user story is a short, simple description of a feature from the user’s perspective.

Format: "As a [type of user], I want [an action] so that [a benefit/value]."

Example: "As a customer support agent, I want to search for orders by customer email so that I can resolve inquiries faster."

Three Cs model (Ron Jeffries):

• Card: The written story — a reminder, not a specification
• Conversation: The discussion between the BA, developers, and stakeholders that fleshes out the details
• Confirmation: The acceptance criteria that verify the story is complete

Acceptance criteria use the Given/When/Then format:

Given I am on the order search page
When I enter a customer email and click Search
Then I see all orders associated with that email within 2 seconds

INVEST criteria for good user stories:

• Independent — not coupled to other stories
• Negotiable — a conversation, not a contract
• Valuable — delivers value to the user or business
• Estimable — the team can estimate effort
• Small — fits within a single sprint
• Testable — has clear acceptance criteria

Backlog grooming (or refinement) is the ongoing process of reviewing, clarifying, estimating, and prioritizing items in the product backlog. The BA plays a central role.

What happens during grooming:

• Review upcoming stories and confirm they are clear and ready for development
• Break large stories (epics) into smaller, sprint-ready stories
• Add or refine acceptance criteria
• Estimate effort with the team (story points or t-shirt sizing)
• Prioritize based on business value and dependencies

Prioritization techniques:

MoSCoW:

• Must have: Critical — the product fails without it
• Should have: Important but not critical — can work around it
• Could have: Nice to have — adds value but not essential
• Won’t have (this time): Out of scope for this sprint/release

WSJF (Weighted Shortest Job First): Used in SAFe. Score = (Business Value + Time Criticality + Risk Reduction) / Job Size. Highest score = highest priority.

During Sprint Planning, the team selects stories from the backlog for the upcoming sprint. The BA’s role:

• Clarify requirements — answer questions, provide context, resolve ambiguities
• Confirm acceptance criteria — ensure the team knows what "done" looks like
• Identify dependencies — flag stories that depend on other teams or external systems
• Help estimate — provide complexity context based on requirements understanding
• Advocate for the user — ensure the team does not skip the user’s perspective in technical discussions

The BA should be present in all sprint ceremonies — not just planning, but also standups (to answer requirement questions), reviews (to validate the increment), and retrospectives (to improve the requirements process).

Kanban is a visual workflow management method that focuses on continuous delivery rather than fixed sprints. It is simpler than Scrum and works well for teams with varying priorities.

Core Kanban principles:

• Visualize the workflow — use a board with columns (To Do, In Progress, Review, Done)
• Limit Work in Progress (WIP) — each column has a maximum number of items to prevent overload
• Manage flow — monitor how items move through the board and identify bottlenecks
• Make policies explicit — everyone knows what "Done" means and what each column requires
• Implement feedback loops — regular reviews and retrospectives
• Improve collaboratively — the team evolves the process continuously

Scrum vs Kanban:

Agile is easy to do badly. Watch for these anti-patterns:

• Zombie Scrum: The team does the ceremonies (standups, reviews) but there is no real collaboration, no working increment, and no stakeholder feedback
• Water-Scrum-Fall: The team calls it "Agile" but does all requirements up front and all testing at the end — waterfall with Scrum terminology
• User stories as mini-waterfall: Writing every detail in the story instead of leaving room for conversation
• No Definition of Done: Stories are marked "done" without meeting quality standards — technical debt accumulates
• Velocity gaming: Inflating story points to look productive instead of focusing on value delivery
• Missing retrospectives: Skipping the one ceremony that actually drives improvement

As a BA, you are often the first to notice these patterns. Use the retrospective to raise them constructively.

1. Take a feature idea for a mobile app and write 8 user stories with acceptance criteria in Given/When/Then format.
2. Prioritize those 8 stories using MoSCoW — justify each classification.
3. Simulate a sprint planning session: select 5 stories for a 2-week sprint and write a sprint goal.
4. Create a Kanban board (physical or digital in Trello/Jira) with WIP limits for a hypothetical project.
5. Identify two Agile anti-patterns you have seen (or can imagine) and describe how you would address them in a retrospective.

In a real job, Agile is the default in most software companies. You will join a team that does two-week sprints, uses Jira, and expects you to keep the backlog healthy. Your BA skills — elicitation, documentation, stakeholder management — do not disappear in Agile; they adapt. Instead of a 30-page BRD, you write concise user stories. Instead of a monthly status meeting, you do daily standups. Instead of a sign-off meeting, you demo working software every sprint. The BAs who thrive in Agile are the ones who can switch between strategic thinking (what should we build next?) and tactical execution (what does this specific story need?) on the same day.

Business problem: A fintech startup is building a personal finance tracking app. Users want to link bank accounts, categorize transactions, and set budgets.

Objective: Practice Agile BA skills: write user stories, groom the backlog, plan a sprint, and manage the workflow.