Agile for Analysts

Scrum, Kanban, backlog management, DoR/DoD, and story mapping — the BA's survival guide in Agile teams.

The Agile Manifesto (2001)

Agile emerged from a frustration with heavyweight, document-heavy software development processes. In 2001, 17 software practitioners signed the Agile Manifesto with 4 core values:

We value...	Over...
Individuals and interactions	Processes and tools
Working software	Comprehensive documentation
Customer collaboration	Contract negotiation
Responding to change	Following a plan

*"That is, while there is value in the items on the right, we value the items on the left more."*

12 Agile Principles (Key Ones for Analysts)

1. Deliver working software frequently — weeks, not months 2. Welcome changing requirements — even late in development 3. Business people and developers must work together daily 4. Simplicity — the art of maximizing the amount of work NOT done 5. The best architectures emerge from self-organizing teams 6. Regular reflection — how to become more effective

Scrum Framework

Scrum is the most widely used Agile framework. It organizes work into fixed-length Sprints (1-4 weeks).

### Roles

Role	Responsibility
Product Owner (PO)	Defines and prioritizes the Product Backlog; represents business value
Scrum Master	Facilitates Scrum process; removes impediments
Development Team	Cross-functional team that delivers working software

*Where does the BA fit?* In many teams, BA functions are split between PO (business requirements) and developers (technical specifications). In larger teams, a dedicated BA feeds the PO and bridges the gap to developers.

### Scrum Artifacts

Product Backlog: an ordered list of everything needed in the product. Owned by the PO.
Sprint Backlog: items selected for the current sprint + plan for delivering them.
Increment: the sum of all completed Product Backlog items at the end of a sprint. Must be potentially shippable.

### Scrum Events

Event	Purpose	Duration (for 2-week sprint)
Sprint Planning	Select items and plan the sprint	4 hours max
Daily Scrum	Synchronize and identify blockers	15 minutes
Sprint Review	Demo increment to stakeholders	2 hours max
Sprint Retrospective	Inspect and adapt the process	1.5 hours max

Kanban

Kanban is a flow-based approach. Work items move through stages on a board; there is no fixed sprint cadence.

Backlog │ To Do │ In Progress │ In Review │ Done
────────┼───────┼─────────────┼───────────┼─────
  US-12 │ US-11 │   US-09     │   US-07   │ US-05
  US-13 │       │   US-10     │           │ US-06
  US-14 │       │             │           │

WIP Limits: Each stage has a maximum number of items (Work In Progress limit). When a stage is full, the team must finish existing work before starting new items.

When to choose Kanban over Scrum:

•Continuous flow work (support, maintenance, bug fixing)

•Unpredictable incoming work

•When sprint ceremonies feel like overhead

Scrum vs Kanban

	Scrum	Kanban
Cadence	Fixed sprints	Continuous flow
Roles	PO, SM, Dev Team	No prescribed roles
Planning	Sprint Planning	Just-in-time
Change policy	No changes mid-sprint	Changes welcome anytime
Metrics	Velocity (story points/sprint)	Cycle time, throughput
Best for	Feature development	Support, maintenance

Project: Digital Onboarding for a Retail Bank

A regional bank is building a digital onboarding flow — customers should be able to open a current account entirely online in under 10 minutes.

Team: 1 Product Owner (Head of Digital), 1 BA, 1 Scrum Master, 4 developers, 1 UX designer, 1 QA engineer.

Sprint length: 2 weeks.

How the BA Works in This Team

### Between Sprints (Refinement ongoing)

The BA is the PO's "right hand" for backlog preparation. Between sprints, the BA:

•Conducts stakeholder interviews to clarify upcoming stories

•Creates wireframes with the UX designer

•Writes acceptance criteria in Gherkin format

•Identifies edge cases (joint accounts, non-resident customers, KYC failures)

•Flags regulatory requirements (AML check must complete within 24 hours of application)

### Sprint 3: Identity Verification

Sprint Goal: "A customer can verify their identity using their passport and pass liveness check."

Sprint Backlog (selected by the team in Sprint Planning):

Story	Points	Owner
US-31: Document capture UI (passport front/back)	5	Dev + UX
US-32: Liveness check integration (iProov API)	8	Dev
US-33: KYC result handling (pass / fail / manual review)	5	Dev + BA
US-34: Email notification on manual review	3	Dev
US-35: Admin view: pending manual reviews	5	Dev

BA's role during the sprint:

•Day 1-2: Available for developer questions on US-31 acceptance criteria

•Day 3: Discovered iProov API has different response schema than documented — BA updated the spec immediately

•Day 8: Participated in QA testing of US-33 edge case (expired passport → should route to manual review, not reject outright)

