PI Planning is a cadence-based event for the entire ART that aligns teams and stakeholders to a shared mission and vision.

PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe.

Details

The Agile Manifesto states, “The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.” SAFe takes this to the next level with PI planning.

Where possible, everyone is face-to-face (virtually or physically), and these large-scale PI planning events now occur within many enterprises worldwide. They have clearly shown real financial ROI, not to mention the intangibles that happen when the team of Agile teams creates a social construct that is personally and collectively rewarding.

It may not always be practical for the entire Agile Release Train (ART) to collocate; however, in our current times, COVID-19 has created a situation where this isn’t an option. While physical face-to-face planning has benefits, the unwritten SAFe ‘rule’ is that the people who do the work plan the work. Real-time, concurrent, virtual, face-to-face planning has now proven effective when physical presence is not possible. Indeed many ARTs have been flourishing in creating a hybrid situation where several teams join remotely, as shown below in Figure 1.

The advanced topic article, Distributed PI Planning with SAFe, provides additional guidance and considerations for successfully managing these scenarios.

PI Planning has a standard agenda that includes a presentation of business context and vision, followed by team planning breakouts—where the teams create their Iteration plans and objectives for the upcoming PI. Facilitated by the Release Train Engineer (RTE), this event includes all members of the ART and occurs within the Innovation and Planning (IP) Iteration. Holding the event during the IP iteration avoids affecting the scheduling or capacity of other iterations in the PI. PI Planning takes two days, although the ART can extend this timebox to accommodate planning across multiple time zones.

Business Benefits of PI Planning

PI planning delivers many business benefits, including:

• Establishing face-to-face communication among all team members and stakeholders
• Building the social network the ART depends upon
• Aligning development to business goals with the business context, vision, and Team and ART PI objectives
• Identifying dependencies and fostering cross-team and cross-ART collaboration
• Providing the opportunity for just the right amount of architecture and Lean User Experience (UX) guidance
• Matching demand to capacity and eliminating excess Work in Process (WIP)
• Fast decision-making

Inputs and Outputs of PI Planning

Inputs to PI planning include:

• Business context (see ‘content readiness’ below)
• Roadmap and vision
• Highest priority Features of the ART Backlog

A successful PI planning event delivers two primary outputs:

• Committed PI objectives – Each team creates a set of SMART objectives with the business value assigned by the Business Owners.
• ART planning board – Highlighting the new feature delivery dates, feature dependencies among teams, and relevant milestones

Preparation

PI planning is a significant event that requires preparation, coordination, and communication. It is facilitated by the RTE and event attendees, including Business Owners, Product Management, Agile Teams, System and Solution Architects, the System Team, and other stakeholders. The RTE must schedule all PI planning in advance to be well prepared. The active participation of Business Owners in this event provides an essential Guardrail on budgetary spending.

For the event to be successful, preparation is required in three major areas:

1. Organizational readiness
2. Content readiness
3. Logistics readiness

The following sections describe these three areas.

Organizational Readiness

Before PI planning, there must be strategy alignment among participants, stakeholders, and Business Owners. Critical roles are assigned. To address this in advance, however, event organizers must consider the following:

• Planning scope and context – Is the planning process’s scope (product, system, technology domain) understood? Do we know which teams need to plan together?
• Business alignment – Is there reasonable agreement on priorities among the Business Owners?
• Agile teams – Do we have Agile teams? Are there dedicated team members and an identified Scrum Master/Team Coach and Product Owner for each team?

Content Readiness

It’s equally important to have a clear vision and context so that the right stakeholders can participate. Therefore, the PI planning must include the following:

• Executive briefing – A briefing that defines the current business context
• Product vision briefing(s) – Briefings prepared by Product Management, including the top 10 features in the ART Backlog
• Architecture vision briefing – A presentation made by the CTO, Enterprise Architect, or System Architect to communicate new Enablers, features, and Nonfunctional Requirements (NFRs)

Logistics Readiness

Preparing an event to support a large number of attendees isn’t trivial. This prep can include securing and preparing the space for physically collocated planning. For remote attendees or a fully distributed PI Planning, this also includes investment in the necessary technical infrastructure. Considerations include:

• Locations – Each location where planning takes place needs preparation in advance.
• Technology and tooling – Real-time access to information and tooling to support distributed planning or remote attendees
• Communication channels – Primary and secondary audio, video, and presentation channels must be available

Standard Agenda

The event follows an agenda similar to Figure 2. Descriptions of each item follow. For guidance on adapting this agenda to support planning across multiple time zones, refer to the advanced topic article, Distributed PI Planning with SAFe.

Figure 2. Standard two-day PI planning agenda

Day 1 Agenda

• Business context – A Business Owner or senior executive describes the current state of the business, shares the Portfolio Vision, and presents a perspective on how effectively existing solutions address current customer needs.
• Product/solution vision – Product Management presents the current vision (typically represented by the top ten or so upcoming features). They highlight changes from the previous PI planning event and any relevant milestones.
• Architecture vision and development practices – The System Architect presents the architecture vision. Also, a senior development manager may introduce Agile-supportive changes to development practices, such as test automation, DevOps, Continuous Integration, and Continuous Deployment, which the teams will adopt in the upcoming PI.
• Planning context and lunch – The RTE presents the planning process and expected outcomes.
• Team breakouts

  1 – In the breakout, teams estimate their capacity for each Iteration and identify the backlog items they will likely need to realize the features. Each team creates draft plans, visible to all, iteration by iteration.

