Managing Requirements Dependencies Between Agile Teams

agile agile

Although we strive to avoid functional dependencies between requirements, the fact is that they occur in practice.  They certainly occur between requirements that are being addressed by a single team and they will even occur between requirements being addressed by different development teams.  This is particularly true between the subteams within a program (a large development team organized into a “team of teams”).

The following diagram depicts a simple situation where there is an agile program organized into five subteams (A thru E).  The way you read the diagram is that the arrows between requirements represent functional dependencies.  In this case the requirement fourth from the top on A’s backlog (A4)  depends on the one that is second from the top (A2) and on B3 (the requirement third from the top on team B’s backlog).  B3 in turn depends on C7, which depends on D3.  D3 depends on E4, which depends on D10, which depends on C12, which depends on D14.  There could very well be dependencies between other requirements, but for this example we’re only worried about the dependencies originating from A4.

Figure 1: Example of functional dependencies between requirements.

Requirements Dependencies Between Teams


Where Do Functional Dependencies Come From?

Functional dependencies occur between requirements for several reasons:

  1. End-user driven.  Functional dependencies occur naturally in the business domain as the result of end user activities.  For example, when a customer opens a bank account there is a functional dependency between the customer and bank account business entities.  Furthermore, functionality such as being able to withdraw from a bank account depends on their being the ability to open a bank account for a customer to begin with.
  2. Requirements decomposition. When a large requirement is decomposed into smaller ones there are dependencies from the original large requirement to the smaller sub-requirements.  An example of this is decomposing an epic, a large story, into several smaller stories.
  3. Technology driven. Some teams will choose to identify requirements for a given platform, subsystem, or architectural layer.  For example, you may identify requirements for systems of engagement, such as applications running on mobile devices, and for systems of record, such as a back-end ERP system.  A requirement for a mobile application may have a dependency on a requirement for a backend system to provide certain behaviors (such as the ability to create, read, update, and delete data).  An example of requirements dependencies driven by architectural layering would be that you may choose to identify user interface (UI) requirements, business rules, and data requirements (via data models perhaps).  A UI requirement depends on the implementation of a business rule which in turn depends on several data-oriented requirements.

Of the three reasons for why functional dependencies exist, the first two are clearly within the purview of a Product Owner (PO).  The third one, technology driven dependencies, can be trickier because many POs will not be familiar with the underlying technologies.  This is one reason why Disciplined Agile Delivery (DAD)’s Architecture Owner (AO) role is so important.  The AO and the PO on a disciplined agile team work very closely together.  AOs will help POs to better understand the implications of the technologies being used as well as to understand potential implications of the technologies (including technology-driven functional dependencies).  These sorts of discussions will occur throughout the lifecycle, although they are particularly important during initial release planning during Inception and during iteration planning and look-ahead planning throughout Construction.


How do You Resolve Functional Dependencies?

Functional dependencies are addressed via three basic strategies:

  1. Reprioritize one or both of the requirements.  When requirement X depends on requirement Y you ideally want to implement Y before, or at least in parallel, to implementing X.  The advantage of reprioritization is that it requires the least amount of work by the development team.  The disadvantage is that when a requirement is reprioritized in this manner the team is no longer working on the highest priority functionality by business value, potentially decreasing the return on investment (ROI) provided by the team.
  2. Mock out the missing functionality until it is available.  Requirement X depends on requirement Y and Y will not be available in time (e.g. X is being worked on right now and Y will be developed in a future iteration).  In this case the development team will implement X to the best of their ability, but will mock out (simulate or stub out) the functionality of Y until it is available.  The advantage of this approach is that it is now possible to demo X so as to get feedback about it.  The disadvantages are that your solution isn’t shippable until the mocked out functionality is implemented (or removed) and that there is the additional work to be done to mock it out.
  3. Rework the requirements to remove the dependency.  If X depends on Y, then one solution might be to refactor X into X1 and X2, where X2 has the functionality dependent on Y but X1 has no dependency.  X1 would be implemented now, and X2 at the same time or after Y is implemented.  For example, a new screen has a dependency on data services being available.  The screen includes five fields, four of which already have data services available but one of which is brand new.  In this case X1 would be to do the work to implement the screen with the four fields and X2 would be the requirement to add the new field once the data was available on the back end. Another solution would be to not add the new data field at all, something you would need to discuss with your stakeholders.

