10

In a Scrum team, what do you do with stories that require work to be done by another team?

The work required of the other team could be well defined and in parallel: "We'll do this, and we want you to do that." Or it could be that we're asking the other team to engage with us in the development process - discovering requirements and impacts, planning, validating, and then delivering.

The team being autonomous requires that the team is trusted to deliver its stories within the sprint. So the team sizes its stories to the size it can deliver within one sprint, and then takes responsibility for delivering it. But when the team depends on another team, the other team may not start work at the same time, and even if it works efficiently, its work may end up crossing the boundary of a single sprint. If they are not efficient, their work, even though appropriately sized for a sprint, may not be delivered within the time of one sprint, for example if they have competing priorities and other work in progress.

It seems that by depending on another team, our team has lost its autonomy, and can't be trusted to, or held responsible for, delivering the stories. Can it still be called a Scrum team then? But surely Scrum teams do depend on other parties all the time? How should the team manage these dependencies?

8

A Scrum Team should be cross-functional, meaning that they have all of skills needed to deliver a valuable feature to completion, which ideally means production. This means that a Scrum Team nearly never needs another team to complete an item. However, there are two exceptions:

1) Even though your team might be able to deliver a valuable feature, other teams may be delivering related features so even though their work shouldn't be required for your team to successfully complete their feature, you still want to track it. A common way to do that is to have an over-arching board that tracks major feature sets or epics or whatever you want to call them. It can be a simple sticky-note board. For each large item, have a copy of the smaller parts that teams are working on next to in in a few columns - probably something simple like "Not Starting - In Sprint - Delivered".

2) Flukes - as much as cross-functional teams shouldn't have dependencies, it happens from time to time, but it should happen so infrequently that it really doesn't matter how you handle it. Write a note, wing it, whatever works for you. If it happens enough that the minor inefficiencies have an impact, you should be addressing the cross-functionality problem. If you're doing the first item anyway, that can be a convenient way to handle this circumstance.

A word of warning: Scrum is easy to game. If people are determined to split work and organize teams in the old paradigms, it's easy to use scrum terms and pretend to be agile, but you won't get the benefits out of it.

| improve this answer | |
  • We had one slip for three cycles because the the team that owns the codebase for another product that had to change in tandem to deliver a requested feature was trying to block the corresponding change. My team was cross-capable but I should not abuse my server-admin privileges to override the review process and push into the other team's codebase despite guaranteed review failure. – Joshua Sep 9 '19 at 1:58
  • What about databases? Many companies have central database team. Should they abandon it? How do they make sure then to have a stable and secure database? – J Fabian Meier Sep 9 '19 at 13:16
  • @Joshua I wish I could answer that question. I've seen many teams work through situations that could be described the same way, but in each case the circumstances were a bit different and the right solution for them was different. Sometimes it's a matter of breaking down code ownership silos, sometimes it is focusing on fewer things or aligning focus, sometimes it's about decoupling pieces of code, or even introducing things like feature flags. I'm confident your organization can work through those challenges but I have no way to say what the solution for you is. – Daniel Sep 10 '19 at 19:52
  • 1
    @J. Fabian Meier - For most companies, the answer to that question is an emphatic yes. Many companies move toward a model of having a forum for experts as well as people interested in a particular skillset to establish guide-rails to make good decisions around database design (or other skills). If a core part of your business is effective use of databases (if you are a data analytics company for example) then it's worth it to have deep DB skills on every team. There are incredibly rare exceptions but many times the answer is yes. – Daniel Sep 10 '19 at 19:55
4

Scrum teams can encounter external dependencies, but as you rightly say they often adversely impact on the capability of the team.

I would recommend that every time a dependency occurs, the team asks the question: "What can we do to avoid this kind of external dependency happening?"

There are several ways this question might be answered, including:

  • Is more training required?
  • Does the composition of the teams need to change?
  • Would knowledge transfer help?
  • Do we need to be more careful with our planning?

When you do have external dependencies I would caution you against trying to manage them in a time-based fashion, by saying things like: "This story is a dependency for team X, so we need to complete it this sprint".

A better approach is to manage the dependencies using priorities. For example: "This story is a dependency for team X, so we are going to raise its priority".

This avoids falling into the trap of traditional development where ever more complicated plans are written in an attempt to avoid dependencies causing disruption. This is an anti-Agile approach as it restricts the ability of the teams to respond to change.

Above all, recognise that external dependencies are something we should work hard to avoid.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.