As an agile Project Manager, you face a lot of pressure to assure your stakeholders that your project is on track. You are the one the client is calling saying, “are we going to finish this thing on time??” It is imperative to have documentation that can eliminate all doubt that you will. Enter the Iteration Plan.
What is an Iteration Plan?
The Iteration Plan serves multiple purposes and is a living document that you maintain throughout the project. It can show the high-level roadmap using general bullet points or epics, as well as the granularity of each sprint using individual PBIs (Product Backlog Items), features, or user stories.
You can format this document in multiple ways depending on your project and personal preference, but the skeleton should show the sprint plan and each workstream involved in the project. You can use your project’s wiki software (I usually use Confluence, shown in the example below), you can organize your PBIs into sprints in Azure DevOps or cards in Trello, or you can even use Excel. Any party contributing to the project – your development team, the client, other third-party vendors or partners – should be represented in this document. Dependencies and risks are everywhere!
Creating the Iteration Plan
Your project team should start creating the Iteration Plan during your initial kickoff or discovery sessions. These early discussions will involve estimations for big features and identifying dependencies for these features. The team will also determine the order at which certain tasks need to be done for features to be completed on time.
The Iteration Plan is essential for identifying and mitigating/eliminating risks early in the project. The riskiest areas of the project should be started as early as possible to attempt to accommodate the unexpected. For example: if you know an area of your project will require a technical proof-of-concept (POC), you will want to begin as early as possible in the project to tackle any issues that arise and keep the project on track. Risky or unknown features should be slated for Sprint 0 or Sprint 1 in the Iteration Plan since the results will inform the remainder of the project.
As the Project Manager, you should continuously update the Iteration Plan as the team completes features and learns more about the project’s requirements. As requirements are defined and features shift or get completed, the Iteration Plan will serve as a roadmap for the remainder of the project to give you a solid idea of how much work you have ahead of you and if you will finish as planned.
Here is an example scenario: your project has six development sprints, and you have estimated the search feature to take three sprints to complete. This means that the approved design and final requirements for search need to be delivered before the end of Sprint 3. This is where it is important to have all parties involved in the creation of this document – the design team will know how their deadline will impact the overall timeline and how missing it could have a large ripple effect. Dependencies for search could go even deeper: you could have a dependency on the client to even select a search technology prior to starting the design phase. It is important that the design team knows what out-of-the-box features come with the search tool when creating mockups.
Other example scenarios that an Iteration Plan can address:
- A portion of the site is dependent on a product information API being finalized. The API needs to be ready for consumption by Sprint 2 for all development to be completed on time. You determine that your team can deliver on time if the client provides test data by Sprint 2 and real data by Sprint 4.
- You’ve estimated content entry to take three sprints. To complete this work in time, the client must approve and deliver final content by the end of Sprint 2. Reviewers on the client team should be available and ready to review content starting in Sprint 4. Documenting these tasks clearly shows what is expected of each party at every step of the project.
The Iteration Plan is an essential document for an agile project. It maps out dependencies, addresses risks, and gives all project stakeholders confidence that there is a plan. I hope it helps you with your next project!