Scrum doesn't require user stories, and since the Product Backlog is intrinsically ordered, 100% independence between items is not required. However, the underlying issue of how to estimate external dependencies is a valid one that is easier to resolve once you focus on level-of-effort rather than elapsed time.
The Definition of Done is not the same as your team's working agreement. It is how you know stories are complete. Regardless of how you handle external dependencies, it is more of a framework estimation/planning issue than a done/not-done issue.
Estimate only the level of effort required within the team to manage the external dependency. Everything else is a process issue, and will be covered below.
Scrum Doesn't Mandate User Stories or Complete PBI Independence
Tasks Needn't Be Stories
Scrum doesn't mandate use of the user story format. The Scrum Guide mentiones Product Backlog item(s) 25 times, but "user story" is not mentioned even once.
Even if the Scrum Team adopts the user story format for its Product Backlog, Sprint Backlog items don't have to be in the same format. In fact, most tasks on the Sprint Backlog should be decomposed from a related Product Backlog Item, and trying to coerce each task into a user story instead of a bullet point or checklist item may be overkill.
While user stories should be as independent as possible, the "independent" INVEST mnemonic is a best practice for the user story format rather than a specific framework requirement of Scrum. In a Scrum context, the goal of story independence is to maximize the ability of the Product Owner to reprioritize Product Backlog Items (PBIs), and to optimize the Development Team's ability to meet the Sprint Goal even if some items from the Sprint Backlog (SBIs or tasks) are blocked or incomplete.
In real-world Scrum implementations, tasks on the Sprint Backlog will often have dependencies and sequencing requirements. More specifically, reducing the dependencies between PBIs doesn't necessarily reduce dependencies within a user story. Furthermore, Scrum requires some level of central coherence, which is why the framework doesn't mandate a backlog free of all story dependencies. Scrum is, in part, the art of finding the right level of coupling between backlog items to create a coherent Sprint Goal while still allowing the backlog to be reordered between Sprints to adapt to changing requirements.
Handling Wait Tasks
An important aspect of story points, and of Scrum estimation in general, is that the primary metric is effort, not time. Therefore, I always coach that wait tasks (or stories that contain wait tasks) discount externalities outside the team provided the dependency will fit within a single iteration.
As a practical example, let's consider this user story about embiggening a widget taken from the Product Backlog:
As a widget consumer
I want an embiggened widget two orders of magnitude larger
so that I can more easily frobnicate the whatchamacallit.
When the Development Team selects this user story during Sprint Planning, the embiggening story is decomposed and the team does "just enough" planning to ensure the story is likely to fit within the current Sprint, and to add key tasks and dependencies to the Sprint Backlog. This story's tasks include:
- Ask Bob in Procurement to order a baker's dozen of standard widgets.
- Borrow a widget stretcher from Sally in Supply.
- Stretch the widget.
- Insert the newly-stretched widget in the whatchamacallit.
- Run the frobnication regression tests.
While the procurement process and the supply requisition are prerequisites for completing the story, the effort required for those tasks is essentially that of making a request. This likely a phone call or a bit of paperwork, and possibly a follow-up or two. Even though the Scrum Team should make those external dependencies visible, and the Development Team should track them within the Sprint, the Development Team's internal level of effort for those tasks is minimal.
Even if a team member must chase after Bob and Sally for days or weeks, the story should be estimating team effort, not time elapsed. If the story would be estimated at three points if the materials were on-hand, having to call or email someone outside the team to order equipment doesn't really add a measurable level of effort within the team, and is therefore a probably still a 3-point story. On the other hand, if someone on the team must prepare a 24-page business case before Bob or Sally will agree to make the necessary equipment available for the team, then that level of effort might turn a 3-point story into an 8- or 13-point story to reflect that the effort is internal to the team.
When to Isolate External Dependencies
In general, external dependencies can be written as low-effort tasks, and don't change estimates much. However, when the internal level of effort is large, or when the team isn't confident that an external dependency will fit within a single iteration, then the stories/tasks should be split and made as independent as possible. For example, the Scrum Team might develop a new user story for the Product Backlog that should be done a Sprint or two ahead of the embiggening story:
As a Development Team member,
I need to requisition a widget stretcher from Sally
so that we can embiggen a frobnicating widget in the whatchamacallit.
While the stories are related, this story can be delivered independently of the embiggening story. If they can be consolidated, great! But if not, isolating the requisition from the embiggening reduces uncertainty and makes it easier for the team to forecast when the work will be done.
Considering all the foregoing, I recommend the following:
- Estimate only the level of effort required by the Scrum Team.
- The expected time to complete an external task is only relevant if it puts the Sprint Goal at risk, or if the externality is likely to cross Sprint boundaries.
- Split all stories and tasks that will cross Sprint boundaries.
- Split off all stories and tasks that are "known unknowns" so that unavoidable dependencies can be re-evaluated at Sprint boundaries.
Should a Sprint Goal be unavoidably reliant on an external dependency, then that should be a visible risk for the Sprint. Scrum doesn't guarantee success of the Sprint; it simply makes the process and its artifacts transparent!