January 17, 2017 at 09:12PI Planning in SAFe
Scaled Agile Framework, SAFe is an Agile development framework developed by Scaled Agile Inc., essentially a knowledge base for implementing lean enterprise-level agile development. Below is a free retelling of the original PI Planning - Scaled Agile Framework article .
190-member PI planning session
One of the principles of the Agile manifest says that "direct communication is the most practical and effective way to exchange information with the team itself and within the team." This is easy to do if you have one small team. But what about the scale of a huge company when there are a lot of teams and their synchronous work is needed? To do this, the PI Planning tool is used in the Scaled Agile Framework (SAFe) - this is the practice of direct communication of all teams, business representatives and other interested parties, who, as it were, are combined into one large team - Agile Release Train (ART).
Communication takes place at regular meetings with a standard agenda: at the beginning there is a presentation of business representatives with a story about the current situation, strategy and tasks, then a planning session, when teams create a plan for implementing the product increment created within the program - Program Increment (PI). We’ll make a reservation right away: in the SAFe terminology, the term “program” is used to refer to a large number of interconnected teams, in the future we will stick to it. This session is attended by all ART members as far as possible. To facilitate such meetings, a special role is assigned - Release Train Engineer (RTE). He is also responsible for the escalation of blockers, helps in risk management, value delivery and continuous improvement.
For such planning, research and training events, a special IP-iteration (Innovation and Planning iteration) is provided so as not to take the time of teams at other iterations inside the PI. The session lasts from 1.5 to 2 days. The result is a consistent set of program goals for the next PI.
Geographically distributed ARTs hold this meeting at the same time in different places, but maintain constant communication with each other.
It is important to carry out PI planning regularly, because it sets the rhythm of the entire ART. This is an integral part of SAFe: if you do not carry out PI planning, you do not use SAFe.
250-member
PI planning session PI planning provides many benefits to a business:
The following materials are being prepared for the session: roadmap, concept, top-10 priority features from the program’s backlog and other artifacts for conveying the business context.
The main results of PI planning are:
PI planning is an important event that requires preparation, coordination and communication. Participants in the event: product managers, Agile teams, architects and engineers, system teams, stakeholders - all of them should be notified in advance and come to the event well prepared.
A successful event is being prepared in the following areas:
The following is a description of the training in each area.
It is important to make sure that the program has a strategy that will be understood by the participants of the event, including interested persons and representatives from the business, that the work of the teams corresponds to this strategy, that there are people in all key roles in ART.
Below are examples of questions that help determine this readiness.
It is equally important to correctly convey the concept and business context, therefore, all necessary stakeholders should be present at the session. For this, PI planning includes the following activities:
It is not so easy to prepare the venue and technical infrastructure of the event with a large number of participants, especially if there are remote participants.
The following are points to consider.
In general, the event follows the standard agenda, which is shown below. Next, we will consider each block of the event in more detail.
Standard Agenda for a 2-Day PI Planning Session
The top manager or business owner describes the current state of the business and how well the current solutions in the future will satisfy the needs of customers.
Product managers present the current concept of the program, usually talking about the most important 10 upcoming features, about changes from the previous PI-planning, as well as about any future milestones.
System architect presents an architectural concept. In addition, a senior development manager can talk about changes in Agile development practices, such as test automation and continuous integration, that need to be considered during the next PI.
The facilitator, RTE, explains the planning process and the expected results from the event.
The facilitator explains the goals and plan of the PI planning session for 100 people
Teams for each iteration estimate the amount of work that they can perform (capacity) and determine the backlog elements that are most likely necessary for the implementation of features. Each team creates draft plans that are visible to all the other participants, iteration after iteration. At this time, they identify risks and dependencies, determine the draft goals of the team on PI. The team also adds features to the program board.
Teams identify interdependencies in PI planning sessions per 100 people
Reviewing plans is carried out with strict time limits for the performance of each team. At this time, the teams present the main planning results: draft goals, potential risks and dependencies. Representatives from the business, product managers, other teams and stakeholders ask questions and give feedback.
The product owner presents the plan her team assembled at a 100-person PI planning session.
It is likely that the plans will need to be finalized taking into account the expected amount of work, limited resources and identified dependencies. During this meeting, management approves the scope of work and corrects deficiencies in the plans. RTE holds a meeting with all key stakeholders until they identify achievable goals.
The next day, the event begins with the fact that the manual describes all the changes in the planned amount of work and resources.
Teams continue planning based on the results of the previous day, making the necessary changes. They finalize their goals on PI, and business representatives evaluate the business value of these goals.
Planning results for one of the teams at the PI planning session for 100 people
All teams briefly present their plans. At the end of each team’s performance, risks and blockers are voiced, but teams are not allowed to discuss and seek solutions in this short period of time. If the plan is accepted by customers, the team posts flipcharts with their goals for PI and risks in the most visible place, so that everyone can see in real time the formation of the overall goals of the program.
During planning, teams discover critical risks and blockers at the program level, which may affect the ability of teams to solve their problems. These issues are addressed by all participants. All risks, one after the other, are clearly, honestly and openly classified into the following groups:
Risks of the program at the PI planning session for 100 people
After the risks of the program have been considered, the teams vote for realism and willingness to take responsibility for achieving these program goals on PI. All team members raise their hands, showing one to five fingers.
Voting rules at a PI planning session for 100 people
If, on average, three or four fingers are raised for all teams, then management can accept such obligations. If on average there are less than three fingers, then the necessary changes are made to the plan and all plans are processed. Everyone who raises two or less fingers should express their concerns. This allows you to either identify a new risk that requires re-planning, or simply convey important information to everyone.
Voting at rehearsals with Scrum-masters and product owners of the teams before the PI-planning session for 100 people
If necessary, teams revise their plans until a level of trust is sufficient for them. This is the first moment in the entire PI-planning session, when time constraints go by the wayside - more important is the consistency of plans and the willingness of teams to take responsibility for their implementation.
Finally, RTE conducts a short retrospective session to determine what worked out well, what was not good, and what could be done better at the next PI planning session.
After that, you can discuss further steps, put goals and user stories in IT tools for managing Agile projects, plan upcoming key activities and events ... and even tidy up the room!
Successful PI planning gives you three key artifacts.
In this video, our PI planning practice:
PS . If you are interested in materials on the transformation of processes in large companies, we recommend the Enterprise Agile Russia group on Facebook. We will discuss scaling approaches such as SAFe and LeSS.
190-member PI planning session
Product development tasks cannot be predicted in advance. Pass planning and tracking to those who can evaluate the end result and influence what it will be.
- Michael Kennedy, Product Development for the Lean Enterprise
There is no magic at SAFe ... unless just PI planning.
- Authors SAFe
One of the principles of the Agile manifest says that "direct communication is the most practical and effective way to exchange information with the team itself and within the team." This is easy to do if you have one small team. But what about the scale of a huge company when there are a lot of teams and their synchronous work is needed? To do this, the PI Planning tool is used in the Scaled Agile Framework (SAFe) - this is the practice of direct communication of all teams, business representatives and other interested parties, who, as it were, are combined into one large team - Agile Release Train (ART).
Communication takes place at regular meetings with a standard agenda: at the beginning there is a presentation of business representatives with a story about the current situation, strategy and tasks, then a planning session, when teams create a plan for implementing the product increment created within the program - Program Increment (PI). We’ll make a reservation right away: in the SAFe terminology, the term “program” is used to refer to a large number of interconnected teams, in the future we will stick to it. This session is attended by all ART members as far as possible. To facilitate such meetings, a special role is assigned - Release Train Engineer (RTE). He is also responsible for the escalation of blockers, helps in risk management, value delivery and continuous improvement.
For such planning, research and training events, a special IP-iteration (Innovation and Planning iteration) is provided so as not to take the time of teams at other iterations inside the PI. The session lasts from 1.5 to 2 days. The result is a consistent set of program goals for the next PI.
Geographically distributed ARTs hold this meeting at the same time in different places, but maintain constant communication with each other.
Overview
It is important to carry out PI planning regularly, because it sets the rhythm of the entire ART. This is an integral part of SAFe: if you do not carry out PI planning, you do not use SAFe.
250-member
PI planning session PI planning provides many benefits to a business:
- Inside ART, business communication is being established, because many of those who need to do joint projects get to know each other for the first time.
- High efficiency of communication between all team members and stakeholders is ensured. Simply put, if you bring a lot of people together and give them a goal, then this leads to an extraordinary energy communication. Tested on our experience! (comment translator)
- Business customers and developers finally hear each other and begin to act in concert in accordance with the goals of the business.
- Teams begin to see the “picture as a whole”, dependencies are revealed, which encourages teams to coordinate among themselves and other ARTs.
- Teams select only the necessary minimum requirements for architecture and user interface. This will allow you to meet the planned deadlines and not “roll up” excess functionality.
- The scope of work is planned taking into account the capacity of teams, due to which the excess of incomplete work is eliminated.
- Decision making is accelerated.
The following materials are being prepared for the session: roadmap, concept, top-10 priority features from the program’s backlog and other artifacts for conveying the business context.
The main results of PI planning are:
- A set of SMART goals for PI teams that each team defines on its own. Each goal is evaluated in terms of business relevance. The goals of all teams are combined into a set of goals for the entire PI program.
- The program board, which shows new features, expected dates for their implementation and any other milestones with which the goals of the teams are associated.
- General agreement with realism and willingness to take responsibility for the achievement of these goals.
Training
PI planning is an important event that requires preparation, coordination and communication. Participants in the event: product managers, Agile teams, architects and engineers, system teams, stakeholders - all of them should be notified in advance and come to the event well prepared.
A successful event is being prepared in the following areas:
- Organization: coherence of business and development according to strategy, readiness of teams and all art.
- Content: preparedness of management and developers.
- Infrastructure: venue and event logistics.
The following is a description of the training in each area.
Organization
It is important to make sure that the program has a strategy that will be understood by the participants of the event, including interested persons and representatives from the business, that the work of the teams corresponds to this strategy, that there are people in all key roles in ART.
Below are examples of questions that help determine this readiness.
- Scope of work and planning context: “Is the planning framework clear: product, system, technology area? Do we know what teams are needed for joint planning? ”
- Business coherence: “Are priorities agreed between business representatives?”
- Agile teams: “Do we have Agile teams? Are all teams staffed by developers and testers? Is Scrum master and product owner defined everywhere? ”
Content
It is equally important to correctly convey the concept and business context, therefore, all necessary stakeholders should be present at the session. For this, PI planning includes the following activities:
- An overview of the current business context from top management.
- An overview of the product concept prepared by product managers based on the top 10 priority features from the program’s backlog.
- An overview of the architectural concept is usually provided by the technical director or architect to talk about technological innovations to support the implementation of features, as well as non-functional requirements.
Infrastructure
It is not so easy to prepare the venue and technical infrastructure of the event with a large number of participants, especially if there are remote participants.
The following are points to consider.
- Space: the room should be spacious enough for all participants, including space for breaks if necessary.
- Technical support: pre-identify the people who will help you with setting up, testing and solving problems with the technical infrastructure at the event.
- Communication channels: Distributed scheduling sessions require primary and backup channels for broadcasting audio, video, and presentations.
The agenda
In general, the event follows the standard agenda, which is shown below. Next, we will consider each block of the event in more detail.
Standard Agenda for a 2-Day PI Planning Session
Day 1
Business context
The top manager or business owner describes the current state of the business and how well the current solutions in the future will satisfy the needs of customers.
Product concept
Product managers present the current concept of the program, usually talking about the most important 10 upcoming features, about changes from the previous PI-planning, as well as about any future milestones.
Architecture and Development Practices
System architect presents an architectural concept. In addition, a senior development manager can talk about changes in Agile development practices, such as test automation and continuous integration, that need to be considered during the next PI.
Planning context
The facilitator, RTE, explains the planning process and the expected results from the event.
The facilitator explains the goals and plan of the PI planning session for 100 people
Team Work - 1
Teams for each iteration estimate the amount of work that they can perform (capacity) and determine the backlog elements that are most likely necessary for the implementation of features. Each team creates draft plans that are visible to all the other participants, iteration after iteration. At this time, they identify risks and dependencies, determine the draft goals of the team on PI. The team also adds features to the program board.
Teams identify interdependencies in PI planning sessions per 100 people
Reviewing draft plans
Reviewing plans is carried out with strict time limits for the performance of each team. At this time, the teams present the main planning results: draft goals, potential risks and dependencies. Representatives from the business, product managers, other teams and stakeholders ask questions and give feedback.
The product owner presents the plan her team assembled at a 100-person PI planning session.
Management Review and Problem Solving
It is likely that the plans will need to be finalized taking into account the expected amount of work, limited resources and identified dependencies. During this meeting, management approves the scope of work and corrects deficiencies in the plans. RTE holds a meeting with all key stakeholders until they identify achievable goals.
Day 2
Change plans
The next day, the event begins with the fact that the manual describes all the changes in the planned amount of work and resources.
Team Work - 2
Teams continue planning based on the results of the previous day, making the necessary changes. They finalize their goals on PI, and business representatives evaluate the business value of these goals.
Planning results for one of the teams at the PI planning session for 100 people
Presentation of final plans
All teams briefly present their plans. At the end of each team’s performance, risks and blockers are voiced, but teams are not allowed to discuss and seek solutions in this short period of time. If the plan is accepted by customers, the team posts flipcharts with their goals for PI and risks in the most visible place, so that everyone can see in real time the formation of the overall goals of the program.
Program risks
During planning, teams discover critical risks and blockers at the program level, which may affect the ability of teams to solve their problems. These issues are addressed by all participants. All risks, one after the other, are clearly, honestly and openly classified into the following groups:
- Resolved - the team agreed that the problem is no longer relevant;
- Owned - the issue cannot be resolved at the event, but someone agreed to further resolve this issue further;
- Accepted - some risks are facts or potential events that simply should be understood and taken into account in future work;
- Mitigated - the team can determine a plan to eliminate the consequences of this risk or blocker.
Risks of the program at the PI planning session for 100 people
Voting
After the risks of the program have been considered, the teams vote for realism and willingness to take responsibility for achieving these program goals on PI. All team members raise their hands, showing one to five fingers.
Voting rules at a PI planning session for 100 people
If, on average, three or four fingers are raised for all teams, then management can accept such obligations. If on average there are less than three fingers, then the necessary changes are made to the plan and all plans are processed. Everyone who raises two or less fingers should express their concerns. This allows you to either identify a new risk that requires re-planning, or simply convey important information to everyone.
Voting at rehearsals with Scrum-masters and product owners of the teams before the PI-planning session for 100 people
Alteration of plans, if necessary
If necessary, teams revise their plans until a level of trust is sufficient for them. This is the first moment in the entire PI-planning session, when time constraints go by the wayside - more important is the consistency of plans and the willingness of teams to take responsibility for their implementation.
Retrospective
Finally, RTE conducts a short retrospective session to determine what worked out well, what was not good, and what could be done better at the next PI planning session.
After that, you can discuss further steps, put goals and user stories in IT tools for managing Agile projects, plan upcoming key activities and events ... and even tidy up the room!
results
Successful PI planning gives you three key artifacts.
- A set of SMART goals for PI teams that each team defines on its own. For each goal, representatives from the business determined the assessment of its business value.
- The program board, which shows the delivery dates of new features, dependencies between teams and dependencies on other ART, as well as important milestones.
ART One Program Board - The agreement of all ART teams with the realism of PI goals and their willingness to take responsibility for achieving these goals.
Practice
In this video, our PI planning practice:
PS . If you are interested in materials on the transformation of processes in large companies, we recommend the Enterprise Agile Russia group on Facebook. We will discuss scaling approaches such as SAFe and LeSS.