Utilizing Resources Outside the Scrum Team

When you're building your Scrum team, sometimes it doesn’t make sense for a particular individual to be a member of the team. They may have a specialty that’s only needed occasionally by the team or may be too busy with other work to participate in regular Scrum ceremonies.

An “External Resource” May be the Answer

Being a member of a Scrum team means a person must attend all the various Scrum ceremonies, so they can stay up to speed with what’s going on and be empowered by having all relevant information. If that person only needs to contribute an hour or two a week of effort to the project, it likely doesn’t make sense for them to spend an average of 3 to 5 hours attending ceremonies.

Every person you add to the Scrum team means more time is required to keep everyone up to speed, so you’ll want to make sure the “juice is worth the squeeze,” as a business associate of mine likes to say. That is, ensure adding another full-fledged team member is worth the additional time it takes to get—and keep—that person up to speed.

When it doesn’t make sense to add a team member, the team can utilize the individual as what I call an external resource. An external resource is someone who helps the team complete the work in their sprint but is not a member of the team.

I use the word “external” to underscore that the individual—since they are not a member of the team—does not have ownership over getting things done. The responsibility of ensuring the external resource produces the desired result rests solely with the team.

This does introduce some light management responsibility into the Scrum team. Because the internal resource isn’t attending the Scrum ceremonies, they don’t have context about everything that’s going on. One or more team members need to direct the work of the external resource, since they are outside the self-organized Scrum team.

If you are not going to utilize a team member enough to offset the amount of time they’ll spend in Scrum ceremonies, consider utilizing them as an external resource instead.

Temporary Team Members

Sometimes a team finds they are spending a considerable amount of time coordinating with a particular external resource. If the resource is likely to be utilized for the majority of a sprint—or perhaps several sprints—the team should consider adding them as a temporary team member.

The temporary team member should get familiar with the work that’s coming up. Many teams hold a backlog refinement ceremony during one sprint, to prepare for the next. The temporary team member should attend backlog refinement before the sprint in which they’ll be involved, then attend every Scrum ceremony of the sprint.

They’ll be just like any other team member during that sprint. They’ll be fully informed about everything that’s going on, and they’ll be able to work more effectively.

Once the resource’s work slows down to the point where they are needed very little or not needed at all, they can roll off the team. It’s beneficial if you do not change the makeup of the team during a sprint. Wait for the time between sprints to change things up.

Types of External Resources

There are a few different types of external resources a Scrum team may want to utilize, including:

• User experience architects. If the application doesn’t have a sophisticated user interface or has just a few screens, it may make sense to utilize a user experience architect as an external resource.
• Visual designers. Similar to user experience architects, visual designers may not need to be on the development team for the duration of development.
• Database analysts. It’s not typical that you are going to require specialized database design work throughout the project. The development team can consult database analysts as needed when it makes sense.
• Enterprise architects. Architects who are responsible for the consistency of the technical infrastructure of all software applications in the company focus on the big picture, and it doesn’t make sense for them to be a full-time member of any particular development team. Instead, the team can consult the enterprise architect when they face technical decisions that may have far-reaching implications across multiple teams or multiple applications.
• DevOps personnel. Early in a project, the development team may need quite a bit of help from the DevOps team, to help them get various development and test environments set up. As a rule, DevOps specialists likely aren’t needed for the production of every story on the product backlog.

Estimating Time to Manage External Resources

When the team is planning the sprint, it’s important to reserve time on the sprint backlog to manage any external resources.

Keep in mind that this time shouldn’t include the time needed by the external resource to complete the work. It should only include time for the team to coordinate and review the work.

For example, if Jim in DevOps is going to need a solid day to create the new environment the team needs, but the team thinks they’ll spend only an hour working with Jim and verifying his work, they’ll put 1 hour as the estimate in their plan.

Using the Sprint Task Board to Manage External Resources

Since the team is responsible for coordinating with external resources, it’s imperative they don’t take a "fire and forget" approach, where they ask for help from the resource and forget all about it. Instead, I suggest the development team tracks the status of the work using the sprint task board and stay on top of the external resource.

As I discussed above, part of the plan should include a method to track the work needed from external resources on the sprint backlog. Since our teams use JIRA, we break down stories into subtasks. When work is going to be done by an external resource, we’ll add a subtask to track their progress.

Here’s how we use the sprint task board to stay on top of our external resources:

• When they are beginning their work—typically once the coordination has happened and the ball is in their court—we move the subtask to the In Progress column and add a comment explaining what activity has happened to handle the coordination. For example, "Spoke with Jim in DevOps about the new environment. He’s opened ticket number 2983 in their ticketing system and he says they should be able to complete it by the end of this week." Someone on the Scrum development team should put their name on the subtask at this point, to ensure everyone knows who is “owning” any on-going coordination. The ScrumMaster could handle this sort of coordination if they are willing to volunteer to take it on.
• Once the external resource has completed the work, the team needs to check it to make sure it is done correctly. At this point, we move the subtask to the To Verify column, again with a comment explaining the status. For example, "The new environment can be found at https://testenv1.mycompany.com and is ready for testing."
• The team reduces the remaining time on the subtask to reflect only the time needed to check the work. If everything looks good, the subtask is moved to “Done.” Otherwise, it’s moved back to “In Progress” and the team member who owns it goes back to the external resource to get the issues addressed.

Giving External Resources Advance Notice

If a development team assumes they can walk up to the DevOps team and say, “I need a new environment and I need it by tomorrow,” they may get laughed out of the room with a reply along the lines of, “How does three weeks sound?”

Realize that part of working with external resources is that they likely already have their plate full and they’ll need to fit your work into their overall to-do list.

If a team wants to ensure timely turn-around of the items for which they utilize external resources, it’s a good idea to give them a heads up. The ScrumMaster can help with this by ensuring the team looks ahead on the product backlog and thinks about the needs for the next sprint or two. The team can then give the external resources a heads up that they’ll need some help in a few weeks.

Providing advance warning if you need their help is a much better approach than expecting an immediate turn-around and failing to deliver the portion of the current sprint that has an external dependency.

Some Scrum teams will insist they resolve the external dependency first, before they take the related user story into a sprint. This is a fine approach, but might be too conservative in some cases, especially if the team has coordinated with the external resource and they feel comfortable about getting what they need.

While there are both pros and cons to having external resources take part in the work your Scrum team commits to, if managed effectively, they can prove to be a valuable asset in keeping your team on track.

What is your experience with building teams and leveraging external resources? Leave a comment for us below.

This article was previously published on the Ascendle Blog