HKSM

Updated Dependencies is the living list of current sequencing, blocking, and integration relationships among epics, user stories, and tasks. It is refreshed whenever new information emerges and is used to guide backlog ordering, sprint commitments, and cross-team coordination.

Key Points

• Captures the latest known relationships that affect the order or feasibility of work.
• Continuously maintained across refinement, release planning, sprint planning, Daily Standup, and reviews.
• Informs Product Owner prioritization and team commitments by exposing blockers and enablers.
• Links to the Sprint Backlog, Scrumboard, Impediment Log, and Risk Register for transparency.
• Includes both internal (within team) and external (vendors, other teams, compliance) dependencies.
• Serves as an output of planning and coordination events and as an input to future planning and sequencing.

Purpose

Updated Dependencies ensures the team and stakeholders see what must happen first, what can proceed in parallel, and where waiting time may occur. By making dependencies explicit, the team can reduce surprises, lower handoff delays, and plan work that is truly deliverable within the sprint or release.

It supports sustainable flow by enabling early mitigation actions, such as creating enablers, negotiating contracts, or coordinating with other teams.

Key Terms & Clauses

• Internal vs. External: Dependencies within the same team versus those involving other teams, vendors, or third parties.
• Upstream vs. Downstream: The predecessor work item and the successor that is affected by it.
• Mandatory (hard) vs. Discretionary (soft): Technically required order versus preferred sequencing for efficiency or learning.
• Enabler: A story or task created to satisfy a prerequisite (e.g., API stub, data setup) for a higher-value item.
• Lead/Lag: Time advance or delay needed between related items to avoid conflicts or waiting.
• Interface/Contract Clauses: Agreements on APIs, data formats, compliance gates, or approvals that create timing constraints.

How to Develop/Evaluate

• Identify during refinement and planning by asking structured prompts: What must exist first? Who else is involved? What decisions or artifacts are missing?
• Record each dependency with item IDs, type (internal/external, hard/soft), owner, due date, and impact if unmet.
• Validate with stakeholders and owners; confirm feasibility windows, SLAs, and acceptance criteria dependencies.
• Visualize on a dependency map or annotate the Scrumboard and backlog items for easy discovery.
• Reassess at Daily Standup and Scrum of Scrums; update status, escalate to Impediment Log if blocking.
• Review after each sprint to retire resolved links and add new ones from feedback or emerging scope.

How to Use

• Release Planning: Sequence epics and large features; adjust the Release Planning Schedule and milestones based on external constraints.
• Backlog Refinement: Reorder the Prioritized Product Backlog and split stories to decouple hard dependencies where possible.
• Sprint Planning: Select only work that can be completed; add enabling stories or tasks to clear critical predecessors.
• Daily Coordination: Track dependency progress; raise risks, create spikes, or mock services to keep flow.
• Risk and Impediment Management: Link high-impact dependencies to the Risk Register and move active blockers to the Impediment Log with owners.
• Scaling: Use Scrum of Scrums to manage cross-team dependencies and align integration points and cadences.

Example Snippet

• ID: DEP-07.
• Upstream: US-012 Create payment API stub (enabler).
• Downstream: US-024 Process card payments.
• Type: Internal, mandatory, finish-to-start; lag 0 days.
• External Constraint: Vendor certificate approval (SLA 3 business days).
• Owner: API team lead; Status: In progress; Impact if unmet: Delay downstream story, potential sprint spillover.
• Mitigation: Add mock service for early integration; schedule approval request on Day 1.

Risks & Tips

• Risk: Hidden external approvals cause last-minute blocks. Tip: Surface compliance and vendor SLAs during refinement.
• Risk: Overcommitment on blocked stories leads to carryover. Tip: Commit only to work with cleared predecessors or add explicit enablers.
• Risk: Dependency sprawl reduces autonomy. Tip: Decouple via API contracts, feature toggles, mocks, and vertical slicing.
• Risk: Stale documentation. Tip: Update the dependency list in each planning and confirm changes in Daily Standup.
• Risk: Poor ownership of cross-team work. Tip: Assign a named owner and due date; escalate unresolved items to Scrum of Scrums.
• Risk: Unclear impact. Tip: Tag each dependency with value at risk and time sensitivity to aid prioritization.

PMP/SCRUM Example Question

During Sprint Planning, the team discovers a previously unknown external approval needed before starting a high-value story. What should the Scrum Master and Product Owner do next?

1. Keep the story in the sprint and start it later once the approval arrives.
2. Record the item in Updated Dependencies, adjust the Sprint Backlog by selecting alternative stories or adding an enabling task, and communicate the change.
3. Ask the Scrum Master to remove the impediment immediately and still commit to the original plan.
4. Extend the sprint length to accommodate the approval lead time.

Correct Answer: B — Record the dependency, re-plan scope with enablers or alternatives, and communicate.

Explanation: Newly found dependencies must be captured and used to re-plan realistic work. Committing to blocked items or changing sprint length is not appropriate.