Skip to main content
All CollectionsDependency Management & Tracking
Good Practices on Dependency Sticky Notes
Good Practices on Dependency Sticky Notes

Think of the Dependency Sticky Note type as metadata; data that describes the dependencies between Team or ART backlog items.

Updated over 8 months ago

Purpose

This article was created to describe good practices related to using Dependency Sticky Notes during 3x major phases of its life cycle:

  1. Creating and assigning the Dependency Sticky Note type in the presence of cross-team or cross-ART dependencies

  2. Using the Mirror functionality to provide visibility and transparency of Dependency stickies on the ART Planning Board and Solution Planning Boards

  3. Effective ways to facilitate and manage Dependencies during the PI event to save time and ensure high alignment and clarity across all stakeholder views

Communicate cross-team or cross-ART dependencies instantaneously, with high fidelity, and in a frictionless way using the Dependency Sticky Note type.

Reduce waste by reducing rework and replanning when communicating Dependencies in real time during planning.

Scenario #1 - Using Dependency Sticky Notes

Imagine that the team breakout sessions have started and while decomposing and creating work items to deliver a key ART Backlog Item the team surmises that they are dependent on another team to deliver an interface, subsystem or service of some sort to complete their Feature work. The team can start to deliberate about wether this is a real-dependency, a run-time or build-time only dependency, or what team in the organization is designed to handle the dependency, BUT what is critical is that they communicate this dependency in real-time (immediately) and with clarity about their expectations when it will be delivered...

This critical step of communicating the Dependency to the receiving team - in manner that saves time, greatly reduces coordination overhead and brings maturity to the whole process of facilitating team dependencies - is the purpose of the Dependency Sticky Note type.

The Dependency Sticky Note provides metadata that instantly communicates to the receiving team with clarity what the requesting team is expecting in terms of schedule and the related work item (e.g. Feature in the ART Backlog) which helps them understand the ART/Team priority. This happens instantaneously and frictionlessly when the Dependency Sticky Note is assigned.

clarity about the expected will drive alignment on the scheduling, help faster decision making around managing dependencies across-teams and across-ARTs.

Here is a scenario that outlines some simple good practices for managing a Dependency. An assumption here is a Feature Team...

  • When a team identifies or knows of a dependency they need from another team, they create the Dependency Sticky Note on their Team Board, in the Iteration they want it delivered.

  • Link the Dependency Sticky Note to the Feature (ART Backlog Item) it is related to. Important: the link between the Dependency and the [Feature] Work Item Sticky Note will be important in regards to visual management on the ART Backlog Board.

  • Next, assign the Dependency Sticky Note to the Team they depend on using the Sticky Note toolbar Depend button.

piplanning.io Dependency Sticky Note creation

Create the Dependency Sticky Note in the Iteration you expect it to be delivered.

Link the Dependency to the Feature (ART Backlog Item) that it pertains too.

Click the Depend button on the toolbar and select the Depends On team

  • Optional: Mirror the Dependency Sticky Note to the ART Planning Board or the Solution Planning Board IF the Dependency needs to be on these boards for cross-team or cross-ART visibility and tracking respectively.

Select the Mirror to Planning Board button on the toolbar

Select ART Planning Board if it is a cross-team dependency on the ART

Select Solution Planning Board if it is a cross-ART team dependency.

Note: Visual indicator if it has already been mirrored.

  • Assumption: Organizational structure and/or the absence of Feature teams, agile at scale and many other factors make dependencies pretty inevitable for product or solution delivery.

Did this answer your question?