During this process, teams identify risks and dependencies and draft their initial team PI objectives. The PI objectives typically include ‘uncommitted objectives,’ which are goals built into the plan (for example, stories that have been defined and included for these objectives) but are not committed to by the team because of too many unknowns or risks. Uncommitted objectives are not extra things to do in case there is time. Instead, they increase the reliability of the plan and give management an early warning of any objectives that the ART may not be able to deliver. The teams also add the features and associated dependencies to the ART Planning Board, as shown in Figure 3.

Figure 3. ART planning board showing features and dependencies

• Draft plan review – During the tightly timeboxed draft plan review, teams present key planning outputs, which include capacity and load, draft PI objectives, potential risks, and dependencies. Business Owners, Product Management, and other teams and stakeholders review and provide input.
• Management review and problem-solving – Draft plans likely present challenges like scope, people and resource constraints, and dependencies. During the problem-solving meeting, management may negotiate scope changes and resolve other problems by agreeing to various planning adjustments. The RTE facilitates and keeps the primary stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives.

Solution Trains often hold an additional management review and problem-solving workshop after the first day of planning to address cross-ART issues. Alternatively, the RTEs of the involved trains may talk with each other to discuss the problems for the ART’s specific management review and problem-solving meeting. The Solution Train Engineer (STE) helps facilitate and resolve issues across the ARTs.

Day 2 Agenda

• Planning adjustments – The next day, the event begins with management presenting changes to the planning scope, people, and resources.
• Team breakouts

  2 – Teams continue planning and making the appropriate adjustments. They finalize their objectives for the PI, to which the Business Owners assign business value, as shown in Figure 4.

Figure 4. A team’s PI objectives sheet with assigned business value

• Final plan review and lunch – All teams present their plans to the group during this session. At the end of each team’s time slot, the team states its risks and impediments and provides the risks to the RTE for use later in the ROAMing exercise. The team then asks the Business Owners if the plan is acceptable. If the plan is accepted, the team brings their team PI objective sheet to the front of the room so everyone can see the aggregate objectives unfold in real-time. If the Business Owners have concerns, teams can adjust the plan to address the identified issues. The team then presents its revised plan.
• ART PI Risks – During planning, teams have identified risks and impediments that could impact their ability to meet their objectives. These are resolved in a broader management context before the whole train. One by one, the risks are discussed and addressed with honesty and transparency and then grouped into one of the following categories:
  • Resolved – The teams agree that the risk is no longer a concern
  • Owned – Someone on the train owns the risk since it cannot be addressed during PI planning
  • Accepted – Some items are simply facts or potential problems that must be understood and accepted
  • Mitigated – Teams identify a plan to reduce the impact of the risk
• Confidence vote – Once ART PI Risks have been addressed, teams vote on their confidence in meeting their team PI objectives

Each team conducts a vote using their fingers (fist of five) or a digital tool for remote events. If the average is three fingers or above, then management should accept the commitment. If it’s less than three, the team reworks its plan. Anyone voting two fingers or fewer should be allowed to voice their concerns. These concerns might add to the risk list, require replanning, or provide information. Once each team has voted, it’s repeated for the entire ART, with everyone expressing their confidence in the collective plan, as illustrated in Figure 5.

• Plan rework – If necessary, teams adjust their objectives until they have high confidence. This additional planning is one occasion where alignment and commitment are valued more highly than adhering to a timebox.
• 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 to do better next time, as shown in Figure 6.

• Next steps – Typically, a discussion about the next steps, along with final instructions to the teams, follows, including:
  • Cleaning up the rooms used for planning (if applicable)
  • Entering the team PI objectives and stories in Agile lifecycle management (ALM) tooling
  • Reviewing team and ART events calendars
  • Determining Iteration Planning and Team Sync locations and timing

After the planning event, the RTE and other ART stakeholders summarize the individual team PI objectives into a set of ART PI objectives (Figure 7) and use this to communicate externally and track progress toward the goals.

Product Management uses the ART PI objectives to refine the roadmap, improving the forecast for the following two PIs.

The ART Planning board is often used during the Coach Sync to track dependencies. It may or may not be maintained (manually) after planning is complete. A digital tool for managing dependencies facilitates their follow-up.

Teams leave the PI planning event with a prepopulated backlog for the upcoming PI. They take their team’s PI objectives, plans, and risks to their regular work area. ART risks remain with the RTE, which ensures that the people responsible for owning or mitigating a risk have captured the information and are actively managing the risk.

Most importantly, the ART executes the PI, tracking progress and adjusting as necessary as new knowledge emerges. Execution of the PI begins with all the teams conducting planning for the first iteration, using their PI plans as a starting point. It offers fresh input for the iteration planning processes that follow. Since the plans created during PI Planning did not consider detailed story-level acceptance criteria, the team will likely adjust the first and subsequent iteration plans.

Figure 7. ART PI objectives

Solution Train PI Planning

This article focuses on the planning activities of a single ART. However, large Value Streams may contain multiple ARTs and suppliers. In this case, the Solution Train provides coordination using Pre-Plan and Coordinate and Deliver activities.

Learn More

[1] Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled, Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020.

Account Holder name nghĩa là gì?

Người nắm giữ tài khoản là người đứng tên mở tài khoản và là chủ sở hữu hay người đại diện chủ sở hữu thực hiện quyền sở hữu đối với tài khoản ở tổ chức quản lý tài khoản.

Account number của ngân hàng là gì?

Số tài khoản ngân hàng là số được cấp khi bạn mở tài khoản ngân hàng được ngân hàng cung cấp qua email hoặc in trong một tờ phiếu. 1. Số tài khoản ngân hàng là một tập hợp các chữ số được sử dụng để xác định một tài khoản ngân hàng cụ thể, chẳng hạn như tài khoản séc hoặc tài khoản thị trường tiền tệ.