Perspectives in Iteration Planning : From a Developer to a Product Owner to a Business Analyst

Mohit Garg
8 min readMar 1, 2022

--

Image source : Storiesonboard

Iteration Planning is an important event in the complete cycle of an iteration where the team members meet up and discuss what they can realistically achieve in the upcoming iteration.

Since we are discussing planning here, there are few important factors we must be aware of that impact iteration planning.

  • Team velocity
  • Team capacity
  • Spillover from previous iteration
  • Prioritised backlog
  • Team’s relative experience of tech/project context

For sake of consistency, I would coin the above factors as Iteration Planning Factors for use throughout this article.

While most of the factors impacting the iteration plan are tangible if we consider the first four points above. However, how a team member’s relative experience can impact the planning is not something that can be determined in an objective manner.

Let’s take some examples to understand all of the above factors. I would share my collective experiences in different roles on how I have seen Iteration planning play out. While steps for planning an iteration remained largely the same, the difference lies in the fact of how they got executed.

Steps involved in building an iteration Plan

Disclaimer : Not all methods mentioned here would apply in all settings . They have been mentioned here only to bring perspective of some of the different ways Iteration Planning may be done.

Method 1 : Discuss and Plan along with the team

First, I would like to discuss the iteration planning scenario from a developer perspective which was the first project I had worked on following the Scrum Model.

Below steps describe how our Iteration Planning was conducted including the iteration pre-planning and iteration planning meeting (IPM).

Iteration Pre-Planning

PO walked the team through the prioritised stories for the coming iteration. Queries raised by the team were clarified.

How the Iteration Planning Factors fared

  1. Team velocity :With the team having worked together for a long duration (more than 6 iterations), team velocity had reached a fairly consistent value.
  2. Team capacity : We discussed the capacity of the team during the iteration plan meeting(IPM) and any planned individual or office holidays. Accordingly, available capacity for the iteration was calculated.
  3. Relative experience: Team was already working for the last few months on the same product. So everyone was well equipped with tech know-how of upcoming work and the requisite project knowledge. So no impact on planning had to be considered.
  4. Spillover consideration :For any spillover, the team checked the pending work in the ongoing tasks and calculated the remaining capacity to pick up new work.

Planning meeting

PO had already put in an estimate basis his experience of earlier delivered stories as an indication for prioritised backlog items.

However, the team was free to discuss and change the estimates if needed. In case, there was a big discrepancy in estimates, the team could discuss with the PO if there is an understanding gap between what the PO wanted and the team’s understanding of the requirements.

Eventually, the team would discuss the tickets in the prioritised backlog and plan them in Sprint as per its available capacity under guidance of Scrum Master.

Method 2 : Plan ahead with Team Lead/Manager and share Plan with the team

When I moved to the next project, my role had changed and I had taken up the role of being a Product owner.

Below is my experience on planning an iteration as a Product Owner and the difference compared to the first method.

Iteration Pre-Planning

We did the pre-Planning meeting with all the teams together where we would go over the prioritised backlog items.

Prioritised Backlog items were determined on the basis of items slated to be showcased for upcoming Client showcases and dependencies we had to take care of to unblock other teams in the project.

How the Iteration Planning Factors fared

As soon as the previous iteration was planned, I had to start creating a draft plan for the upcoming iteration with my manager where we would align stories across different teams considering their ownership and experience in that functional area and capacity to complete the required work during the iteration.

A couple of days before the end of the iteration, we would hold a meeting with all team’s leads to discuss Iteration Planning factors and adjust the draft plan.

  1. Team Velocity : With new teams built for the project, velocity took time to settle. So for every iteration, we looked into how the teams fared and then adjusted plans accordingly for the upcoming iteration.
  2. Team Capacity : For calculating team availability, capacity planning (somewhat similar to referenced link) was done basis below factors.

(1)Time spent by team members in Sprint ceremonies like daily stand ups, iteration planning, showcases, retrospectives etc.

(2)Time spent by team members in any other non project activities

(3)National/office holidays

(4)Team’s individual planned holidays

Since Planning was done in days, total capacity of team would calculated by following formula

Team capacity = (Working days in iteration * No. of developers) — (Sum of factors mentioned above (i) till (iv))

3. Relative Experience : Team Member’s relative experience would factor into the effective available capacity by considering below factors:

  1. Experience in tech relevant to project
  2. Business knowledge context relevant to team’s tickets
  3. Time Spent in ramping/grooming up to project/tech needs

