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 creating goals or missions to subsequent sequences of the dev work. After setting up the goal, the planning process has to find related user stories, 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.
Pre-planning the iterations
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 the feedbacks and experiences serves 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 act as be a pool for ideas. I’m sure you don’t routinely organize meetings after each new added backlog item, but this could be a perfect the 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 an 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 from 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 a 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 users 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.
Step 3 – Establish Capacity
Adjusting the iteration to the dev team’s capacity and setting up deadlines could be vital in a product development. Keep in mind, 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 with the deadlines and the capacity. Calculating the team’s capacity often fails when you don’t check teammate’s availability e.g. holidays, trainings, 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
Handling inner priorities could be crucial when the iteration contains risky elements such as blockers or integration features (should wait for outer parters 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 by a single click. The structure remains untouched.
Step 5 – 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 to evaluate and estimate the user story more accurately. If the estimated effort is 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 to 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.
Try this at home! Sing in your StoriesOnBoard Workspace
Not yet registered? Try it for FREE
Handpicked related content:
Read more about iteration planning
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?