You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

Agile : Iteration Planning

0.00 avg. rating (0% score) - 0 votes

“A goal without a plan is just a wish” — Antoine de Saint-Exupery

Agile, It’s all about flexibility in the course of software development phase. But flexibility is not possible without a proper plan in place. Even when we decide the architecture of a software, we often keep in mind that the software stays flexible to any changes in future and therefore design patterns come into picture. There comes Iteration,  a step by step approach. Grab yourself a cup of coffee as we are going to dig deeper into it.

Planning plays a vital role in the software development life cycle. It not only gives a better idea for the upcoming sprint/iteration but for the entire project delivery timelines. This is the reason why agile helps each and every stakeholder involved in the process.

Agile @

We have been following agile for quite a long time now. We implemented it in our own version and convenience and then we learned from the problems we faced in daily process. We iterated over and over and now we are in a place to write such blog posts.

Before moving ahead to the stuff, we would like to portrait a bigger picture of what is actually a iteration and how it is involved as a part of the bigger agile process.

Let us understand it with an example,

Suppose you are preparing for a half marathon 3 months down the line. The date is fixed, the target is fixed and obviously your effort as well.

What next ?

Well you need a #PLAN in place to get ready with the weapons to hit the bullseye.

You need stamina to run the marathon, strong muscles to avoid muscle fatigue, good shoes (if new, get comfortable with them) and many more.

So you start visualizing the end result and hence prepare a road-map to achieve the desirables step by step. And this step by step road-map is actually a bundle of iterations where each step is called one iteration in agile software world.

Similarly in software development,

Deadline is fixed, features/product is fixed and you need some step by step plan to achieve it. And hence we come up with the step by step road-map to analyze the development pace and the assurance of the delivery and hence the iteration. As we go with the book,

Iteration planning is a collaborative effort involving these roles: Scrum Master: Facilitates the meeting. Product Owner: Represents the detail of the product backlog items and their acceptance criteria. Delivery team: Define the tasks and effort necessary to fulfill the commitment.

Iteration Planning @

Iteration planning at naukri starts way before the start of the iteration. Let me guide you through step by step

Step 1 : (Backlog* grooming)

For Iteration X, We start grooming the features (stories*) we are going to deliver in this iteration in iteration X-1. The product owner and some team members take some time out of their capacities and plan for the next iteration in advance.

  • Backlog is nothing but a list of stories in our pipeline for near iterations to come.
  • A user story is a small feature that follows invest.

Follow to know more about user stories.

After the story grooming, the stories are shared with the whole scrum team for their better understanding and to help them prepare for the viewpoint they will put across in pre-iteration meetings. The best thing about backlog grooming is that you have enriched product backlog for the times to come and you have ample number of time to decide the priorities for the same.

Backlog basics :

A product backlog that should follow DEEP principle i,e

Detailed appropriately, Emergent, Estimated, and Prioritised

Typical steps in backlog grooming :

  • Analyse the customer, user and quality assurance team’s feedback
  • Integrate the learning and come up with improvements or features
  • Decide what to do next on the basis of their priorities
  • Write detailed user stories around the features/improvements, decide when to pick them up and enrich the product backlog.

