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.
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.
A typical SAFe Program Board is a row and column matrix that consists of the following:
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.
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.
The following are the basic inputs required for the Program Board:
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.
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.
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.
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.
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.
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.
Your email address will not be published. Required fields are marked *
85 percent of respondents say Scrum continues to... Read More