HKSM

Dependencies are relationships where one backlog item, task, or deliverable relies on another to be available or completed. In SBOK, they are identified, tracked, and coordinated to order work, reduce blockers, and align teams across sprints and releases.

Key Points

• Represents prerequisite or sequencing relationships between epics, user stories, tasks, or external deliverables.
• Captured during backlog creation and refinement, and revisited in Sprint Planning and Scrum of Scrums.
• Used to order the product backlog when necessary, but value and risk still drive prioritization.
• Cross-team and external dependencies are surfaced as risks or issues and tracked visibly.
• Helps the team avoid over-commitment by selecting only ready, unblocked work.
• Acts as an input to Create Sprint Backlog and Scrum of Scrums, and an output from Create User Stories and Create Tasks.

Purpose

Dependencies exist to make sequencing clear, prevent avoidable blockers, and improve coordination. When managed well, they reduce waiting time, stabilize flow, and enable predictable delivery.

They also expose coupling early so the team can split work vertically, add stubs or feature flags, or negotiate integration points before committing.

Key Terms & Clauses

• Internal vs. external: Internal is within the same team; external involves another team, vendor, or system.
• Cross-team: Dependencies between two or more Scrum Teams working on the same product or release.
• Upstream vs. downstream: Upstream work must be done first; downstream work is affected by the upstream item.
• Finish-to-start (FS) and start-to-start (SS): Common simple relationship types for planning conversations, not for creating detailed Gantt charts.
• Blocked/unblocked: Current execution status due to unresolved dependency.
• Definition of Ready clause: Examples include “no unresolved external dependency” or “integration plan identified.”

How to Develop/Evaluate

• Identify during user story workshops and refinement: ask what must exist first, who provides it, and what integration is needed.
• Classify by type (internal, cross-team, external) and by relationship (FS, SS), and estimate lead times.
• Reduce or remove: split stories vertically, create spikes, use mocks/stubs, apply feature toggles, or pull integration earlier.
• Record clearly: link items in the product backlog, note owners and dates, and reflect high-risk items in the Risk Register.
• Validate readiness before Sprint Planning using Definition of Ready and acceptance criteria for integration points.
• Review cross-team items in Scrum of Scrums and agree on synchronization points and responsibilities.

How to Use

In SBOK processes, dependencies are:

• An output from Create User Stories and Create Tasks, where relationships and sequence are discovered.
• An input to Approve, Estimate, and Commit User Stories and Create Sprint Backlog, influencing what can be pulled into the sprint.
• Actively managed during Conduct Daily Standup and Scrum of Scrums to surface blockers and coordinate teams.
• Referenced during Groom the Prioritized Product Backlog and Conduct Release Planning to refine ordering and integration milestones.
• Escalated to the Issues Log or Risk Register when external or time-sensitive, with owners and mitigation actions.

Example Snippet

• US-45 Payment as a user I can pay with credit card — depends on Team B’s API v2 (external, FS); mitigation: sandbox stub; target integration: Sprint 6.
• US-52 Audit log — start-to-start with US-50 Auth refactor (internal, SS); plan: enable feature flag; owner: Dev Lead.
• Task T-110 Migrate schema — upstream of T-118 Data seeding (internal, FS); buffer: 1 day for review.

Risks & Tips

• Hidden dependencies cause spillovers and thrash; visualize them on a dependency board or within backlog tooling.
• Over-sequencing can slow delivery; favor vertical slices and incremental integration to cut ties.
• External dependencies carry schedule risk; create early spikes and agreements with clear dates and owners.
• Make “no unresolved external dependency” part of Definition of Ready, or explicitly track exceptions with mitigation.
• Use mocks, stubs, and feature toggles to decouple development from integration timelines.

PMP/SCRUM Example Question

During Sprint Planning, the team finds a high-value user story that depends on a vendor API scheduled for release next sprint. What should the Scrum Master recommend?

1. Commit to the story now and finish it once the vendor releases the API.
2. Split the story to decouple the dependency, use a stub or defer the blocked part, and select only ready items.
3. Extend the sprint length so the dependency is no longer an issue.
4. Change the Definition of Done to allow incomplete integration for this sprint.

Correct Answer: B — Split the story to decouple the dependency, use a stub or defer the blocked part, and select only ready items.

Explanation: The team should avoid committing to unresolved external dependencies. Decoupling and selecting ready work preserves focus and predictability without changing timeboxes or lowering quality.