External Dependencies
Work that the Scrum Team relies on but that is owned, performed, or delivered by people or systems outside the team. These outside tasks, services, or deliverables are required to complete the team’s work, yet they are typically beyond the team’s direct control.
Key Points
- Arise when progress depends on vendors, other internal teams, regulators, or third-party systems.
- Cannot be fully planned or changed by the Scrum Team alone; require coordination, agreements, and lead time.
- Should be identified early, made visible on boards/backlogs, and tracked with clear owners, dates, and risk status.
- Mitigation includes SLAs, integration plans, buffers, fallback options, and frequent communication with external parties.
Example
A Scrum Team building a payment feature must integrate with a bank’s API. The bank needs two weeks to enable a sandbox account. The team marks this as an external dependency, coordinates dates with the bank, plans other work in the interim, and tracks the dependency and risk.
PMP Example Question
During Sprint Planning, the team learns a feature depends on a third-party API update that will be delivered next month. What should the Scrum Team do first?
- Add the third-party work to the Sprint and commit to finishing it now.
- Record it as an external dependency, coordinate dates with the external owner, plan unblocked work, and track the risk.
- Add more developers to remove the dependency.
- Cancel the Sprint until the API is ready.
Correct Answer: B — Manage the external dependency through coordination and plan around it
Explanation: The work is outside the team’s control, so the team should make the dependency visible, coordinate with the external party, adjust plans to avoid blockage, and monitor the risk.
