### 5.1.2 The Structure of an Iteration Planning The Iteration Planning is there to help the Agile Project Core Team (A-PCT) plan the implementation of the Work Items List (WIL) iteratively. Because it reflects the work to implement a solution, the WIL must always be prioritized to allow the Product Owner (PrOw) proposing an Iteration Goal that is relevant and aligned. When proposing the Iteration Goal, the Product Owner (PrOw) is communicating her expectations. With this information and considering capacity and capability, the Agile Project Core Team A-PCT) determines what they need to do, how they plan to do it and how long they expect it to take to validate if the proposed goal is achievable or not. ![[5.1.2 The Organics of an Iteration Planning.png]] By the end of the iteration planning, the Agile Project Core Team (A-PCT) should have a clear and well-defined Iteration Goal and a generated iteration Work Items List, which are vital elements in the Iteration Plan. After clarifying iteration planning organics, it's essential to understand proper implementation steps. To help getting the best from the Iteration Planning, PM2-Agile proposes a sequence of steps that involves the entire Agile Project Core Team (A-PCT). These steps include the need for the team to determine its capacity, define the work to be done, have a temporary agreement on the iteration goal proposed by the Product Owner (PrOw) and have a vote of confidence. #### 5.1.2.1 Determine Team’s Capacity A crucial element in the Iteration Planning is understanding if the Agile Project Core Team (A-PCT) will be able to achieve the iteration goal. To verify this, each Agile Team Member (ATeM) building the solution must know how much time (in hours, preferably) will be able to dedicate to the next iteration. This exercise should also consider team members’ holidays, public holidays and other events. For instance, let’s assume that each working day has seven hours of available work. Let’s also say that an iteration of ten calendar days has only nine working days (one is a public holiday). To determine the Agile Team Member’s capacity, one needs to compute the following data: - Capacity: 9 days x 7 hours = 63 hours Therefore, the Agile Team Member (ATeM) will have sixty-three hours available to help the team reach the iteration goal. Other aspects like unplanned events, bugs, corporate meetings, etc may also impact overall availability and should be considered as well. These aspects are described in the Guidelines section below. #### 5.1.2.2 Agree on the Iteration Goal Defining the iteration goal is the most important aspect of an Iteration Planning, as this will keep the Agile Project Core Team (A-PCT) focused on what is important. Defining the Iteration Goal is the Product Owner’s (PrOw) responsibility and It must start with a prioritized Work Items List (WIL). The Product Owner (PrOw) evaluates the existing items and formulates an iteration goal that is meaningful and adds value to the solution. Once the goal is defined, the Product Owner (PrOw) relays it to the rest of the Agile Project Core Team (A- PCT) to focus on the most relevant items. Note that an initial agreement does not imply that the iteration goal will be immediately approved as the Agile Team Members (ATeM) that develop the solution need to confirm their availability and capacity. ![[5.1.2 Agree on the iteration goal.png]] #### 5.1.2.3 Define the Work to be Done With the team’s availability and the iteration goal defined, the Agile Project Core Team (A-PCT) can determine the work that needs to be done. The team should focus on the items in the Work Items List (WIL) that contribute to the iteration goal. For each item, they determine the tasks they need to execute and verify they have the availability and capacity to complete them. They will perform this routine for each relevant item from the WIL until they exhaust their capacity. To Define the Work to be Done, PM2-Agile recommends the following steps: 1. The Agile Project Core Team (A-PCT) picks up the first item in the WIL related to the iteration goal. 2. As a team, they identify the tasks they believe are required to build and deliver that item. 3. Each task is chosen by an Agile Team member (ATeM) for implementation. 4. The Agile team member (ATeM) estimates the task (should be no bigger than 12 hours). 5. Each Agile team member (ATeM) verifies availability after taking the task. 6. If every Agile team member (ATeM) still has availability, the team picks up the next Work Item from the Work Items List (WIL). 7. If an Agile team member (ATeM) verifies the task cannot be delivered, other team members perform a check. If no other team member can perform the task, the team should stop progress. 8. Once the team reaches their full capacity, it’s time to to evaluate if the iteration goal can be reached or it needs to be adjusted. This is the goal of the next step: the Commitment Agreement. #### 5.1.2.4 Commitment Agreement The Commitment Agreement formalizes agreement between the Product Owner (PrOw) and the rest of the Agile Team Members (ATeM) per the Iteration Goal. This agreement is critical, since it aligns everyone’s expectations transparently in terms of team delivery. There are three possible scenarios in initiating the Commitment Agreement. The first (and simplest) is when the team confirms (based on the information they collected during the previous steps) they can reach the Iteration Goal. In the second scenario, the Agile Team Members (ATeM) find they cannot achieve the Iteration Goal. A discussion with the Product Owner (PrOw) allows the team to propose changes to the iteration goal to make it less ambitious and thus, achievable. The Product Owner (PrOw) will evaluate the feedback given by the team and will try to adjust accordingly. In the third scenario, the Agile Team Members (ATeM) find they can deliver beyond the Iteration Goal. A discussion with the Product Owner (PrOw) allows the team to confirm that the Work Items delivered beyond the Iteration Goal are indeed the most relevant ones. #### 5.1.2.5 Vote of Confidence Many aspects, opinions and adjustments are shared and discussed during an Iteration Planning ceremony, which can considerably change the initial strategy and direction. As such, it’s very important that all Agile Team Members (ATeM) take a couple of minutes to think about the proposed strategy and express how comfortable they are with it. To facilitate the vote of Confidence, each Agile Team Member (ATeM) and the Product Owner (PrOw) will use a finger count to choose a value from 1 to 5 reflecting confidence in the proposed plan. A “1” means “No confidence at all” while a “5” means “I’m 100% that we will complete it successfully”. The steps are the following: 1. Agile Team Members (ATeM) and Product Owner (PrOw) take a minute to assess their confidence. 2. On the count of three, everyone will raise the hand at the same time. 3. Initially, the facilitator asks the “5’s” to lower their hands, followed by the “4’s” and finally the “3’s”. 4. Team members who rate “2’s” or “1’s” should explain their concerns and doubts. 5. The entire Agile Project Core Team (A-PCT) will then perform the required adjustments (if any) to address those concerns. Once all the concerns are discussed and there are no more “1’s” or “2’s”, the Vote of Confidence ends and with it, the Iteration Planning.