•Day 10: Prepared Sprint Review presentation for the Head of Compliance

### Sprint Review (Day 10)

Attendees: Head of Digital (PO), Head of Compliance, Head of Operations, project sponsor (CTO).

BA ran the demo of the identity verification flow. Compliance Officer flagged: "If the liveness check fails 3 times, what happens?" The team had assumed "reject" — but compliance required "flag for manual review after 3 failed attempts" (regulatory requirement the BA hadn't caught in initial elicitation).

Result: New story US-36 created for next sprint. PO and BA immediately updated the DoR checklist to include "KYC failure paths reviewed by compliance" for all identity-related stories.

Key Lessons

The BA's value in Scrum is not writing documents — it's continuous clarification and de-risking of stories before and during the sprint.
Sprint Reviews expose gaps. The BA turns gaps into new backlog items immediately.
The DoR (Definition of Ready) protects the team from starting stories that will be blocked mid-sprint.

Product Backlog Structure

The Product Backlog is a hierarchical list of work. Items are written at different levels of granularity:

Epic: Digital Onboarding
  Feature: Identity Verification
    User Story: As a customer, I want to upload my passport so that my identity is verified automatically
      Task: Implement document capture UI
      Task: Integrate iProov liveness check API
      Task: Handle KYC result states
  Feature: Address Verification
    User Story: ...

Epic: large body of work (months). Too big to estimate, needs decomposition.
Feature: a meaningful slice of an epic (weeks). Groups related stories.
User Story: deliverable in one sprint (days). Has acceptance criteria.
Task: technical work item within a story (hours). For developers.

Backlog Refinement (Grooming)

A recurring meeting (not an official Scrum event but universally adopted) where the team: 1. Reviews upcoming stories for completeness 2. Estimates effort (story points or T-shirt sizing) 3. Identifies dependencies and risks 4. Splits large stories into smaller ones

Who attends: PO, BA, tech lead, and at least some developers. Scrum Master facilitates.

BA's preparation: Before refinement, the BA ensures each story has:

•Clear user persona and goal

•Acceptance criteria written

•Edge cases identified

•UX mockup attached (if UI story)

•Technical risks noted

Definition of Ready (DoR)

DoR is a checklist of criteria a story must meet before the team commits to it in Sprint Planning. It protects the team from starting work they'll be blocked on.

Example DoR:

☐ User story written in standard format (As a... I want... So that...)
☐ Acceptance criteria written (Gherkin or rule-based)
☐ UX design approved (for UI stories)
☐ Dependencies identified and resolved or planned
☐ Story is estimated (≤ 8 story points, otherwise split)
☐ Regulatory/compliance implications noted
☐ Story is understood by at least 2 team members

Definition of Done (DoD)

DoD is a shared understanding of what "done" means for every story. Without it, teams argue about what finished means.

Example DoD:

☐ All acceptance criteria passed (automated + manual)
☐ Unit tests written, coverage ≥ 80% for new code
☐ Code reviewed and approved (≥ 1 reviewer)
☐ API documentation updated (if API changed)
☐ QA sign-off
☐ Deployed to staging environment
☐ No critical or high-severity bugs remaining
☐ PO accepted the story

Story Mapping

Story Mapping (Jeff Patton) is a technique to visualize the user journey and organize backlog items against it.

User Journey: Customer Account Opening

[Visit Site] → [Register] → [Verify ID] → [Fund Account] → [Use Account] ↓ ↓ ↓ ↓ ↓ Landing Basic info Passport Bank transfer First payment page form upload link debit card Liveness Card link Notifications check confirmation Address check ```

Reading the map top-to-bottom gives you releases: the top row = MVP (must have); rows below = later releases.

Benefits of Story Mapping:

•Shows what the user experiences end-to-end

•Reveals gaps in backlog coverage

•Makes release scope visible to stakeholders

•Helps prioritize: "which stories must be in the same release to deliver value?"

Estimation Techniques

Technique	How	Best for
Story Points	Relative sizing using Fibonacci (1, 2, 3, 5, 8, 13)	Velocity-based planning
T-Shirt Sizing	XS, S, M, L, XL — quick rough estimate	Early-stage backlog
Planning Poker	Team estimates simultaneously, discuss differences	Getting team alignment
#NoEstimates	Track cycle time instead of estimates	Mature Kanban teams

Setup

A fintech company is building a "Spending Insights" feature in their mobile banking app. Users will see categorized spending, monthly trends, and budget tracking.

The BA has 3 stories on the agenda for this refinement session:

Story 1: Spending Categorization

Before refinement: > "As a user, I want to see my spending categorized."

Problems identified:

•Who categorizes? Automatically or manually?

•What categories? Who defines them?

•What about uncategorized transactions?

•How do we handle transfers between own accounts?

After BA's clarification: > "As a mobile banking user, I want transactions automatically categorized on import so that I can see where my money goes without manual labeling."

Acceptance Criteria: ``` Given a bank transaction is imported via Open Banking API When the transaction description is analyzed Then the transaction is assigned one of the 12 standard categories: Food & Drink, Transport, Shopping, Healthcare, Entertainment, Utilities, Housing, Travel, Education, Personal Care, Savings, Other And transactions between user's own accounts are excluded from categories And uncategorized transactions appear in "Other" with a manual override option

Given the user wants to recategorize a transaction When they tap the category and select a new one Then the override is saved and reflected in all reports immediately ```

Team discussion: The ML model for categorization is a separate initiative. For this sprint, implement rule-based categorization (keyword matching). ML can replace it later with same interface.

Estimated: 8 story points. Split into two stories: categorization engine (5 SP) + manual override UI (3 SP).

Story 2: Monthly Spending Trend Chart

Before refinement: > "Users should see a chart of spending trends."

BA clarification questions:

•What time range? Last 3 months? 6? Custom?

•By category or total?

•What chart type? Line, bar, pie?

•Mobile: portrait vs landscape rendering?

Discovered gap: The team has no data before the feature launch date. The BA investigated: via Open Banking API, we can fetch 90 days of historical transactions on first sync. Added to acceptance criteria.

Estimated: 5 story points.

Story 3: Budget Alerts (Blocked)

Before refinement: > "Send a push notification when user exceeds their budget."

Blocked: Push notifications require backend infrastructure (Firebase Cloud Messaging) that isn't set up yet. The backend team won't complete FCM integration until next sprint.

Decision: Mark as NOT READY. BA adds it to the backlog for refinement next sprint after FCM dependency is resolved.

Refinement Output

Story	Status	Points	Sprint
Categorization engine	Ready	5	Sprint 7
Manual category override	Ready	3	Sprint 7
Monthly trend chart	Ready	5	Sprint 7
Budget alerts	Not Ready	TBD	Sprint 8

Total committed: 13 SP (within team velocity of 15 SP).

What Made This Refinement Effective

1. BA had prepared wireframes — the team could see what they were building 2. Acceptance criteria were pre-written in Gherkin — developers could estimate accurately 3. The budget alert blocker was caught before Sprint Planning — saved 30+ minutes of planning discussion 4. One story was split from 8 SP to two 5+3 SP stories, keeping both within DoR size limits

Sprint Planning

Sprint Planning kicks off the sprint. The team selects items from the Product Backlog and commits to a Sprint Goal.

### Structure (2-week sprint = max 4 hours)

Part 1 — What (2 hours): PO presents the top backlog items. Team asks questions, clarifies acceptance criteria. Team selects stories they can complete.

Part 2 — How (2 hours): Team breaks selected stories into tasks, identifies technical risks, confirms capacity.

### BA's Role in Sprint Planning

Answer questions about acceptance criteria and business rules
Help break down ambiguous stories
Flag dependencies with other teams or systems
Negotiate scope if team capacity is lower than planned (what can we cut from a story without losing its value?)

### Sprint Goal

The sprint goal is a single sentence capturing the business value delivered this sprint:

Good: "After this sprint, customers can complete identity verification without branch visit." Bad: "Complete US-31, US-32, US-33, US-34."

The goal helps the team make decisions during the sprint when unexpected issues arise — if something isn't needed to achieve the goal, it can be deferred.

Daily Scrum (Standup)

Duration: 15 minutes, same time and place. Purpose: Synchronize the team, surface blockers early.

Traditional 3 questions: 1. What did I do yesterday? 2. What will I do today? 3. Is there anything blocking me?

Modern alternative (focus on the work, not the person):

•Walk the board right to left (Done → In Progress → To Do)

•Discuss each in-progress item: is it moving? Any blockers?

### BA's Role in Daily Standup

Attend and listen — often the first to hear about requirements questions
After standup: available for immediate clarifications (the "hallway conversation" that follows)
Track stories that have been "in progress" for more than 2 days — may need to investigate

Sprint Review

The team demonstrates the completed increment to stakeholders and collects feedback.

Duration: 2 hours (2-week sprint).

Key principle: This is not a status report — it's an inspection of the actual product and a collaborative session to adapt the backlog.

### Structure

1. PO presents what was planned vs. what was completed 2. Team demonstrates each story (working software, not slides) 3. Stakeholders use / interact with the feature 4. Open discussion: Does this meet expectations? What needs adjustment? 5. PO updates the backlog based on feedback

### BA's Role in Sprint Review

Prepares the demo script: which user flows to show, what data to use
Facilitates the demo or co-presents with the developer
Captures feedback from stakeholders as new backlog items or AC changes
Translates technical findings into business language for non-technical attendees

Sprint Retrospective

The team reflects on how they worked — not what they built.

Duration: 1.5 hours (2-week sprint). Participants: Scrum team only (no external stakeholders).

### Classic Format: Start / Stop / Continue

Start: What should we begin doing that we aren't?
Stop: What should we stop doing that isn't helping?
Continue: What's working well that we should keep?

### Other Formats

4Ls: Liked, Learned, Lacked, Longed For
Sailboat: Wind (helps us), Anchor (slows us), Rocks (risks), Island (goal)
Mad / Sad / Glad: emotional temperature check

### BA's Role in Retrospective

Raise issues from a requirements/analysis perspective: "Stories were unclear at sprint start 3 times — can we improve our refinement process?"
Defend the process wins: "Our new DoR checklist caught 2 blockers before Sprint Planning — let's keep it."
Be open to feedback: "We got AC changes mid-sprint twice — can we lock down AC earlier?" is valid feedback for the BA.

The Analyst's Sprint Rhythm

Week 1:          | Week 2:
Mon: Planning    | Mon: Daily
Tue: Daily + dev | Tue: Daily + dev
    clarifications|     clarifications
Wed: Refinement  | Wed: Refinement
    (next sprint) |     (next sprint)
Thu: Daily       | Thu: Daily
Fri: Daily       | Fri: Review + Retro

Situation

A BA at a digital insurance company is preparing for Sprint 5 Review. The audience includes external stakeholders who are not in the day-to-day project work: the Chief Digital Officer (CDO), Head of Actuarial, and two representatives from a partner broker network.

The sprint delivered: online claim submission for motor insurance (photo upload, damage description, contact details).

BA's Preparation (Day 8-9 of Sprint)

### Demo Script

Demo Flow:
1. Open app as "Emma Thompson" (test customer)
2. Navigate to Claims → New Claim → Motor
3. Select "Accident" claim type
4. Upload 3 damage photos (pre-staged test photos)
5. Fill description and location (pre-filled with realistic data)
6. Submit — show confirmation screen with claim reference
7. Switch to admin view — show claim appearing in queue

Edge case to show: - What happens if a photo is too large? → Compression prompt - What if the customer exits mid-flow? → Draft saved, resumes from step 3 ```

### Stakeholder-Specific Talking Points

Stakeholder	What they care about	Prepared message
CDO	Customer experience, NPS	"3-screen flow, avg completion 4 minutes in usability tests vs 25 min phone call"
Head of Actuarial	Data quality for claims processing	"All fields validated before submission; GPS coordinates attached automatically"
Broker reps	Customer adoption	"Customers can submit 24/7; brokers receive claim notification within 60 seconds"

The Review Session

### What Went Well

The CDO was impressed: "This is exactly what we promised at the board meeting." The 4-minute completion time resonated strongly.

### Feedback Received

Broker rep feedback: "Our clients often submit claims from abroad. Can they upload international driving license photos?"

BA's immediate response: "That's not in scope for this sprint — international driving licenses have different formats which require additional validation. I'll create a backlog item for Sprint 7."

*(BA creates the item immediately in the tool during the meeting: "US-67: International driving licence support — upload and validate non-UK licence formats")*

Head of Actuarial feedback: "What if a customer submits the same accident twice? We need duplicate detection."

BA's response: "Good catch. We have basic duplicate prevention (same date + location within 500m), but if a customer submits from home vs accident scene, that won't catch it. I'll add a story for enhanced duplicate detection and schedule it for refinement next week."

### Stories Created from Feedback

New Story	Points	Sprint
US-67: International driving licence support	5	Sprint 7
US-68: Enhanced duplicate claim detection	8	Sprint 8
US-69: Claim submission status email to broker (not just customer)	3	Sprint 7

Post-Review Actions

1. BA updated the Product Backlog with 3 new items 2. BA sent meeting minutes to all attendees within 2 hours 3. BA scheduled a 30-min session with Head of Actuarial to refine US-68 acceptance criteria 4. BA flagged to PO: US-67 and US-69 may affect Sprint 7 capacity — need to re-prioritize

Key Takeaway

The Sprint Review is the most valuable stakeholder touchpoint in Agile. The BA's role is to make it efficient: clear demo, prepared talking points per audience, and immediate capture of feedback into actionable backlog items. A good Review turns stakeholder observations into Sprint 7 requirements before the team leaves the room.