Tasks that need to be done by resources outside the agile scrum dev team

Question

How do I represent and make visible the work teams/staff outside of the dev team have to do e.g. setup environments for our software to be deployed into.

Answer 1

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.

Answer 2

Preferably, you bring those tasks onto the team, but I understand that's not always possible. (Politically, at least, of course it's always possible; sometimes there's just an irrational resistance...)

My team uses pink stickies tacked to our cards that are blocked by external dependencies. Believe me, that blazing hot pink is highly visible. If you have lots of these, consider creating a dependency map near your work board. If you're virtual, most tools have an equivalent of our pink stickies. Jira calls it "impediment". They're infinitely less visible in an electronic backlog though.

Another great method is to "walk the board" from "just got done" to "just got started" at your stand up. Be sure to talk about every card in progress. The team will get pretty sick of talking about that card blocked by external team X and take matters into their own hands quickly enough...