HKSM

A technique to identify, classify, and document relationships among epics, user stories, tasks, and external deliverables that influence sequencing and coordination. It is used during backlog refinement, release planning, and sprint planning to expose internal, external, and cross-team dependencies and plan mitigations. The results guide ordering decisions, integration activities, and risk and impediment management.

Key Points

• Highlights relationships that affect the order and timing of backlog items.
• Covers internal, external, and cross-team dependencies, and whether they are mandatory or discretionary.
• Uses lightweight visuals such as dependency maps, matrices, tags on backlog items, and blockers on the Scrumboard.
• Supports splitting stories, creating spikes, using stubs or mocks, and planning integration points.
• Feeds release planning, sprint planning, risk register updates, and the impediment log.
• Handled collaboratively by the Product Owner, Scrum Master, and Development Team, and scaled via Scrum of Scrums when needed.

Purpose of Analysis

The goal is to make hidden couplings visible so the team can sequence work realistically, reduce waiting, and avoid rework. By surfacing dependencies early, the team can decide whether to remove them, mitigate them, or plan around them.

This analysis improves transparency for forecasting and coordination across teams and vendors and informs risk-based decisions about scope, timing, and integration.

Method Steps

1. Collect candidate items: gather prioritized user stories or epics targeted for the next release and upcoming sprint.
2. Scan for links: walk through each item’s workflow, data, interfaces, and acceptance criteria to spot potential dependencies.
3. Classify: mark each dependency as internal, external, or cross-team; and as mandatory or discretionary; note criticality and lead time.
4. Plan mitigation: choose actions such as re-ordering, splitting stories, introducing spikes, using mocks, or arranging integration handshakes.
5. Record: update the product backlog with dependency tags or a matrix/map; add blockers and actions to the impediment log if needed.
6. Adjust plans: refine release and sprint forecasts, sequence the Sprint Backlog, and set up integration tasks and test windows.
7. Monitor and escalate: review dependencies in Daily Scrum and, for multi-team work, in Scrum of Scrums; escalate unresolved external items.
8. Inspect and adapt: capture lessons in the Retrospective to reduce recurring dependencies in future sprints.

Inputs Needed

• Prioritized Product Backlog with epics and user stories, including acceptance criteria.
• Architecture and interface information, data contracts, and test environment availability.
• Team capacity, skills, and Definition of Ready and Definition of Done.
• External schedules such as vendor deliveries, compliance deadlines, and release windows.
• Existing risk register entries and the impediment log for historical blockers.

Outputs Produced

• Dependency map or matrix and annotated backlog items with dependency tags.
• Updated release plan and sprint forecast reflecting realistic sequencing and integration points.
• Refined Sprint Backlog with ordered tasks and identified blockers.
• New or split user stories and spikes to decouple work or reduce uncertainty.
• Risk register updates for external dependencies and entries in the impediment log with owners and due dates.
• Coordination agreements with other teams or vendors and scheduled integration tests.

Interpretation Tips

• Treat dependencies as risks with timing impact; consider probability, impact, and lead time.
• Prefer removal over management: split stories, isolate interfaces, and use mocks to decouple.
• Do not over-engineer; lightweight visuals and clear ownership are usually enough.
• Re-check dependencies whenever backlog items change or new information appears.
• Make external dependencies visible to stakeholders to set realistic expectations.

Example

While refining items for a release, the team finds a story that relies on a new payment API from another group. They label it as an external, mandatory dependency with a two-week lead time.

The Product Owner reorders the backlog so independent stories come earlier. The team creates a spike to design against a mock API and schedules an integration task for the sprint after the API delivery. The Scrum Master logs the dependency and coordinates with the other group via Scrum of Scrums.

Pitfalls

• Cataloging dependencies without assigning owners or follow-up actions.
• Assuming preferences are dependencies, leading to unnecessary sequencing constraints.
• Creating heavy Gantt-style networks that undermine agility and responsiveness.
• Ignoring lead times for approvals, environments, or vendor work until sprint start.
• Failing to revisit dependencies during the sprint, causing late surprises and spillover.

PMP/SCRUM Example Question

During backlog refinement, several Scrum Teams discover that multiple stories rely on a vendor API update expected next month. What should the Scrum Master facilitate first when applying dependency determination?

1. Add buffer to all sprints to absorb possible delays.
2. Extend sprint length to match the vendor’s schedule.
3. Identify and classify the dependencies, record them on a dependency map, and adjust ordering and mitigation actions.
4. Freeze scope until the vendor confirms a firm date.

Correct Answer: C — Identify and classify the dependencies, record them on a dependency map, and adjust ordering and mitigation actions.

Explanation: Dependency determination begins by surfacing and documenting the relationships, then planning sequencing and mitigations. Changing sprint length, adding buffers, or freezing scope are less appropriate first steps in Scrum.