Within an agile environment, functional dependencies are managed by Product Owners.  When the dependencies are between requirements, or more accurately work items, that are being addressed by a single agile team this is fairly straightforward because it’s within the purview of the single product owner.

Now let’s consider how a Product Owner team would manage requirements dependencies within a program, as in the diagram above.  In this case let’s assume that each team has it’s own product owner (PO) whom we’ll refer to as PO-A, PO-B, and so on.  There are three scenarios to consider when managing requirements dependencies:

  1. Within the same sub-team.  An example of this is A4 depends on A2. This is straightforward as a single person, in this case PO-A, is responsible for managing this dependency.
  2. On previously developed functionality.  An example of this is C7 depends on D3.  This should also be straightforward as D3 was implemented in iteration N so it should be available when C7 is implemented during iteration N+1.
  3. On future functionality.  An example of this is B3 depends on C7.  The problem is that we want to implement B3 during iteration N but we currently plan to implement C7 during iteration N+1.  The two product owners, PO-A and PO-B, will need to work together to determine a strategy for resolving the dependency.  They’ll do this via a combination of the strategies described earlier.  They may also need to work closely with the Chief Product Owner to ensure that their reprioritization choices reflect the overall needs of the program.

How would the entire requirements dependency map for A4, as depicted in the diagram above, be resolved?  It depends on what the product owner team decides.  At the present moment the overall requirements dependency chain is to be implemented during iterations N through N+3.  This may in fact be acceptable and the product owners will decide to live with the impact of mocking out functionality until it is available.  Or they may decide to reprioritize the functionality so that it is implemented in a more effective order (perhaps during iteration N+1).  The point is that the product owners will engage in negotiation amongst themselves to determine the best order in which the sub teams will implement the functionality.


How do You Manage Functional Dependencies?

Functional dependencies are managed by the Product Owner, or in the case of a program, the Product Owner team.  The goal is to do just enough work to maintain the dependencies and no more.  When you do not sufficiently maintain the dependencies, perhaps you forget to record that a sub-requirement was created as the result of decomposing a larger parent requirement, then it becomes difficult to ensure that a requirement is properly implemented. When you invest too much effort into maintaining functional dependencies any extra effort beyond the point of sufficiency is a waste.  In short, your dependency map should be just barely good enough (JBGE) for the situation you find yourself in.

There are several options available to you for maintaining a functional dependencies:

  1. Physical dependency map.  With this strategy requirements, such as user stories or features, are captured on paper (typically via index cards or sticky notes) and placed on a whiteboard, corkboard, or table.  On physical boards dependencies can be indicated via physical placement, for example the cards capturing the sub-requirements of a large requirement are placed immediately to the right of the large requirement card.  On a corkboard strings representing requirements could be placed from one card to another and on a whiteboard lines could be drawn to represent the dependencies.  Or IDs could be given to each requirement and any dependencies simply captured on the cards via writing down the appropriate IDs. An example of a physical map include user story maps, see Figure 2 below, that indicate the epic or theme that a story is part of (this is a rudimentary form of dependency mapping).  Another example includes a program plan board, an idea promoted by SAFe, where requirements are mapped to iterations/sprints (columns on the board), to implementation teams (rows on the board), and dependencies indicated via strings or lines.
  2. Simple electronic tool.  Dependencies can be managed using tools such as spreadsheets, word processors, or wikis.
  3. Backlog/work item management tools.  This includes products such as Trello, Atlassian’s JIRA, Rally and VersionOne.  Some of these tools will have native support for managing dependencies where others do not (if the solution is to add a text reference into a freeform notes field then that’s not native support).
  4. Requirements management tools.  This includes products such as Blueprint, Enterprise Architect, or DOORS NG.  Be aware that some of these tools will have native, and more importantly effective, support for agile requirements artifacts such as user stories and acceptance criteria.  Sometimes they will not.


