Understanding the SAFe® Program Dependency Board Retrospective

The Program Increment (PI) Planning is a key differentiator event, unique to the SAFe® way of working. It is a 2-day (2.5 to 3 days in case of Distributed environments) planning event at the beginning of each PI where all the members of the Agile Release Train(ART), Leadership, Business and other stakeholders gather to plan for the next upcoming PI. 

The PI objectives and the Program Board are the two major outcomes of this large-scale Planning Event. This article delves into the Program Board creation, template, uses and the benefits it brings to the smooth planning and running of the upcoming PI. 

Know more about safe core values.

What is a SAFe® Program Board? 

The SAFe Program Board is created by teams at the time of PI Planning to visibly represent dependencies of their features with other teams in the Agile Release Train (ART). It also represents how the feature completion dates fare against any milestone events. This visual radiator helps to quickly sort out major dependency issues and fix the chronological order of execution to meet the major milestones at the time of PI Planning. It is recommended to be used after the PI Planning as well, so that emerging and evolving changes are updated, and teams respond accordingly.

What Is Found on a SAFe® Program Board?  

A typical SAFe Program Board is a row and column matrix that consists of the following: 

1. List of Teams: The list of teams that are part of the ART and the supporting teams which work with all the teams in the ART such as UX, Architecture etc. are listed as rows in a matrix. 
2. Iterations: All the Iterations that will be part of the PI appear as columns of the Matrix board. The Iterations can be 2 or 3 weeks long and so the number of Iterations depends on cadence set for the iterations in the ART. So, there can be 3 or 4 iterations with an IP(Innovation & Planning) iteration at the end. 
3. Milestones/Events: The first row in the Matrix lists any Milestone event that is about to happen during the course of the PI; for e.g Trade show, a compliance SLA with one of the Customers, or an Engineering Milestone like a technological upgrade. This ensures to give visibility on whether the features related to that event have been planned to be completed before the milestone or not. 
4. Features: Each of the teams places the Feature card at the Iteration at which it is planned to be completed. For e.g if Team X plans to work on a Feature A with 4 stories, 3 planned for Iteration 1 and 1 planned for Iteration 2 , the Feature A will appear only once as a blue card in the matrix at Iteration 2. This is because the Feature is complete only at the end of Iteration 2. 
5. Dependencies: If Team X is dependent on the Shared UX Team and Team Y to complete Feature A in Iteration 2, the dependencies are marked as a Red card in the Iterations at which the UX Team and Team Y work on the dependencies. There is a red coloured connector between the Feature A Card and all the dependency Red Cards. 

To effectively navigate the dynamic landscape of Agile development and maximize collaboration, SAFe certification training equips professionals with the skills and insights needed to leverage the power of the SAFe Program Board.

What are the uses of a SAFe® program board?  

The Program Board makes it obvious if there is a risk of missing an important milestone or if the dependencies do not make sense chronologically.  It is a very important Visual Information Radiator that is created and used in PI Planning and also during the course of PI. 

For e.g, Team Y is delivering Feature B very close to the Milestone Event which is a risk. Team Z is delivering Feature C after the Milestone event which must be replanned. 

Team X is Planning to complete Feature A in Iteration 2. It has dependencies with the UX Team and Team Y. But Team Y is planning to work on the dependent story in the same Iteration 2. Team Y can replan to work on it in Iteration 1 because Feature A is high priority and cannot risk missing completion because of an important milestone. 

Deeper learning from the program dependency board  

Other than the obvious benefits of the Program board, it also exposes certain other facets of planning at scale. It could quickly point out if any team(s) is completing too many features at the very end of the PI. From the Sample Program board, we can infer Team X is only completing features at the end of the PI. 

Teams that have dependencies with multiple teams might become a bottle neck for the progress of other teams. Team Z has dependency with almost all the teams in the ART. Ways must be devised during the PI Planning itself to reduce this sort of dependency. 

The board might expose that one Team is having a lot of features tied to different Milestones. The priority of work seems not equally distributed amongst the teams. 

The shared services teams like Architecture, UX, Infrastructure etc, will have a clear picture on how other teams are dependent on them and how to prioritize the request from these teams. 

If there is a milestone very close to the beginning of Iteration 1, the senior Management and Business teams can anticipate a risk of not meeting this milestone.   

How to set up your SAFe® program board  

The following are the basic inputs required for the Program Board: 

1. Milestone dates come from the Product Management or Business Teams. Any Engineering Milestone dates come from the Engineering Head. 
2. The list of the teams in the ART and the Shared Services teams are input by the RTE 
3. The names to be used for the teams in the board should be provided by Scrum Master in consultation with teams. 

Once the input information is available, the RTE creates the Board before the PI Planning starts. Scrum Masters start populating the board for their respective teams in consultation with their teams during the course of the PI Planning.

Are you looking to enhance your project management skills? Our online PMP course is the key to achieving mastery in the field and obtaining the best PMP certification. Enroll now and take your career to new heights with confidence.

When to use a SAFe® program board  

The Program Board is created and very useful at the time of PI Planning. During PI Planning the board is reviewed at intervals and at draft reviews, and changes are incorporated. 

It is highly recommended to keep the board up to date throughout the PI to add and modify emerging dependencies and changing milestones. The Program Board can be reviewed and updated at the ART level meetings by the Scrum Masters and RTE, so that the latest information is available on the board. 

Create your own SAFe® program board  

The program board can be created as a virtual board in the case of distributed teams. There are tools like Miro that can be used to create Virtual program boards.  

In the case of co-located teams, a physical board can be displayed at a common area where all teams and shared teams can have access to it. Different coloured cards must be used such as– blue for Feature Cards, Red for Dependency and Red Strings for connecting the Feature card to their dependencies. It is better to have a soft board as the base so that board pins can be used to hold the connector strings in place.

Good Practices and Tips for Program Board Efficiency  

The Program Board used well serves as a very effective visual information radiator and planning aid for all stakeholders at PI Planning and during the PI execution.  

• Having all the necessary information like the Milestone events before the PI Planning can ensure that the most up to date information goes into the Program board at the time of PI. 
• Awareness of the Milestone can help Business and Teams prioritize and plan the features. 
• For features not tied to a Milestone, Business Teams get an indication of when Features are likely to be completed. This helps them to plan the release of these features.  
• The Shared Service teams (UX, Infrastructure, Architecture etc) can prioritize and plan their work according to the dependencies and milestones on the board. 
• The RTE can take the responsibility of bringing the Program Board as a topic of conversation at ART synch meetings, so that the Scrum Masters and other stakeholders can keep it current and updated and the ART can benefit from it. 
• Through the Program Board the RTEs can track and communicate the various dependencies and milestone targets to all the relevant stakeholders to constantly get their attention and support as required. 
• The teams can check in to the board any point of time to get a view of the larger context of the release e.g features worked on by other teams and their target completion. 
• There are likely to be changes to the plans drawn out during PI. In keeping with the Agile Principles of embracing and responding well to change, the Program board can be revisited every week and kept updated. 

All said, the Program Board should not replace the constant collaboration and interaction amongst the teams and stakeholders but a tool that provides context and serves as an aid to the communication. 

SAFe® Program Board Template  

A SAFe Program Board Template can be created using a sample board described by SAFe. You can find out more about it here. Miro also has a free template that can be used. 

Conclusion

The Program Board is one of the most major outcomes from the PI Planning event and one of the most important tools that can be used by the RTE and Scrum Masters during the PI execution phase. It is an important Visual Radiator for running Agile in a Scaled environment and can be used effectively and efficiently for best results.