Considering the above, for each team member, it was calculated how much time they would need to spend corresponding to the above non delivery items and as such, corresponding capacity was reduced to get the final team capacity. This figure would vary from a reduction of 0–50% of capacity per team member.

As the team matured, this factor could become 0 or remain between 0–10% at max.

4. Spillover consideration : Spillover considerations remained similar as explained to the initial scenario for Iteration planning.

Eventually, a Gantt would be prepared per team which looked like below on how the stories would be divided amongst team members.

Note : Team Members initials like AK, MG etc. are for illustration purposes only.

Planning meeting

After the initial plan was done with team leads, planning also had to be done and shared with account and scrum teams.

Account Level Planning

Since ours was a large account, we also had to factor in account dependencies and priorities. So before sharing the plan with the teams, we would have an Account wide meeting with all team’s PO’s, managers and PMO so that all teams are aligned.

Team Level Planning

Planning with the team basically had team leads sharing and discussing the plan with team members and going over the details. In case team members had any queries, they were free to reach out to PO.

Since the team also had QA who would test the feature, planning was done in such a way that all work is completed 2 days before the sprint end so as to give sufficient time to QA to test and for developers to fix any bugs coming as a result of the same. This also gave time to developers to look into upcoming iteration work.

Method 3 : Plan ahead with Tech Lead & Iteration Manager , share and discuss with the team

When I changed my role to a business analyst I found significant overlaps with my experience as a Product Owner.

However there are few other differences which I would like to highlight which impacted our Iteration Planning.

  • We have client side PO’s who would help us prioritise on feature level and let us know expected timelines.
  • Story level breakup and plan for the iteration is primarily taken care of by the team
  • Estimations are already done by the team when we do feature breakdown to stories
  • Pair programming based development. So we would have 2 dev pairing up for a ticket.
  • Estimations in story points
  • Since team also supports PROD and there are frequent platform maintenance/improvement tasks that the team had to complete for its owned services. Almost 20–30% capacity of the team have to be reserved/planned for such tasks.

Below is how Iteration Planning differs from the above two methods.

Iteration Pre Planning

As PO is part of recurrent meetings with the team, we do not really need to do pre-planning team meetings and the team is mostly clear on what priorities look like going to the next iteration. If need be, the same is also discussed upfront at the start of any iteration planning meeting.

How the Iteration Planning Factors fared

  1. Team velocity : Since the team was new, we did not have any reference velocity for initial sprints. We checked with existing project personnel on historical data in the project and used that information as a reference and devised what we can realistically plan and achieve in the initial few iterations.

As the team matured, a relatively consistent velocity reached which we would refer for planning.

2. Team capacity : Primarily we considered any holidays and planned leaves to check if we need to plan at reduced velocity.

3. Relative experience: Our team was built from scratch with only 2 people who had prior experience in the project. So there was a fair amount of context building required around the same and most of the people were also new to the technology being used in the project.

So considering the above factors, we knew that velocity initially would be low and it would get better incrementally. As estimation was done together by team for stories for each feature, we could get estimates considering how comfortable the team was feeling at that point of time.

4. Spillover consideration : Spillover considerations remained similar as explained to the initial scenario for Iteration planning.

Planning meeting

We follow a definite template in order to conduct IPM which would look like below.

  • Above structure helped us brought transparency to the team
  • Myself along with tech lead and iteration manager discuss the tickets which shall be placed in iteration before hand
  • During IPM, we discuss the tickets planned and check with the team if they have any concerns on meeting the target or any other topics which shall be in the iteration so that we can adjust our plan accordingly.
  • We also go over completed stories in last iteration so as to feel that sense of accomplishment.
  • We also look into the spill over and discuss why the spillover happened and see if we can avoid these in future iterations.

Summary

As we can see, iteration Planning could be done in different ways in different circumstances but the primary factors which impact it remain largely the same. Most critical things eventually that makes iteration planning a success are based upon

  • Knowing your team and their strengths
  • Understanding client’s priorities and expectations
  • Avoiding overcommitment

I have also compared the above 3 methods and reflected upon their pros and cons. You can check out the same below.

Comparision between methods explained above

These factors helped me every time as we executed our plans for delivery.

#ThoughtworksIndia #TWBloggersClub

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Mohit Garg
Mohit Garg

Written by Mohit Garg

Business Analyst at Thoughtworks

No responses yet

Write a response