Figure 2. Example of a simple story map.

Story map

Which approach should you take?  Our advice is always to keep it simple and use physical tools if your situation permits.  Having said that, there are advantages and disadvantages to each strategy:

  • Physical dependency maps work well when teams are geographically close (working on the same floor or at least nearby floors in the same building).  When you find yourself with a lot of dependencies to manage, or in a regulatory environment when traceability is mandated, or your team is geographically distributed (even if you just have a few people working from home), you’ll find that you’ll want to consider using electronic tools.
  • Simple electronic tools work well when the team is small to medium sized (say less than 30 people), when the team is geographically distributed in some way, and the dependencies aren’t very complex.
  • Backlog management tools are an effective option if you’re already using them for other reasons (such as managing your work), they natively support dependency mapping, and when physical dependency maps haven’t worked out for you.
  • Requirements management tools are appropriate when you find yourself in complex situations, often at scale.  This includes geographically distributed teams, complex domains, and regulatory situations.


Parting Thoughts

Earlier we said that the diagram represents a “simple” situation.  It is simple in that all five teams are following the same sort of lifecycle, in this case the basic/agile DAD lifecycle.  Furthermore the velocities of the teams are roughly the same, which we did for the convenience of the example.  Usually the team velocities are very different, due to a combination of different team sizes and different levels of productivity.  In a future blog posting we’ll discuss the challenges that arrive when the subteams are following different lifecycles (for example a lean or continuous delivery lifecycle or even a waterfall lifecycle).

Several of the strategies described in the blog posting were first identified in Complex Requirements on an Agile Project (Dr. Dobbs Journal, October 2008).

Have any Question or Comment?

19 comments on “Managing Requirements Dependencies Between Agile Teams

I like the approach but I’ve questions with regard of functional dependencies which seem to cover three different types of requirements:
a. Business requirements: operations on accounts may depend on customer profiles
b. System functionalities: some operations can be performed on-line, others can only be carried on on-site
c. Technology constraints: some operations cannot be performed on mobiles.
Yet, that taxonomy is not systematically applied to describe the problem, and it’s not used as a basis of the solution.


Actually, I did discuss where requirements dependencies come from:
End-user driven, which would generate business requirements (A)
Technology driven, which would generate B and C
Decomposition (or perhaps artificial is a better name)

The solution is also described, and the strategy is independent of the source

Russell Smith

The timing of this post is great as this is something very relevant to our current position. We’re trying to manage ‘Technology driven’ dependencies between multiple teams (e.g. Platform team, Front-end team, API team, etc.) and your suggestions are excellent.

Our teams are geographically distributed and we’re using JIRA. However, the functionality offered out-of-the-box does not visualise the dependencies, it just records them.

If anybody reading this has a good suggestion (perhaps a JIRA add-on) where dependencies can be visualised to aid the PO’s in ordering of each teams backlog it’d be much appreciated.


Hi Russell,

