Iteration Planning In 5 Steps In Azure DevOps

Iteration planning or release planning is the next step right after the product discovery phase, and it’s also a frequently repeating element of software development. The major purpose of iteration planning is to create goals or missions for subsequent sequences of the dev work. After setting up the goal, the planning process has to find related user stories and evaluate and estimate them. Azure DevOps handles iterations well, but before launching the next sequence, the planning could be hulking when you have only a flat list of user stories. That’s why I suggest you go to StoriesOnBoard, as the place where iteration planning happens effectively.

StoriesOnBoard is a visual product discovery and planning tool in which you can create an intuitive backlog. The board can be synchronized in real-time to the Azure DevOps project, so you won’t have to work twice. When you performed the product discovery in StoriesOnBoard, the iteration planning would have been nice and smooth. If you missed the product discovery stage check our previous article about the topic.

What is iteration planning?

The goal of iteration planning is to decide on how much and what user stories of the backlog the development team is going to implement. The team usually agrees upon a set of user stories for the next iteration and formulate iteration goals. During planning, the team must take the team’s velocity, each story’s complexity, and any interdependencies into consideration.

So the outcomes of the iteration planning should include:

  • an iteration backlog containing user stories the team will work on during the iteration,
  • a short description of iteration goals,
  • a strong commitment from the team to deliver.

Pre-planning the iterations

Iteration planning can take place very efficiently if the team has all the necessary inputs at their disposal. First, it is usually the Product Owner (PO) that determines planned iteration goals so that the discussion can be based on those pre-planned goals.

Before we start creating the next iteration or release, I suggest involving your team in a revision of the last iteration. How was the development work? Were there any planning mistakes discovered? Did the dev team finish all the tasks?

All feedback and experiences serve a better planning. Moreover, the development can result in additional backlog items, that you’ll need to add and prioritize.

As I previously mentioned StoriesOnBoard acts as a pool for ideas. I’m sure you don’t routinely organize meetings after each newly added backlog item, but this could be a perfect occasion (when the product team is invited) to discuss and prioritize ideas. So don’t miss the chance to brainstorm with your teammates – it could help them to keep involved in the design process.

Iteration Planning in 5 steps

I’ve summarized in a nutshell the core steps of iteration planning. But as with every agile work template, you could add or cut steps according to your business needs.

Step 1 – Set iteration goals

The next selected goal or features can come from a user request, from the customer, or a priority order/list. In this phase, you should focus on a business or product goal, not on user stories. What is the next goal or the next problem you should solve primarily? If you did this work previously, during the product discovery, you have an easy job. If you have the backlog items only in priority order, then you should collect the related stories into a release. Retelling the narrative flow helps you to check if the iteration contains all the necessary items. Discovered a hole in the backlog? No problem! You have everything (the team and the whole backlog) to find missing stories. Remember, after setting up the integration with Azure DevOps, you can send newly added items with all the details to the project with a single click.

Step 2 – Estimate user stories

In this step, you should involve at least the lead developer to estimate all the user stories. Developers won’t participate in every product meeting, so retelling the user’s stories help them to get into the groove. After estimating all the user stories you’ll get a sight of the required dev time. Using StoriesOnBoard you can easily add estimation to the backlog items. You can use story points and custom estimation units. Moreover, the estimation will be synchronized to Azure DevOps.

estimate user stories

Step 3 – Establish Capacity

Adjusting the iteration to the dev team’s capacity and setting up deadlines could be vital in product development. Keep in mind, that you should deliver as often as you can. Moreover, keeping to deadlines has further importance. To sum up, you should check if the proposed iteration meets the deadlines and the capacity. Calculating the team’s capacity often fails when you don’t check teammate’s availability e.g. holidays, training, etc. If the capacity, the job, and the deadline satisfy each other, you can proceed with the next step.

If you have capacity a problem then you should go thru the user stories again and alternate or postpone some of them. Force the team, to find a simpler solution to the problem.

Step 4 – Planning steps – internal priority

planning steps


Handling inner priorities could be crucial when the iteration contains risky elements such as blockers or integration features (should wait for outer partners eg: API). Consulting with the developers, the product owner should define the opening- the mid-game, and the end-game tasks.

Arranging the user stories in the iteration can express internal priority and you can add more visuality with card labels and tags. After this step, you can push the entire iteration, including all the details, to Azure DevOps with a single click. The structure remains untouched.

Step 5 – Tasking stories

tasking stories


Tasking stories could be an optional step when you use both user stories and tasks. During the high-level planning, you won’t need this level, so I suggest you handle tasks in Azure DevOps and specify them according to dev teams’ practice.

Splitting user stories lets you evaluate and estimate the user story more accurately. If the estimated effort changes after estimating the tasks, StoriesOnBoard will update estimation points automatically in your product backlog.

Iteration planning and continuous product discovery

Making product discovery and iteration planning a regular activity creates an agile, flexible product development process where the product team is ready to deliver on time and often. It results in a product team, that is always open to customer demands, new requests, and market changes. So don’t hesitate to change your dev process using the right tools.

Handpicked related content

10 benefits of synchronizing the story map to Azure DevOps or TFS
Product Discovery in Azure DevOps

Read more about iteration planning

How to run a successful iteration planning session

How useful was this post?

Click on a star to rate it!

Average rating 2 / 5. Vote count: 1

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?