What Is Iteration Planning and How to Do It Effectively?

Iteration planning is considered as the lifeline of Agile framework and plays an important role in the cadence delivery of the product in incremental releases. It is very critical to do iteration planning effectively to ensure we remain productive and add business value with each sprint. An Iteration Preparation Meeting is a crucial ceremony during an IT project development stage for every Agile team that uses Scrum. It's where the team gets together in the next Iteration to chat about work and is structured to help provide a consistent focus and direction for the work ahead.

Iteration Planning (Overview)

Iteration planning is one of the important ceremonies in the Agile framework. The aim of iteration planning is to set a few high-level goals for what to achieve during the iteration, to create a sufficiently comprehensive plan detailing who needs to do what to achieve those goals, and to determine how to measure what you have achieved. Iteration planning is usually conducted at the start of an iteration with the entire team in a group, including key stakeholders, generally lasting one to a few hours. It means that the whole team knows what needs to be achieved, and they are committed to the results of the team.  

In certain cases, it is preferred to allow a smaller subset of individuals, such as the project manager, an architect and an analyst to meet in advance with a draft iteration plan. For the team to complete the collection of top-ranked product backlog products, the iteration planning plays an important role. Based on the duration of iteration and team velocity, this is a time-boxed arrangement. 

A crucial feature of an iteration is to concentrate the team on a measurable benefit that is deliverable in the short term. To make sure that you do not lose concentration on what to achieve during the iteration, document 1-5 high-level targets. Usually, for each iteration, the project plan may specify one or more goals, and those goals are used as a starting point. If you need to explain the goals when you prepare your iteration, do so. 

Inputs to IP & Planning the Iteration

The IP goals are typically based on the following factors: 

Critical risks not yet mitigated: Iteration priorities also involve the most significant risks being pushed down.  

The time allocated to the iteration: Iterations are timeboxed, so the Project Manager must ensure that the iteration priorities are achievable in relation to the time and resources allocated to the iteration.  

The highest priority features: To ensure that the essential features of the application are built and checked early on, specifications are prioritized. 

• Iteration Planning Steps- Before starting, make sure, the user story in the product backlog have been sized by the team and a relative story point value has been assigned. The product backlog is stacked to reflect the product owner 's preferences. For these rated backlog products, there is a general understanding of the acceptance requirements. Per iteration, there is an iteration plan that can describe who will execute the work item for how long a time.  

Since iterations are time-boxed, by calculating how many hours of real work can be taken on, we need to consider how big our 'box' is. Let's say you have 6 team members, and you have 15 working days in your iteration, and you can do 5 real hours of work per person and day on average. This will earn you 6x15x5h = 450 real work hours. Notice that only 4-6 hours of actual project work every day is done by the average team member, with the remainder being consumed by e-mails, meetings, and other routine tasks not specifically related to the project. For all the high-priority items in the Work Items List, the team can then review and amend priorities to ensure that a significant work item is not skipped, which will otherwise fall far below the list of what can be taken on in this iteration. The essential features for a product backlog item for the purpose of iteration planning are:  

• The iteration is small enough to be done.  
• We can check whether it was correctly implemented or not. 

There are two steps in designing the contents of an iteration: deciding how many user stories will fit into the iteration, then breaking down those stories into assignments and appointing owners. Sizing refers to a user story's relative reach, which is normally performed in relative points. When it is first developed, during backlog refining sessions, and before the planning meeting, the team regularly estimates the size of a user story. The team should know what story at the top of the backlog will fit into the iteration by the time preparation starts. Estimation refers to the breakdown of tasks into a user narrative. When the steps taken to produce a user story are established, an hourly estimate is provided for each mission. This figure keeps the team updated on how close it is to completing a mission. The team also recognizes how many task hours each member of the team has available in the iteration (known as capacity) to avoid overburdening of individuals. 

• In planning sprints, there are two general approaches: velocity-driven planning and capacity-driven planning. 
• Velocity driven Sprint Planning 

 Let 's start with velocity-driven sprint planning since it's the simplest to explain. Velocity-driven sprint preparation is based on the idea that in the next sprint, the amount of work a team can perform is approximately equal to what they have done in previous sprints. This implies, of course, that the team is working on similar work from sprint to sprint, consistent sprint lengths, and so on, such as a constant team size. Each of these assumptions is usually true and violations of the assumptions are easily recognized that is, the team knows this in advance when a sprint switches from 10 to nine working days, as in the case of a holiday.

The following are the phases in velocity-driven sprint planning:  

• Determine the historical average velocity for the team.  
• Select the number of items for the product backlog equal to that velocity.

Most teams stop there. Others include an extra step:  

• Identify the activities involved in the user stories chosen to see if it feels like the correct amount of work.  

And there will be some teams moving even further to:  

• Estimate the assignments to see if the task total is in line with previous sprints. 

Capacity driven planning 

The product owner, the Scrum Master and all members of the agile team are involved in a capacity-driven sprint planning meeting. The product owner brings into the meeting the top-priority product backlog items and presents them to the team, usually beginning with a summary of the high-priority items collection.

After a high-priority item has been selected, team members discuss the work involved and determine the activities needed to produce the product backlog item. The hours for each item would also be approximately calculated by most teams. These figures are tentative since the figures can only be used to impact the number of items that are brought into the sprint and the product backlog. Estimates do not need to be accurate to do so. Do not ask or expect a team to think about any job that will be completed during the sprint. That is not only unlikely, it is needless, too.

