Blog

• ~5 min read • Agile BA Discovery Requirements

When I first moved into Agile projects, I thought I could simply “do the same BA work, but in sprints.” I quickly learned that Agile Business Analysis isn’t just a different pace — it’s a different mindset.

In traditional projects, requirements are often treated as a one-time event: gather upfront, document in detail, hand over to delivery. In Agile, that approach falls apart fast because we’re building while we’re learning. Business needs evolve, market conditions change, and what seemed “right” in week one may be irrelevant by week six. That’s where continuous discovery comes in.

From One-Time Requirements to Continuous Discovery

Agile BAs don’t just “write requirements” — we stay embedded in the flow of discovery and delivery. Instead of one big phase, we:

  • Collaborate with stakeholders regularly to refine understanding.
  • Break large ideas into smaller, testable pieces.
  • Validate assumptions early and often.

It’s a constant loop of learn → adapt → deliver.

What Continuous Discovery Looks Like in Practice

  1. Start with the problem, not the solution. Who’s affected? What’s the value at stake?
  2. Co-create user stories and acceptance criteria. Devs, testers, and stakeholders contribute early.
  3. Keep documentation light but useful. Story maps (Miro), lightweight flows, living Confluence pages.
  4. Validate early with real users. Demos, prototypes, and usability sessions — before UAT.

Balancing Agility with Traceability

In enterprise/regulated contexts, we don’t abandon traceability. We integrate it: link Jira stories to decision logs, keep acceptance criteria close to test cases, and avoid a “separate compliance phase.”

The Agile BA’s Superpower

Our value isn’t perfect documentation — it’s asking the right questions at the right time, connecting the what to the why, and making sure the how makes sense.

Final Thought

Agile isn’t about working faster — it’s about embracing change, staying curious, and delivering value continuously. Keep discovery alive from the first idea to the final release — and beyond.

👉 See related artefacts on my Business Analysis portfolio.

• ~4 min read • Career Enterprise Delivery

I started in operations — coordinating linehaul, improving on-time delivery, and solving day-to-day logistics problems. That hands-on exposure to bottlenecks, data, and process variation made the jump to Business Analysis a natural step: the same instincts, applied to systems and change.

What Operations Taught Me

  • Outcome focus: SLAs and customer impact sharpen prioritisation.
  • Data first: Throughput, dwell time, and exceptions drive decisions.
  • Change on the ground: The best process is the one people actually use.

Crossing into BA

I formalised the toolkit — requirements elicitation, BPMN, user stories, UAT — and applied it to enterprise programs. The shift wasn’t from “ops to IT”; it was from firefighting to designing better systems.

Enterprise Separation: A Defining Project

On a $500M divestiture, I helped separate critical applications and retire redundant ones with 99.9% uptime during cutover. My work spanned application portfolio analysis, BPMN for critical flows (job management, invoicing, inventory), and cutover runbooks with clear go/no-go criteria — all documented and traceable in Confluence/Jira.

Advice if You’re Making the Shift

  1. Start with problems, not solutions — frame value and constraints.
  2. Make work visible — story maps, process maps, and decision logs.
  3. Validate early — short feedback loops beat assumptions.

Discussed on LinkedIn; the canonical, maintained version lives here for SEO and artefact access. Join the discussion on LinkedIn.

👉 Explore related case studies on my Business Analysis portfolio.