In my previous blog we saw how RTE sets the agenda for Program Increment session. It was more focused on setting up of business context by Leadership team. Sharing the Architecture vision by the System Architect, and Team getting into breakouts and preparing the Draft Plan followed by Management Review. Let us see how Day 2 looks like in the Program Increment Planning.
At the start of Day 2, RTE reviews the agenda and objectives and share the same with the participants as shown below:
This is the time when the program commits an action plan that fits the capacity of the team where they can deliver maximum business value.
Planning Adjustments
After the previous day review with management and problem-solving meeting, adjustments are done with respective ARTs. It is the responsibility of the management review group to describe the issues and do planning adjustments that were concluded in the problem-solving meeting at the end of day 1.
Team Breakouts Continue
Basis feedback and inputs received from Management review team gets back to the breakout sessions to work on the following:
- Adjust their draft plan and work on the final plan.
- Teams are expected to finalise their Sprint Plans and PI Objective during these sessions.
- Teams as well try to establish stretch objectives
- Business Owners help assign business value to PI objectives in the scale of 1 to 10 (1 being the lowest and 10 the highest)
The team has to ensure that their boards are updated with all the features, risks and cross-team dependencies so that all the stakeholders and participants are aware and accordingly prioritise their set of stories and dependencies.
Concluding Team PI Objectives
Team works towards Final PI objectives by the end of the session. PI objectives are expressed in business terms. It is a brief summary indicating what teams committing for the upcoming PI.
Use of Stretch Objectives
Stretch objective is the work that is planned but is not included as a commitment from the team. It is kept to identify work that can be variable within the scope of a PI.
Reasons for categorising Objectives as Stretch Objectives?
- It helps to have a stretch objective when the team has low confidence in its ability to meet a PI objective. As this is something not committed and takes away the burden from the team. That said, teams are always encouraged to achieve the same.
- If the objective has many unknowns, the team should plan spikes early in the PI to reduce uncertainty. Such cases can be categorised as Stretch objective.
Team tries its best to achieve Stretch Objectives and as well are included in the capacity, but since they are not the committed ones, business stakeholders can plan accordingly and keep their side of stakeholders updated accordingly.
Establishing Business Value
Why there is a need to estimate Business Value? This is required to evaluate the progress of an ART. How do we evaluate if ART is a success or not? It is basis Business Value delivered by an ART. To measure each ART, all the PI Objectives need to be mapped to numeric value on a scale of 1 to 10 known as Business Value. To execute this, the Business Owners set the business value of each objective toward the end of the PI planning session as given below:
Note that not all PI objectives will deliver equal value. Business Owners will accordingly assign value to objectives. The one with externally visible will be assigned with a higher value as compared to infrastructure or architecture objectives that are not going to be visible outside.
Team also uses these Business Values for making trade-off or scope adjustment to ensure they deliver the maximum value to the business.
Program Board
It is the responsibility of the RTE to create a program board in advance of planning. The team then updates it during planning. This board gives visibility on the feature delivery dates, milestones, and dependencies among teams and with other ARTs as shown below:
Final Plan Review
Once the teams are done with their side of planning and discussions with other teams on dependencies and are ready with their PI Objectives, it is time for Final Review.
This is basically a repeat of the draft plan review session from the day before, but by now the teams will have completed their plans.
Each team is given 5-10 minutes to present their plan indicating the BV (business value) planned, risks and dependencies. After publishing its Objectives, each team states its remaining program risks and impediments. Risks and any impediments are addressed later.
This is followed by a Q&A between ART and Business owners. The facilitator confirms with the Business Owners if the plan is acceptable to them. If the plan is acceptable, then there is a discussion on identified risks and impediments in front of everyone. This helps everyone to understand each other Objectives in real-time. This is done for each team.
Addressing Program Risks and Impediments
All the risks, dependencies, and impediments identified by the teams are discussed in an open forum in front of everyone one by one by each team. These are resolved in a broader management context in front of the whole train. One by one, the risks are addressed with honesty and transparency, and then categorised into one of the following categories:
- Resolved – The teams agree that the issue is no longer a concern.
- Owned – Someone on the train takes ownership of the item since it cannot be resolved at the meeting.
- Accepted – Some risks are just facts or potential problems that must be understood and accepted.
- Mitigated – Teams can identify a plan to reduce the impact of an item.
Confidence vote
Once the risks of all the teams have been addressed, teams vote on their confidence in meeting their program PI objectives. The teams vote using a ‘fist of five’. 1 being a low confidence and 5 fingers indicating very high confidence, as given below:
If the average of the vote is three or more fingers, management accepts the commitment. However, if the average is less than three, then it indicates the low confidence and indicate a problem with the plan finalised so far. This indicates that some adjustments are needed in either Scope or Resourcing. In such a scenario, teams need to revisit the plan, make adjustments and it continues till the time confidence is achieved and the average confidence vote is between 3 to 5.
Planning retrospective and moving forward
Finally, the RTE leads a brief retrospective for the PI planning event to capture what went well, what didn’t, and what can be done better next time. This specific session gives further insights to RTE to make adjustments for the next PI session so as to be more effective.
As seen in 2 days Agenda for the PI session, it is advent that no other even is as powerful in SAFe as PI Planning. This 2 days session holds the key to the success of any given ART. It brings everyone together to plan toward a common mission, vision, and shared purpose.
The primary output of PI planning is a committed set of PI objectives that the teams will deliver over the course of the PI. This is supported by a program board, which maps the feature delivery dates, milestones, and dependencies that must be successfully navigated to develop and release value.
References: SAFe Distilled 4.5 and Scaled Agile Framework
