Why this matters
As a Business Analyst, your user stories only deliver value if the right parts are built in the right order. Dependencies are the connections between stories, systems, data, and teams that can block delivery or cause defects if missed. Identifying them early helps you plan sprints, write realistic acceptance criteria, and prevent rework.
- Release planning: sequence stories so blockers are resolved first.
- Acceptance criteria: capture preconditions and integration expectations.
- Risk management: make technical, legal, or vendor dependencies visible.
- Stakeholder alignment: clarify who must deliver what and when.
Quick test is available to everyone; log in if you want your progress saved.
Concept explained simply
A dependency is anything your story needs from somewhere else to succeed. It could be another story, a service, data, an approval, or a person.
Common dependency types
- Upstream vs. downstream: upstream provides inputs; downstream consumes your outputs.
- Internal vs. external: your team vs. another team/vendor.
- Technical: APIs, data models, infrastructure, environments.
- Business/process: policy changes, approvals, support coverage.
- Regulatory/legal: compliance reviews, consent, audit logging.
- Shared resource: design, QA, security, data platform, environments.
- Blocking vs. sequencing: blocking prevents start; sequencing orders for efficiency or value.
Mental model
Think of your story as a small machine with inputs and outputs. To find dependencies, ask: Who supplies my inputs? Who relies on my outputs? What rules or constraints must be true before this machine can work?
Step-by-step: identify dependencies fast
- Clarify the outcome and boundary: one-sentence story goal and what is in/out of scope.
- Map producers and consumers: list input providers (data/services/teams) and output consumers (users/systems/reports).
- Classify the dependency: type (technical/business/regulatory), location (internal/external), and impact (blocking/sequence).
- Translate into acceptance criteria: write preconditions, integration behaviors, and error handling as Given/When/Then.
- Plan sequencing and visibility: create follow-up stories/tasks and add dependency notes or tags on the story.
Discovery prompts (use during refinement)
- Which API, data source, or event must exist before we can start?
- What environments, credentials, or feature flags are required?
- Do we need legal/security review or updated terms/consent?
- Which teams must deliver something? Whatâs their capacity/lead time?
- What happens if upstream is late? Do we need mocks or toggles?
- How will we verify integration in test and production?
Worked examples
Example 1: Email receipt after payment
Story: As a customer, I want an email receipt after successful payment so I can keep a record.
- Upstream: Payment gateway returns success and transaction ID.
- Upstream: Email template from Marketing is approved.
- Technical: Email service credentials and rate limits.
- Regulatory: Include required business info and unsubscribe footer (if applicable).
Acceptance criteria fragments:
- Given payment gateway returns success, When receipt is generated, Then email is sent within 60 seconds with transaction ID.
- Given email service is unavailable, When retry policy is applied, Then system retries up to 3 times and logs failure.
- Given template version 3 is approved, Then send using template v3.
Example 2: Mobile app needs new API
Story: As a user, I want to see my loyalty points in the app.
- Blocking upstream: Loyalty API endpoint /v2/points must exist with auth scopes.
- Internal sequencing: Design system component for points badge.
- Shared resource: Mobile release train every 2 weeks.
Acceptance criteria fragments:
- Given user is authenticated with scope loyalty.read, Then app displays balance within 2s with caching.
- Given API returns 429, Then app shows non-blocking error and retry CTA.
- Feature is behind flag loyalty_points; default off.
Example 3: Data migration
Story: As an analyst, I want legacy orders migrated so reports remain accurate.
- Upstream: Read access to legacy DB snapshot.
- Technical: Mapping of legacy statuses to new schema.
- Business: Sign-off from Finance on reconciliation thresholds.
Acceptance criteria fragments:
- Given migration completes, Then order counts match within ±0.1% per day.
- Given unmapped status, Then record is quarantined and reported.
- Audit log contains user, timestamp, batch ID.
Turning dependencies into acceptance criteria
Translate each identified dependency into concrete testable statements.
- Preconditions: feature flags, approvals, data availability.
- Integration behavior: request/response, retries, timeouts, error paths.
- Validation: logging, metrics, audit events, monitoring alerts.
- Fallbacks: graceful degradation when upstream fails.
Template you can copy
Given [dependency precondition], When [trigger], Then [expected outcome], And [error/fallback behavior], And [observability/assertion].
Quick checklist
- Outcome and scope are clearly stated.
- All inputs (data/services/approvals) are listed with owners.
- All outputs (users/systems/reports) are listed with consumers.
- Each dependency is classified and marked blocking or sequencing.
- Acceptance criteria include preconditions, errors, and observability.
- Feature flags, mocks, or toggles defined where helpful.
- Follow-up tasks/stories created for unresolved dependencies.
Who this is for
- Business Analysts, Product Owners, and Analysts collaborating with engineering.
- Junior to mid-level professionals writing user stories and grooming backlogs.
Prerequisites
- Basic user story writing (As a..., I want..., so that...).
- Familiarity with acceptance criteria and Given/When/Then format.
- High-level understanding of your productâs systems and teams.
Learning path
- Practice the 5-step dependency identification on two existing stories.
- Add dependency-driven acceptance criteria to those stories.
- Run a 15-minute dependency review in your next refinement.
- Create follow-up tasks and plan sequencing across the next 2 sprints.
Exercises
Exercise 1: Invoice PDF download
Mirror of Exercise ex1 in the Exercises panel below.
Exercise 2: Add Google OAuth
Mirror of Exercise ex2 in the Exercises panel below.
Common mistakes and how to self-check
- Only listing technical APIs: include business approvals, legal reviews, and shared resources. Self-check: Is there any non-engineering team involved?
- Not marking blocking vs. sequencing: treat everything as equal. Self-check: Which items prevent starting vs. just change order?
- Vague acceptance criteria: missing timeouts, retries, or error states. Self-check: Can QA test failure cases without guessing?
- Ignoring environments: missing test data, credentials, or sandbox access. Self-check: Can we run this in staging today?
- No observability: hard to verify integration. Self-check: What logs/metrics prove it works?
Practical projects
- Story dependency map: pick a feature and build a one-page map listing upstreams, downstreams, owners, and risks. Add acceptance criteria snippets.
- Mock-first delivery: propose feature flags and API mocks for one story to decouple teams. Document in acceptance criteria.
- Risk-based sequencing: re-order 6 stories based on blocking risks and lead times; justify the sequence in one paragraph.
Mini challenge
Timebox 15 minutes. Choose any story from your backlog. Identify 5 dependencies, mark each as blocking or sequencing, and add 3 acceptance criteria that cover at least one failure path and one observability check. Share with your team for feedback.
Next steps
- Apply this process to your next refinement session.
- Keep a living dependency log for complex features.
- Use the quick test to validate your understanding before moving on.