Iteration a.k.a Sprint Planning: Part 3
Continued from Iteration a.k.a Sprint Planning: Part 2
Now that we have all the ingredients ready and handy let's gather together and cook a beautiful dish!! Now mind you, we are not just preparing "any" dish with whatever ingredients we have, we are preparing a "specific" dish.. so in that sense focus and have a clarity on the end goal that you want to achieve.
End goal and desired output (artifacts) of iteration planning is to -
- The iteration goal (ensure that team is aligned to the goal that was defined during the PI planning)
- Iteration / Sprint backlog
Assuming that you have invited all the relevant stakeholders, here is how one can approach the Iteration planning, the "how" part -
- First, team determines its capacity based on number of members allocated to the team and vacations/off days.
- Based on the capacity, team them forecasts the story points they believe they can deliver in that iteration/sprint.
- Based on the forecast, team "loads the sprint" with the backlog items as per the priority that Product Owner recommends. Backlog items may have items those have spilled over from previous sprint, any defects/bugs, spikes etc. and/or items from product backlog based on the priority.
- Once the sprint is loaded, team re-looks at the newly created sprint backlog, breaks the items in sprint backlog into manageable tasks and re-validates the estimation to ensure it matches the capacity.
- It is recommended not to "load" the sprint to it's fullest capacity (100%). We need to reserve some capacity to perform other sprint activities such as iteration review/demo, retro, backlog grooming, sprint planning, taking care or other activities such as support, maintenance and some buffer that would take care in case certain spike / backlog items takes a bit more than what was initially planned. This totally up to the individual teams to decide on how much time they would like to reserve for such activities.
- Breaking down the backlog items in tasks helps team to clearly see what it would take to complete the tasks and adds/removes the tasks from the iteration backlog accordingly.
- Once team acquires the the confidence about completing the backlog items among themselves, they convert that confidence into commitment in the form of sprint goal that keeps the team focused on what they are planning to achieve during the sprint.
- Sprint goal is a team activity; I had to specially mention this as many time team looks at Scrum Master or Product Owner or someone senior in the team to come up with the sprint goal which is not correct. Product Owner/Scrum Master can guide the team on the goals but team has to come up with their own words/text as sprint/iteration goals. This activity re-validates teams understanding of sprint priorities, overall picture and alignment with PI objectives.
- We had a practice to add a backlog item (preferably smaller in size e.g. 5-10% of the team's capacity) as stretch goal item that team would attempt to complete once team takes care of the committed items of the backlog. Please note that stretch goal is not part of Sprint goals.
