Iteration planning or sprint planning is the next step after the product discovery phase. It is also a frequently repeated element of the software development process. The main purpose of iteration planning is to create goals or missions for subsequent sequences of development work.
Once the goal has been defined, the planning process involves identifying, evaluating, and estimating the relevant user stories.
Issue trackers like Jira, Trello, and Azure DevOps handle iterations well, but planning before launching the next sequence can be tricky if you only have a flat list of user stories.
This is why I recommend StoriesOnBoard, which supports effective iterative planning.
What is an iteration in agile software development?
Iterations are most commonly known as sprints in Agile Methodology. An iteration or sprint is a repetitive event over a time frame, in software development, the length of each iteration is usually scheduled to be two to three weeks. In software development, where a small amount of code is written and tested, then another small amount of code is added, and so on until the entire application is complete is referred to as iterative and incremental development.
Each iteration also provides rapid feedback to the team, so that the project scope and priorities can be adjusted based on user experience, ensuring that product development delivers consistently high business value and quality.
Expand your knowledge, follow us for more!
What is iteration planning?
The purpose of iteration planning is to decide how many and which user stories the development team will implement from the backlog. The team usually agrees on the user stories for the upcoming iteration and defines the iteration goals. During the iterative process, the team should consider the team’s progress rate, the complexity of each story, and possible interdependencies.
The results of the iteration planning should therefore include:
- a sprint backlog of selected prioritized user stories that the team will work on during the iteration,
- a brief description of the iteration goals,
- a clear commitment from the team to deliver.
Iteration planning with StoriesOnBoard
StoriesOnBoard is essentially a visual product discovery and planning tool that allows you to create an intuitive product backlog and project roadmap. The app can be synchronized in real-time with Jira, Trello, and Azure DevOps projects, among others (e.g Slack), so you don’t have to work twice.
When you do product discovery in StoriesOnBoard, iteration planning is nice and seamless.
If you’re not completely clear on the product discovery phase, read our previous article on the topic.
How to prepare iteration planning?
Iteration planning can be very efficient if the team has all the necessary input. First of all, the product owner (PO) usually defines the planned iteration goals, so that the discussions can be based on the pre-planned objectives.
Before starting to create the upcoming iteration or release and having an iteration planning meeting, it is worth having a retrospective meeting (it is best if the Scrum master facilitates this meeting), i.e. reviewing the previous iteration with the team. How was the development work? Did you discover any planning mistakes? Has the development team completed all the tasks? Were there any obstacles to working efficiently?
Sharing and discussing all feedback and experiences will help us plan better. In addition, during development, additional backlog items may be generated, which you should add to the product backlog and prioritize.
As I mentioned earlier, StoriesOnBoard is a great product and feature brainstorming and management platform. The iteration planning meeting is a perfect opportunity to discuss and prioritize ideas with the product and/or development team.
So don’t miss the opportunity to hold a brainstorming session with your team – it will help them understand the planning process and stay involved.
Expand your knowledge, follow us for more!
Iteration Planning in 5 easy steps
In a nutshell, these are the core steps of iteration planning. Keep in mind that, as with all agile work templates, you can add or omit steps depending on the specifics of your project.
Step 1 – Set iteration goals
The future iteration’s goal or a new feature may 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 most important problem you should solve? What is the next product increment that creates the most customer value? If you have done this work earlier in the product discovery process, you have an easy job.
If the product backlog items are only in priority order, you should collect the related stories into one release.
Retelling the narrative flow helps to check that the iteration contains all the necessary elements. Discovered a hole in the backlog? No problem! You have everything (the team and the product backlog) to find missing stories.
Remember that after setting up integration with Jira, Trello, or Azure DevOps, you can send the newly added elements with all their details to the project with a single click.
“Retelling the narrative flow helps to check that the iteration contains all the necessary elements.”
Step 2 – Estimate user stories
In this step, the PO or Product Manager should involve at least the lead developer from the dev team to estimate all the user stories. Developers don’t usually attend all product meetings meeting, so retelling the user stories help them to get into the groove. After estimating all the user stories, you all get an idea of the team’s velocity.
On StoriesOnBoard you can easily add estimation information to your backlog items. You can also use story points and custom estimation units. Moreover, the estimation will be synchronized to your issue tracker.
Illustrated with the example of Azure DevOps:
Step 3 – Establish capacity
Adapting iteration to the capacities of the development team and setting deadlines can be crucial in product development. Remember that you should deliver as often as you can. Meeting deadlines is also important.
In summary, it is necessary to check that the proposed iteration meets the deadlines and capacity of the development team.
Calculating the capacity of the team often fails if you do not check the availability of your team members, e.g. holidays, sick leave, training opportunities, etc. If the team capacity, task, and deadline match, you can proceed to the next step.
“Calculating the agile team’s capacity often fails when you don’t check teammate’s availability.”
If there is a problem with capacity, you will need to review the user stories again and replace some or postpone them. Another solution may be for the team to rethink some stories and find a simpler solution.
Step 4 – Planning steps – internal priority
Internal priority management can be key if the iteration contains risky elements such as blockers or integration functions (waiting for external partners, e.g. API).
In consultation with developers, the product owner should define the tasks for the opening, middle, and end game.
By arranging user stories within an iteration, you can express internal priority and make them more visual by adding labels and tags to the cards.
After this step, you can push the entire iteration with all its details to your issue tracker A with a single click. The structure remains intact.
Step 5 – From stories to tasks
Incorporating stories into tasks can be an optional step if you use both user stories and tasks. For high-level design, this level will not be required, so I recommend managing tasks in your issue tracker and assigning them according to the general practices of your development team.
Splitting user stories allows for a more accurate assessment and estimation of the user story. If the estimated effort changes after tasks are estimated, StoriesOnBoard automatically updates the estimation points in the product backlog.
Iteration planning and continuous product discovery
Regular iterative product discovery and iteration planning create an agile, flexible product development process in which the product team is confident of its ability to deliver on time and with frequency.
This way, the entire team will always be open to customer needs, new requests, and market changes. So do not hesitate to change the development process with the right tools.