BA Playbook
The Requirement Changed Mid-Sprint. Now What?
Don't just update Jira. Find the blast radius first.
Surya · August 13, 2026 · 3 min read · 8 practices
For Business Analysts handling a requirement change after a sprint has already started, Freshers and aspiring BAs learning that "I'll update Jira" isn't the right first move, QAs and developers who need the blast radius mapped before they touch code or test cases and Delivery leads and Product Owners deciding whether to absorb, split, swap, defer or stop the work.
The sprint is running. Development has started. QA has prepared the test cases. Then someone says: "We need one small change." If you've worked on a project long enough, you know what usually comes next. The change may be small. The impact may not be. Here's the requirement. Imagine an e-commerce platform. The original requirement says: orders above ₹50,000 require additional customer verification. The BA writes the acceptance criteria. Development starts. QA prepares the scenarios. Three days into the sprint, the business says: "Change ₹50,000 to ₹25,000." Then: "And international customers should require verification regardless of order value." Two sentences changed. Should the BA simply update Jira? No — because the requirement changed in one place. The impact may have changed in ten. Your first question shouldn't be "What should I change in the story?" Ask: "What does this change touch?" Think of it as the blast radius: Requirement → Business Rules → UI / API / Data → Dependencies → Development → Testing → Release. The BA's job is to understand that radius before the team commits to the change.
01Step 01
CHANGE — What exactly changed?
Get the new rule completely clear before you analyse anything.
Step 01
CHANGE — What exactly changed?
Get the new rule completely clear before you analyse anything.
Now the questions start. Does ₹25,000 mean above ₹25,000 or ₹25,000 and above? What happens at exactly ₹25,000? What makes someone "international" — nationality, billing country, shipping country, or account registration? One sentence can hide several decisions.
Old rule → New rule
At a glance
- Does the threshold mean strictly greater than, or greater-than-or-equal?
- What happens at exactly the boundary value?
- What definition of "international" is the business actually using?
Why it helps
Before analysing impact, make the behaviour precise — an ambiguous rule produces an ambiguous impact analysis.
02Step 02
WHY — Why now?
This question changes the decision, not the requirement.
Step 02
WHY — Why now?
This question changes the decision, not the requirement.
Same change. Different urgency. Ask "why does this need to change now?" — not to challenge the stakeholder, but to understand the constraint.
At a glance
- Compliance introduced a mandatory rule — delaying may not be possible.
- A stakeholder changed a preference — it may be safe to wait.
- The original requirement was wrong — existing development may already be incorrect.
- Production exposed a risk nobody considered.
Why it helps
Urgency changes which options are even on the table in step 5.
03Step 03
BLAST RADIUS — What else moves?
Don't stop at the Jira story. Trace the change through the system and delivery chain.
Step 03
BLAST RADIUS — What else moves?
Don't stop at the Jira story. Trace the change through the system and delivery chain.
The flow
At a glance
- Business rules — the threshold changed, and international customers now have an additional rule.
- UI — does the customer see a verification message, and does the wording change?
- API — is the threshold sent to another service? Does an API now need country information?
- Data — is customer country available, reliable and defined consistently?
- Rules / configuration — is ₹50,000 hardcoded, or is the rule configurable?
- Downstream systems — do Fraud, Risk, CRM, Operations or other systems consume the verification result?
- Testing — old scenarios may now be wrong; new boundary and exception cases are needed.
- Analytics and documentation — do reports, support procedures or operating guides still use the old rule?
Why it helps
"Change ₹50,000 to ₹25,000" isn't one change anymore once you trace it — that's impact analysis.
04Step 04
EFFORT — What's already built?
Don't estimate impact from the Jira ticket alone — talk to the people closest to the impact.
Step 04
EFFORT — What's already built?
Don't estimate impact from the Jira ticket alone — talk to the people closest to the impact.
Compare
If it's configurable
"It's configurable. Five-minute change." Great.
If it's hardcoded in three places
"The threshold is used in three services and two are already complete." Different conversation.
At a glance
- Ask Development how much of the original rule is already implemented.
- Ask QA which scenarios are already prepared or executed.
- Ask affected teams whether anything downstream depends on the original behaviour.
Why it helps
The same requirement change can mean five minutes or three days — and only the people building it know which.
05Step 05
OPTIONS — How should we handle it?
A BA adds value by bringing options, not just forwarding the change.
Step 05
OPTIONS — How should we handle it?
A BA adds value by bringing options, not just forwarding the change.
At a glance
- Absorb — the change is small, understood and safely fits the sprint. Do it now.
- Split — keep the original scope and create a separate story for the new behaviour. Deliver incrementally.
- Swap — the change matters but adds effort. Remove something else of similar effort. Protect capacity.
- Defer — the change is valid but not urgent enough to disturb current delivery. Move it to the next sprint.
- Stop & Rework — the new requirement makes current work wrong, unsafe or pointless. Stop, reassess and rework.
Why it helps
The BA may not make the final decision. But the BA should make the options and consequences visible.
06Step 06
DECISION — Who accepts the consequence?
Someone needs to decide — and discussion isn't ownership.
Step 06
DECISION — Who accepts the consequence?
Someone needs to decide — and discussion isn't ownership.
Checklist
- Who requested the change?
- Who assessed the impact?
- Who accepted the delivery consequence?
Why it helps
Depending on the organisation, that decision may involve Product, Business, Engineering, QA, Delivery, Risk, Compliance or Operations — naming who made it prevents the "who approved this?" conversation later.
Pro tip — A dangerous outcome is: "We discussed it, so we assumed everyone agreed." Discussion isn't ownership.
07Step 07
TRACE — Update the source of truth
Now update Jira. Not before.
Step 07
TRACE — Update the source of truth
Now update Jira. Not before.
Checklist
- Requirement — make old and new behaviour unambiguous
- Acceptance criteria — add thresholds, boundaries and exceptions
- Test cases — reflect the new behaviour
- Dependencies — link affected APIs, services, teams or stories
- Design / documentation — update anything people will rely on later
- Decision record — capture why the change happened and who agreed
Why it helps
You don't need a 12-page change document. You need enough history so that three months later someone can answer "why does the system behave like this?"
08Step 08
COMMUNICATE — Tell everyone whose work changed
Updating Jira doesn't mean everyone will notice.
Step 08
COMMUNICATE — Tell everyone whose work changed
Updating Jira doesn't mean everyone will notice.
Tell the people whose work changed: Developer, QA, Product, Delivery, Operations, Support and downstream teams. Communicate the change and consequence, not merely that a ticket was updated.
The shift
Why it helps
Clarity beats assumption.
A two-line requirement change
can create a twenty-item delivery change.
Requirements changing mid-sprint isn't automatically a failure — new information appears, assumptions turn out to be wrong, regulations change. The dangerous part is treating a requirement change like a text edit. Find the blast radius. Make the decision visible. Then change the requirement.
Free Mid-Sprint Change Toolkit
The change may be small. The impact may not be.
Get the printable checklist, editable impact note template and two completed examples.
Download the Complete Toolkit
Take this with you
Mid-Sprint Change Note
MID-SPRINT CHANGE NOTE CHANGE Old behaviour: New behaviour: Thresholds / boundaries: Exceptions: WHY NOW Regulatory / defect / new information / stakeholder preference / production risk: BLAST RADIUS TOUCHED [ ] Business rules [ ] UI [ ] API [ ] Data [ ] Config [ ] Dependencies [ ] Testing [ ] Docs EFFORT What's already built: What Dev / QA must redo: DECISION Option chosen: Absorb / Split / Swap / Defer / Stop & Rework Requested by: Assessed by: Accepted by: COMMUNICATED TO [ ] Developer [ ] QA [ ] Product [ ] Delivery [ ] Ops / Support [ ] Downstream teams
Get new playbooks first.