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 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.
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:
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.
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:
Most teams stop there. Others include an extra step:
And there will be some teams moving even further to:
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.
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.
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 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.
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.
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
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.
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.
Some tips for holding an iteration planning meeting are given below:
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!
Your email address will not be published. Required fields are marked *