The team members ask themselves, "Should we commit to this?" after they have defined tasks and approximately calculated the hours for that one product backlog item. When the team decides that a product backlog item can be shipped, they pick another item and repeat the procedure. And they continue to repeat it until anyone says that they are unable to commit to the product backlog item chosen. If someone is unable to complete the item in the sprint, team members can normally address the situation and see if someone else is available to help. Maybe a DBA with rudimentary JavaScript expertise will assist an exhausted developer of JavaScript. 

You may have noted that no story point or velocity has played a role in the process so far. Although I still recommend providing rapid, high-level estimates of product backlog items in story points.  

• Iteration Planning Attendees: These are the below attendees for IP ceremonies: 
• Scrum Master: The scrum master serves as an agile distribution team facilitator. 
•  Product Owner: The product owner deals with the comprehensive view and approval conditions of the product backlog. 
•  Agile Team : Agile implementation determines their objectives and sets the estimates of effort necessary for the commitment to be met. 
• Iteration Planning Agenda : The following is an example agenda for iteration planning:  
  • Measure the iteration's available team capacity.  
  • Discuss each story, discuss extensive acceptance requirements, and use story points to provide estimates.  
  • When the team runs out of capacity, preparation ends. 
  • Determine and settle on the objectives for iteration. All should be committed to their goals.  

Criteria for acceptance are created through dialogue and cooperation with the product owner and other stakeholders. The Product Owner may adjust the rating of the story based on the story's estimates. 

• Velocity Calculation 

Velocity is a measure of the amount of work that a team can do during a single sprint and is Scrum 's main metric. Velocity is determined by summing the points for all completely completed User Stories at the end of the Sprint. Dividing the total number of story points completed by the number of sprints includes the real velocity. For instance, if a total of 70 points were achieved by the development team over two sprints, the actual velocity of the team will be 35 points per sprint. 

• Capacity planning 

The agile team quantifies their capacity to do work. Each member of the team decides their availability, considers time off and other possible responsibilities. Other standing responsibilities, such as maintenance, are also taken into account in this operation, which is distinct from the creation of new stories. Using their historical velocity as a starting point, the team makes changes to assess the actual potential for the iteration based on the unavailable time and team members. 

• Story Analysis & Estimation

The team backlog is checked once the team capacity has been identified. Each story, covering relative difficulty, scale, complexity, ambiguity, technical challenges, and requirements for acceptance, is addressed. In order to maintain a common understanding of the individual behavior of each story, teams also use Behavior-Driven Production (BDD). Finally, for the story, the team agrees to a size estimate. Usually, there are also other types of stories on the team backlog, including enablers that might represent infrastructure work, POC, and architectural improvements, as well as work and defect refactoring. They also prioritize and estimate these things. 

In Scrum, the estimation of the story point of the team, and the resulting velocity, is usually a local and independent matter. The fact that a small team might estimate their velocity to be 50 in such a way, while another larger team estimates that their velocity is 13, is typically not a concern. However, in SAFe, the calculation of the story point must be standardized, so that assessments of features or epics that require the help of several teams are based on the same concept of the story point, allowing a common economic decision-making basis 

• Relative Estimating, 

Velocity, Capacity, and Normalizing Story Point Estimating- In order to reasonably estimate a story, Agile teams use story points. With relative estimation, the size (expected effort) is compared to another story for each story. An eight-point story, for instance, is four times the effort of a two-point story. The pace of the team is equivalent to the historical average of all completed stories per iteration. The starting point for estimating the potential of a team for a future iteration is velocity. Knowing the skill of a team helps with preparation and helps to restrict Work in Process (WIP). Teams should not take on more stories than their previous pace would imply. Velocity, which is also forecast in story points, is also used to estimate how long it takes to deliver features or epics. 

• Develop/commit to Iteration Goals

When the iteration backlog is known, the team turns its focus to synthesizing one or more iteration priorities that outline the work in that iteration that the team intends to achieve. They are based on the iteration backlog from the PI planning case, as well as the team and program PI goals. The closer the PI planning session is to the IP version, the more likely the PI targets will stay unchanged. When the potential of the team has been met, no more stories are taken from the team backlog in terms of committed stories. At this point, the product owner and the team settle on the final list of stories that will be chosen, and the iteration priorities will be revisited and reaffirmed. The entire team then agrees to the objectives of the iteration, and for the duration of the iteration, the nature of the work remains set. 

• Guidelines for Effective IP 

Some tips for holding an iteration planning meeting are given below: 

• Keep an eye of duration of this event. It should be timeboxed to 4 or less hours. 
• It should be organized by the team and for the team alone. 
• We should keep a check on the historical velocity of team before over-committing the team’s capacity. 

Source. 

Prepare for your project management exam with our online exam prep course! Enhance your skills and confidence to excel in your career with our project management exam prep online.

Conclusion

It is important to ensure that the way you will assess progress at the end of the iteration is transparent to all team members and other stakeholders. The obvious criterion for success should be that you can verify the implemented features. Iteration preparation, either on the first day or a week before the iteration starts, should be performed once per iteration. You should give about 12 hours to finish the process as a facilitator, but there is really no fixed time, it's all about whatever works for your team. Most notably, have fun and remember to celebrate the previous success of Iteration!