We have developed a JIRA add-on that could give you the information you are looking for. The add-on (Impact for JIRA, check it out here will let you visualize any JIRA linking (issue links, Epic Links, etc.) that you have defined in your projects. The add-on will let you define a list of issues that you want to analyze and it will list (in a tabular form) all issues/Confluence Pages linked to those issues (and you can go as deep as you want). This analysis view will let you have a very good way of visualizing any functional dependencies in your project.

If you have any questions or any other ideas around the add-on, don’t hesitate to post them here or contact us via (


One way to reduce this risk/pain is to move from component to feature team. Cross-functional Feature teams are able to implement a user story across all components, that are involved. That is a viable strategy, if more effort is required to resolve dependencies between components than between features (which is likely).Moving from component to feature teams is a long journey.
In any case you need “Guardians of Coherence”. A organisational capability to maintain the “big picture”, the “goal of the whole”, when decomposing requirements/user stories. That requires close(frequent) cooperation between PO and AO. This needs planning and significant resource allocation.


One way to reduce this risk/pain may be to move from component to feature teams. Cross-functional Feature teams are able to implement a user story across all components, which are involved. That is a viable strategy, if more effort is required to resolve dependencies between components than between features (which is likely).
Moving from component to feature teams is a long journey.
In any case you need “Guardians of Coherence”. An organisational capability to maintain the “big picture”, the “goal of the whole”, when decomposing requirements/user stories. That requires close(frequent) cooperation between PO and AO. This needs planning and significant resource allocation.


When working in large projects how do you identify dependencies in an Agile approach? Do you do an analysis of the whole project or do you identify dependencies in the sprint?

How do you control during the sprint planning dependencies as part of the equation? What if you missed a dependency during sprint planning? Will the sprint fail or those are tasks for the next sprint?

Valentin Tudor Mocanu

There are more levels of dependencies: requirement, design etc.
We should remember that the elements in the Product Backlogs are not (only) requirements, but product change requests, that mean small pieces of work, that encapsulate requirements, but contains also info related to the solution/design, possible some acceptance criteria etc.
That should not be a problem for DAD that extend the idea of Product Backlog.

For this reason dependencies because of requirements are only the “first wave” , and after that we need to refine the prioritization for piece of work considering also the design. A good design will have similar dependencies as the ones from requirements, a bad design will introduce massive differences.

Also when dependencies are critical and/or, the rough representation with user stories, features and epics will not be enough: we will need imho a language more close to requirements and business representation: workflows and rules (business rules). But that it is only a scaling case, also with support on DAD (but eventually could be explicit in the options list).


@Peter, the Product Owner team will do the bulk of the work for providing requirements coherence (and the AO technical coherence). The amount of effort this will require depends on the situation. How complex is the domain/technology? How effective is the PO/AO team? How long have they been at it? What is the quality of the existing ecosystem in which they’re work (e.g. how much technical debt is there)?

@Wguerram, when and to what extent you identify dependencies will depend on the situation you find yourself in. Usually you’ll want to start this early in the lifecycle during Inception when you are exploring the initial scope. You’ll want to evolve/maintain the dependencies throughout development as the requirements evolve.

@VTM, good points. I chose to focus on requirements dependencies in this posting so as to limit the scope of the discussion. You are right in pointing out that there is more to it than just requirements-oriented dependencies. Technical/design dependencies are similarly addressed by the architecture owners, the topic of a future blog.


Very interesting topic. I have a customer looking to identify a small set of practices to support large projects where there will be some epics / stories that will span multiple teams. In these circumstances there usually are multiple PO/AO teams at work.

We identified that for requirements with these circumstances we would use requirements envisoning techniques to work out the system context, non functionals and any major dependencies btw the teams. Ultimately only one PO/AO team would own story with others providing supporting tasks.


The Product Owner is responsible for giving rise to Business Backlog. The Backlog combines with the customer backlog will rise the product roadmap.


Reblogged this on Scrum User Group for Road Warriors and commented:
This is something that we see on projects, regardless of size. Well worth taking the time to read.



This is an outstanding paper. I use it a lot.

There’s one more “detent” in the “functional dependencies” between stories. That is the “Scenarios” that evolve from ATDD/BDD. The combination of User Story Mapping with BDD is a match made in heaven. We can work, in parallel, on different scenarios, within a story, as a scaling paradigm.

Thank you.



Leave a Reply

Your email address will not be published. Required fields are marked *