Most ANZ delivery teams work in some form of agile. As a BA, you are not just a spectator of agile ceremonies — you are an active participant with specific responsibilities that keep the team building the right things at the right level of quality. This lesson gives you a practical grounding in how agile actually works and exactly what the BA does inside it.
What You’ll Learn
Agile Manifesto
Scrum
Kanban
SAFe
BA vs PO
Ceremonies
User Stories
Acceptance Criteria
Hybrid Delivery
Agile is not a single methodology — it is a family of frameworks built on a shared set of values first articulated in the 2001 Agile Manifesto. Understanding the values prevents you from applying agile as a checklist. It explains why the practices work and when to adapt them.
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 right side still has value — the left side is valued more.
Scrum
Timeboxed sprints (1–4 weeks)
The most common framework in ANZ. Work is broken into sprints. Roles: Product Owner, Scrum Master, and the Development Team. The BA sits within or alongside the team, owning the requirements pipeline. Ceremonies: sprint planning, daily standup, sprint review, retrospective.
Kanban
Continuous flow, visualised on a board
Used for ongoing operational work or teams that cannot commit to fixed sprint cycles (e.g. support, maintenance). Work items move through columns: To Do → In Progress → Done. WIP limits prevent bottlenecks. BAs contribute by writing and sequencing backlog items and reviewing work as it moves through the board.
SAFe (Scaled Agile Framework)
Enterprise agile for large programme delivery
Dominant in ANZ government, banking, and large corporates running multiple agile teams on a shared programme. Adds Programme Increment (PI) Planning — a large cross-team planning event that runs every 8–12 weeks. BAs must understand PI Planning and how to prepare requirements at both team and programme level.
✗ The Common Misconception
“We don’t need a BA in Scrum — the Product Owner does that work.”
This conflation costs teams dearly. The roles are complementary, not interchangeable.
✓ The Correct Split
Product Owner: owns the product vision, sets priority, accepts or rejects delivered stories.
BA: owns the requirements pipeline — ensuring stories are written, refined, testable, and ready before sprint planning. The PO decides what to build; the BA makes it buildable.
Sprint Planning
Once per sprint — 2–4 hours
BA role: Present and clarify the stories the team will pull in. Answer questions on acceptance criteria. Do not estimate on behalf of the team — that is their responsibility. Ensure every story meets the Definition of Ready before accepting it into the sprint.
Daily Standup
15 minutes each morning
BA role: Listen for blockers you can resolve — unclear requirements, missing stakeholder input, undocumented edge cases. Do not dominate. If you have a requirement-related blocker to raise, do so briefly and resolve it offline.
Sprint Review / Demo
End of each sprint — 1–2 hours
BA role: Validate delivered stories against the acceptance criteria you wrote. Raise defects formally if criteria are not met. Do not accept incomplete work to hit a velocity number — it creates hidden debt.
Retrospective
End of each sprint — 1 hour
BA role: Contribute from a requirements quality perspective: are stories well-written? Is backlog refinement effective? Are acceptance criteria being used by testers? Is the backlog healthy heading into the next sprint?
Backlog Refinement
Weekly — 1 hour
BA role: This is the BA’s primary ceremony. Review and clarify upcoming stories with the team. Add acceptance criteria, break down epics, identify dependencies, surface questions that need stakeholder input before the story can be estimated.
User Story Format
As a [role], I want [capability], so that [benefit].
[role]
Who is performing this action? One specific user type, not “the system” or “all users”.
[capability]
What do they want to do? One specific capability per story. If it contains “and”, split it.
[benefit]
Why do they want it? The business outcome. If you can’t answer this, the story may not be worth building.
I
Independent
Can be delivered without another story
N
Negotiable
Scope can flex; not a contract
V
Valuable
Delivers business benefit
E
Estimable
Team can estimate the effort
S
Small
Completable within one sprint
T
Testable
Acceptance criteria exist
Given / When / Then Format
Given [a specific context or precondition]
When [the user performs a specific action]
Then [a specific, testable outcome occurs]
Example
Given I am a registered user and I am on the checkout page
When I enter a valid NZ bank card number and click Pay
Then a payment confirmation is displayed within 5 seconds and a receipt is emailed to my registered address
Definition of Ready (DoR)
The BA owns this. A story that fails DoR does not enter the sprint.
Definition of Done (DoD)
The whole team owns this. A story that fails DoD is not demonstrated as complete.
Topic 5: Hybrid Delivery — The ANZ Reality
Most ANZ enterprise delivery is not pure agile — it is hybrid. The organisation commits to a formal scope and budget upfront (waterfall-style), then executes in agile sprints. This means you need skills in both domains: writing a proper Business Requirements Document for the governance gate, then writing sprint-ready user stories for the delivery team.
Initiation & Discovery (Waterfall)
Business case, stakeholder mapping, high-level scope, governance approval
Design & Requirements (Hybrid)
BRD or FRD produced upfront; epic and story backlog created for sprint team
Delivery (Agile)
Sprint cycles, ceremony participation, backlog refinement, story sign-off
Transition & Review (Waterfall)
UAT sign-off, go-live checklist, lessons learned, PIR
Agile does not eliminate the BA role — it redefines it. You own the requirements pipeline; the Product Owner owns the priority decision.
Backlog Refinement is the BA’s primary ceremony. If your stories aren’t ready before sprint planning, the sprint starts broken.
The INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) are a practical quality checklist for every story before it enters refinement.
Given/When/Then acceptance criteria are the BA’s quality gate — if a tester can’t use your criteria to verify the story, rewrite them before the sprint starts.
Most ANZ enterprise delivery is hybrid: formal scope and budget upfront, agile execution. You must be fluent in both BRD-style documentation and sprint-ready user stories.
In SAFe environments, PI Planning is a critical event — prepare programme-level requirements and dependencies before the planning session, not during it.
Ready to go further?
Go from foundational knowledge to a globally-recognised BA certification. 6 weeks, 100% online, built around a real-world case study — not just theory.
One-time payment. Instant access. 14-day money-back guarantee.
Ready for the full qualification? CBBA Certification — $349 NZD · 6 weeks · 30-day money-back
Enrol in CBBA →