Skip to main content
Project Management

Return to Answer

Expand explanation.
Source Link
Todd A. Jacobs ♦
Todd A. Jacobs ♦
  • 50.7k
  • 7
  • 60
  • 181

Make External Dependency Management a Story

When a team has external dependencies, one way of making that work visible is to create a user story around managing that dependency. For example, using your example about needing a QA environment for deployments, you might create a story like the following.

As a Scrum Team Member,
I need to create and track a JIRA ticket for the ops team to stand up a production environment
so that we can deploy our finished increment at the end of the Sprint.

While the responsibility for actually deploying the new environment rests outside the team, someone on the team needs to make the request, follow up with the right people, and escalate the issue if it's not being addressed in a timely manner. That's all pretty straightforward, and you can certainly color-code your story card to make it stand out as an external dependency if you like.

WIP Limits for External Dependencies

A bigger issue is how to fit this within your work-in-progress (WIP) limits. A story like this is pretty small in terms of the Development Team's level of effort—not small in importance, but in terms of how much effort it consumes from the team's available capacity. Since it's a low-effort item, you could assign a half-point to it, in which case it remains blocked as WIP until done without creating a major queuing problem for other stories. For example, if your WIP limit is 6, and you have 0.5 points sitting in your "In Progress" queue, you still have 5.5 story points you can work on without violating your WIP limits.

There are certainly other ways to handle it, but in my experience most of them turn this type of external dependency into "invisible work." Since CodeGnome's Law of Transparency says "No invisible work, ever!" you can handle it any way you like, provided you don't sweep it under the rug or treat tracking it as an externality even when most of the work itself is external.

Managing Blocked Dependencies

If the work truly becomes blocked because the external resources aren't available or won't get to it within the current Sprint, then you need to work with the Product Owner to determine if the story is essential to the Sprint Goal. If not, pop it out of WIP and move on. If it is, then the Product Owner must decide whether it's scope that can be swapped out, or whether the Sprint must be terminated and the Scrum Team returned to Sprint Planning.

Either way, this is really no different than what happens when stories that are not externalities become permablocked within the current Sprint. You're simply applying the same principles of Sprint management to dependency stories, and ensuring that those dependencies remain visible.

Make External Dependency Management a Story

When a team has external dependencies, one way of making that work visible is to create a user story around managing that dependency. For example, using your example about needing a QA environment for deployments, you might create a story like the following.

As a Scrum Team Member,
I need to create and track a JIRA ticket for the ops team to stand up a production environment
so that we can deploy our finished increment at the end of the Sprint.

While the responsibility for actually deploying the new environment rests outside the team, someone on the team needs to make the request, follow up with the right people, and escalate the issue if it's not being addressed in a timely manner. That's all pretty straightforward, and you can certainly color-code your story card to make it stand out as an external dependency if you like.

WIP Limits for External Dependencies

A bigger issue is how to fit this within your work-in-progress (WIP) limits. A story like this is pretty small in terms of the Development Team's level of effort—not small in importance, but in terms of how much effort it consumes from the team's available capacity. Since it's a low-effort item, you could assign a half-point to it, in which case it remains blocked as WIP until done without creating a major queuing problem for other stories. For example, if your WIP limit is 6, and you have 0.5 points sitting in your "In Progress" queue, you still have 5.5 story points you can work on without violating your WIP limits.

There are certainly other ways to handle it, but in my experience most of them turn this type of external dependency into "invisible work." Since CodeGnome's Law of Transparency says "No invisible work, ever!" you can handle it any way you like, provided you don't sweep it under the rug or treat tracking it as an externality even when the work itself is.

Managing Blocked Dependencies

If the work truly becomes blocked because the external resources aren't available or won't get to it within the current Sprint, then you need to work with the Product Owner to determine if the story is essential to the Sprint Goal. If not, pop it out of WIP and move on. If it is, then the Product Owner must decide whether it's scope that can be swapped out, or whether the Sprint must be terminated and the Scrum Team returned to Sprint Planning.

Either way, this is really no different than what happens when stories that are not externalities become permablocked within the current Sprint. You're simply applying the same principles of Sprint management to dependency stories, and ensuring that those dependencies remain visible.