Typical backlog Image could be like this (Image source

Step 2: (Pre-Iteration meeting)

At about the end of Iteration X-1, We commit 1–2 hours of the whole scrum team to discuss the plan for the upcoming iteration. All team members come prepared with their level of understanding on the stories as shared with them in Step 1.

Here we discuss the user stories one after another and let everyone share their viewpoints. We discuss why we are doing such a story from the product owner to understand the product growth and customers feedback.

Sometimes some unexpected scenarios come into picture after these valuable discussions (and that is when reason we do not mind extending these to more than 2 hours at times). We decide the tasks to complete the story and fill it there and then on our jira agile board for future reference.

Moreover we discuss all possible stories that we are going to pick up in the next iteration as suggested by the product owner. With all stories well understood to the team, we go ahead to the next step of planning where we plan for what, why and how the stories must be performed.

Step 3: (Iteration meeting)

Iteration meeting is a one hour opportunity for each stakeholder to come across with their viewpoints and decide what all we are going to do in the coming iteration. Iteration can last anywhere between 1 week to 1 month. We at naukri, keeps our iteration limited to 2 weeks of time. This is the interval well suited for us. You can plan according to your convenience.

A typical iteration planning looks like the image as below.

Source :

Story commitment :

On the basis of the tasks involved and the complexity of the stories decided in the pre-iteration meetings, We estimate the relative size of the story and the individual effort of each team involved in the same. Basis which we plan the handful number of stories to be done in the iteration as per the priority shared by the product owner.

For each story we discuss, it is the team who finally decides whether they commit the story in the iteration or not. Sometimes due to higher story complexity, dependency on some external factors, some understanding issues or no bandwidth left for other sub-team, we do not commit the story.

Committing a story means the team takes the complete responsibility of completing the same (and we often complete as well)

Let me clear the above line with an example,

Before our iteration meeting, we all come prepared with our capacities for the coming iteration. We plan for leaves, training and other organizational level tasks well in advance and share the individual capacities.

Know more about how we plan our capacities here.

Depending upon the total team members, we get the cumulative number of hours of each sub team.

For example, say we have 250 hours of Dev team, 90 hours of Front End team and 120 hours of Quality assurance team. So we have to keep in mind the bandwidth of each team so that we can complete the story in the iteration.

We commit stories so that no team stays dangling in the iteration. In such case, we pick up sub-team independent stories. Like dev only story, unit tests, HTML only stories, optimization tasks from the pipelines, server optimization, internal purpose reporting tools etc.

Changes to the user stories:

“Stay committed to your decisions but stay flexible in your approach”    –  Tom Robbins

Once the story is committed to the iteration, it should not be changed. Any Changes, modify the scope of the story and therefore the scope of iteration which is actually a ignorance of all the planning we did as of now. It also leads to the inconsistent burndown chart and may affect the deliveries of other committed stories as well.

An iteration is recommended to be a small period only because any changes to the user story can be catered in the next iteration as it is not that far. Often we do not get into such problems because what we plan in the iteration is planned well at least for the upcoming 2 weeks.

Only in case of priority one issues (like some issues on production environment) we pick up those immediate issues and this is also prioritized by the product owner.

Step 4 (Iteration)

After the stories are decided, we start the iteration where each team pick up the stories as per the availability and capacities. We plan for the order in which stories will be picked such that each and every resource is completely utilized and we can give maximum throughput.

Now what ?

Now the iteration starts and on the day 1 of the iteration. We decide the stories we are picking up first so that we can deliver them for the next sub-team waiting for the story.

For example, Dev waiting for Front end integration, Quality Assurance waiting for the story’s dev done etc.

We induced a term ‘Timelines’ in the process to solve the intricacies.

Timelines :

A timeline is a whiteboard activity where we have the status of the stories written in the board. As soon as the story is dev done, it moves to quality assurance lane. As soon as it is verified by the Quality team, it is moved to Made Live lane. So we have track of each and every story and its state. This helped us plan our stories better and prepare everyone for their roles in advance.

Typical Timeline at Naukri is as image displayed below for one team.


Columns are like :

Our stories for the iteration. These numbers are our story Ids and respective story points.

  • FED : When the story is with Front End team.
  • DEV : When the story is being developed with backend stuff.
  • QA : When the story is undergoing quality assurance.
  • BLOCKED : When the story is blocked for progress due to some factors.
  • DONE : When the story is done and ready to be made live.

We often add more columns like STAGING / LIVE as well.

We manage our timeline daily during the daily status update meetings.

Know more about DIPSUMs

This helps everyone plan their daily tasks and also the whole team stays updated with the status

of the user stories. This also helps in resolving the dependencies of the team members. If everyone is aware of the user stories and the percentage of tasks completed, anyone can pick up the story in case of any unavoidable circumstances.

and hence the part of the iteration planning for iteration X, afew hours of this iteration will be used to plan the iteration X+1.

This cycle continues.

Learning is a part of planning as well :

After the end of each iteration, we do retrospective meeting to identify the learning, the pitfalls we faced and how we can improve in the next iteration.

These improvements from the iteration X are the part of planning of the iteration X + 1.

Burn Down Chart :

During our iteration, we keep close eye on the burndown chart. It helps us identify whether we are delivering constantly or not.

Velocity Report :

Also we try to maintain and improve the velocity of the team by keeping a check on velocity report during each iteration. This helps us identify how much the team has delivered in the iteration as per the commitment and what is the average story points the team is able to deliver.

Build Quality Report :

We often keep track of the build quality in each and every iteration. To know the quality of the build and the various factors impacting it.

These all reports lead to constant delivery, better quality and a better team.

To know more about agile retrospectives, the above mentioned reports follow

Agile is to make stories live as soon as the story is verified. This is a beautiful process that helps the team to deliver constantly. Iteration over iteration team becomes responsible, brings more ownership and delivers quality product. We go to the granular level possible and deliver them independent of other portions of the feature/product.

An iteration is the whole and sole of the agile. It is the smallest step possible to reach the milestone.

You must have heard that

“A long journey starts with a single step”

So We encourage you to take that single step and make history. We will keep writing such blogs to help you out or share our experiences with the rest of the world.

To know more about agile

Follow agile category link

Stay tuned for more articles.

“We write to help you out, you should share to help others out”