Theoretically, one Feature is assigned to one Team and that keeps plans and product delivery simple. Yet, in the real work, things are messier. When the scope of a Feature dictates that multiple Teams need to work together to deliver it, then article how to eliminate the level of effort and non-value add work needed to coordinate this work between multiple teams.
Baseline Scenario for this Help Article
Let's work with the following scenario/s; a Feature on the ART Backlog Board will require work from multiple teams—like a new mobile app feature needing both frontend development and backend API changes, or a new payment system requiring work from payments, security, and customer support teams.
The challenge during planning and executing is getting aligned across the teams and coordinating and optimizing - whose is doing what when - without losing agility or creating overhead that slows everyone down.
The piplanning.io Approach: Dependencies as Coordination Metadata
To understand the concept of piplanning.io's Dependency Sticky type/function, we will use the analogy of ordering a meal at a restaurant. When you order a Entree, the server or waiter doesn't cook it themselves—they write down exactly what you order (the Entree, your preferences, and timing), and give it to the kitchen. The kitchen decides how to fulfill it based on their expertise and schedule.
Similarly, piplanning.io uses Dependency sticky types/functions as coordination metadata—they are not backlog work items themselves, but clear communication about what one team needs from another. In short, the Dependency sticky note will visually communicate the: What (the text), When (the Iteration is is placed in), Why (the linked Feature work item) , and Who (the requesting Team) needs what for this plan to work.
Step-by-Step Process
1. Identify Cross-Team Work Early
During Feature planning, collaborate to identify when your team needs work from others. Ask: "What do we need from other teams to deliver this Feature successfully?"
Example: Your team owns a "Customer Self-Service Portal" Feature, but you need the API team to expose new endpoints and the security team to implement OAuth integration.
2. Create Dependency Sticky Notes
For each cross-team need, create a Dependency sticky note that clearly describes:
What you need (not How it should be built, give the dependent on Team the agency to decide how they will resolve and deliver this dependency)
Place the dependency sticky note in the Iteration When you need it completed
Example: Instead of "Build user authentication API," write "User login/logout capability via secure API endpoints."
3. Link Dependencies to Your Feature
Drag a string or link the master Feature sticky note work item to the Dependency sticky.
Other Teams will be able to reference this linked Feature and understand the bigger picture—the Why behind the requested dependency.
4. Assign to the Dependent On Team
Assign the Dependent On Team, another team in the ART or on the Solution Train (or External Org). Automatically and immediately the Dependent On Team will be notified via a visual sticky note on their Team Board.
Benefit: the Dependent On team can now make immediate decisions about the priorities and capacity for planning work items taking into account the dependency. Hopefully we are eliminating the waste in planning where replanning and rework is needed when new information is presented to the teams at the last minute.
5. Mirror Significant Features
If the Feature has program/ART-level importance, mirror it to the ART Planning Board for broader visibility and coordination.
6. Let Teams Plan Their Own Work
The receiving team creates their own User Stories and backlog items to fulfill the Dependency, and link them to the Dependency. They maintain full autonomy over How they deliver what's needed.
Key Benefits
High Collaboration + High Autonomy: Teams coordinate clearly without micromanaging each other's work, get quickly aligned on the bigger picture and priorities, and can clearly see the scheduling dynamics in realtime to not waste time coordinating the scheduling.
Reduced Friction: Dependencies are visible, contextual, and actionable—no endless conversations or chat threads to find the optimal scheduling of all independent pieces (work items).
Single Source of Truth: One Feature, multiple contributors, clear ownership and expectations. No messy duplication of mock Feature cards, or proxy cards that skew true flow metrics.
How we resolve these Common Anti-Patterns
❌ Copying or duplicating Features [cards] across all Team Boards: Creating multiple Feature cards for the same outcome leads to confusion, misalignment, and duplicate work. Teams end up building slightly different things on different timelines.
❌ Detailed cross-team planning: Don't try to plan another team's work for them. Trust their expertise and give them clear requirements instead.
❌ Dependency hoarding: Don't wait until the last minute to surface dependencies. Early identification prevents bottlenecks and allows better planning.
An Example; how to manage multiple Team delivery of a Feature
Scenario:
A new Feature Expanded payment options with Venmo integration is planned and it is owned by the Mobile team.
Traditional Problem:
Mobile team creates detailed technical requirements, assigns tasks to Backend and Security teams, leading to conflicts only being discovered last minute, and back-and-forth negotiations, escalating to conflicts, and meeting times constantly being extended.
piplanning.io Solution:
Mobile team creates two (2x) Dependency sticky notes:
Payment processing API (for the Backend Team) and
PCI compliance validation (for the Security team)
The receiving (Dependent On) Teams (Backend and Security teams) receive clear requirements about Who/Wha/When and Why they need to resolve this dependency.
They have full autonomy to build plans about How they will plan for and resolve the dependency.
All work stays connected to the single Feature sticky note - Expanded payment options with Venmo integration
Everyone sees progress and can adapt as needed
