What are dependencies?, Why do we need a Dependency Sticky?, and how should we use it? … those are the questions tackled in this article.

‍

PI Planning is all about transparency and aligning the teams on the program to a shared mission and vision. SAFe® points out two primary PI Planning outcomes:

• Committed PI objectives — A set of SMART objectives that are created by each team with the business value assigned by the Business Owners.
• Program Board — Highlighting the new feature delivery dates, feature dependencies among teams and relevant milestones.

During team breakout sessions, each team creates their plans, identify risks and define their PI Objectives. The teams also add the features and associated dependencies on the program board.

The Program Board

But first, let’s take a closer look on the program board. As everybody knows, the program board is one of the key outcomes of a PI Planning, with good reason. The program board is not only a single source of truth during the PI Planning showing the current status of our ART-level plan, it is also a key artefact for RTEs and Scrum Masters to facilitate through an effective program increment.

Actively maintained, the program board summarizes key aspects of our ongoing PI:

• Important milestones and events relevant for the whole Agile Release Train (ART)
• Features completed, planned features at risk and learnings related to our planned features
• Status of our cross-team dependencies and an easy to use option to talk about scenarios and impact on features or other teams if a dependency can’t get solved as planned or a feature will not be completed on schedule

A Dependency Sticky is a request for collaboration

Let’s come back to the PI Planning event and the dependency sticky promoted by SAFe®. Demonstrating the piplanning app, supporting customers preparing their remote PI Plannings and talking with SAFe® practitioners all over the world I often notice confusion about the dependency sticky used on team and program boards. These conversations brought me to the insight that we must distinguish between various types of dependencies.

Dependencies are not Dependencies

People often get confused talking about dependencies meaning completely different things. Therefore I started to differentiate between three types of dependencies: technical, hierarchical and organizational dependencies.

Spoiler Alert → The Dependency Sticky is exclusively used for organizational dependencies.

Let’s take a closer look.

Technical

Technical dependencies are easily explained. “We can start implementing user story 1 as soon as we have completed enabler 1”.

Technical dependencies can be found on every level. On program level, a feature can be dependent on another feature.

Hierarchical

Using backlogs on different enterprise levels means automatically to think about the hierarchy of backlog items. epics, features, user stories, initiatives, enablers, tasks … you name them. The name however, is not as relevant as the agreed hierarchical structure. That’s where hierarchical dependencies need to become transparent. “To deliver feature 1, we’ve planned to implement three user stories and two enabler stories”.

Based on what I often see at our customers, I’ve also visualized the feature on the team board even though it is a program level item. Some teams like to have the feature on their team board, others don’t.

Organizational

And then, there are organizational dependencies. Dependencies for which SAFe® promotes the Dependency Sticky to use on team boards and the program board for mainly three purposes, which I will explain in a second. The term dependency might be confusing as the Dependency Sticky must be understood as request for collaboration. Means, to complete a feature, multiple teams need to collaborate and in case of running a PI Planning, agree on a feasible plan together.

Program Board → relevant information distilled on a single Board

Purposes of a Dependency Sticky:

• Facilitation
• Visualization
• Simplification

Facilitation

‍As soon as a team figures out that another team must be involved, it is crucial to bring both collaborating teams on the same page. Sharing is caring… so the first step is to make sure that both teams know about the dependency. It’s also valuable to highlight an unresolved dependency (i.e. using a flag). As an RTE and Scrum Master you’re well prepared if every participant knows upfront a PI Planning, how to solve a dependency. A good practice is to agree on a workflow.

Workflow: How to handle and visualize dependencies

Visualization

‍The Dependency Sticky visualized on both team boards and on the program board acts as single source of truth. What are we talking about? Why do we need to collaborate? Which feature do we tackle? In which iteration will the dependency be solved? Those are the questions we answer by visualizing the Dependency Sticky on relevant team boards and the program board.

User Stories / Enabler Stories planned to solve the dependency

Simplification

‍Have you ever thought about directly visualizing user stories and enabler stories on the program board? That’s how it would look like.

A chaotic program board

Even though you have abilities to highlight linked items and scale down the sticky size, the program board is chaotic and unreadable. How would this board look like if 8 teams had planned 20 features?! At least not neatly arranged, I think we can all agree on that.

That’s why we should use Dependency Stickies and simplified functionalities on a digital program board to keep our ART-level plan readable.

A simplified program board using Dependency Stickies

It’s totally enough to see on a program board in which iteration a dependency will be solved and when a feature can potentially be delivered. No matter what is planned behind a dependency or a feature, we have the relevant information distilled on a single board.

Showing the planned work items to complete a feature

As an RTE, Scrum Master, Team Member, Product Owner, Product Manager or Business Owner being part of a PI Planning, the Dependency Sticky is your best friend 😉!

Curious where these nice screenshots come from in this article? No these are not pictures of my physical board but the one an only piplanning app. If you are looking for a solid solution for your remote dependency visualization challenges check it out here: piplanning.io

‍