Make External Dependency Management a Story

When a team has external dependencies, one way of making that work visible is to create a user story around managing that dependency. For example, using your example about needing a QA environment for deployments, you might create a story like the following.

As a Scrum Team Member,
I need to create and track a JIRA ticket for the ops team to stand up a production environment
so that we can deploy our finished increment at the end of the Sprint.

While the responsibility for actually deploying the new environment rests outside the team, someone on the team needs to make the request, follow up with the right people, and escalate the issue if it's not being addressed in a timely manner. That's all pretty straightforward, and you can certainly color-code your story card to make it stand out as an external dependency if you like.

WIP Limits for External Dependencies

A bigger issue is how to fit this within your work-in-progress (WIP) limits. A story like this is pretty small in terms of the Development Team's level of effort—not small in importance, but in terms of how much effort it consumes from the team's available capacity. Since it's a low-effort item, you could assign a half-point to it, in which case it remains blocked as WIP until done without creating a major queuing problem for other stories. For example, if your WIP limit is 6, and you have 0.5 points sitting in your "In Progress" queue, you still have 5.5 story points you can work on without violating your WIP limits.

There are certainly other ways to handle it, but in my experience most of them turn this type of external dependency into "invisible work." Since CodeGnome's Law of Transparency says "No invisible work, ever!" you can handle it any way you like, provided you don't sweep it under the rug or treat tracking it as an externality even when most of the work is external.

Managing Blocked Dependencies

If the work truly becomes blocked because the external resources aren't available or won't get to it within the current Sprint, then you need to work with the Product Owner to determine if the story is essential to the Sprint Goal. If not, pop it out of WIP and move on. If it is, then the Product Owner must decide whether it's scope that can be swapped out, or whether the Sprint must be terminated and the Scrum Team returned to Sprint Planning.

Either way, this is really no different than what happens when stories that are not externalities become permablocked within the current Sprint. You're simply applying the same principles of Sprint management to dependency stories, and ensuring that those dependencies remain visible.

Source Link
Todd A. Jacobs ♦
Todd A. Jacobs ♦
  • 50.7k
  • 7
  • 60
  • 181

Make External Dependency Management a Story

When a team has external dependencies, one way of making that work visible is to create a user story around managing that dependency. For example, using your example about needing a QA environment for deployments, you might create a story like the following.

As a Scrum Team Member,
I need to create and track a JIRA ticket for the ops team to stand up a production environment
so that we can deploy our finished increment at the end of the Sprint.

While the responsibility for actually deploying the new environment rests outside the team, someone on the team needs to make the request, follow up with the right people, and escalate the issue if it's not being addressed in a timely manner. That's all pretty straightforward, and you can certainly color-code your story card to make it stand out as an external dependency if you like.

WIP Limits for External Dependencies

A bigger issue is how to fit this within your work-in-progress (WIP) limits. A story like this is pretty small in terms of the Development Team's level of effort—not small in importance, but in terms of how much effort it consumes from the team's available capacity. Since it's a low-effort item, you could assign a half-point to it, in which case it remains blocked as WIP until done without creating a major queuing problem for other stories. For example, if your WIP limit is 6, and you have 0.5 points sitting in your "In Progress" queue, you still have 5.5 story points you can work on without violating your WIP limits.

There are certainly other ways to handle it, but in my experience most of them turn this type of external dependency into "invisible work." Since CodeGnome's Law of Transparency says "No invisible work, ever!" you can handle it any way you like, provided you don't sweep it under the rug or treat tracking it as an externality even when the work itself is.

Managing Blocked Dependencies

If the work truly becomes blocked because the external resources aren't available or won't get to it within the current Sprint, then you need to work with the Product Owner to determine if the story is essential to the Sprint Goal. If not, pop it out of WIP and move on. If it is, then the Product Owner must decide whether it's scope that can be swapped out, or whether the Sprint must be terminated and the Scrum Team returned to Sprint Planning.

Either way, this is really no different than what happens when stories that are not externalities become permablocked within the current Sprint. You're simply applying the same principles of Sprint management to dependency stories, and ensuring that those dependencies remain visible.