Agile projects can be planned

Agile software development has now become established almost everywhere. It allows customer needs to be met in the best possible way. In my blog post, I would like to show you that, contrary to the myth of a lack of planning, agile projects can indeed be planned and go beyond improved value creation.

The challenge – project plan set by management

In many companies, not only strategic but also less important projects are initiated by management with clearly defined goals and deadlines. These strict specifications pose enormous challenges for project management – especially when previous schedules have often not been adhered to. I once joined a Scrum team as a product owner where the plan for the next two years had already been set by the board. An essential aspect is therefore the development and clear communication of a realistic schedule that meets the requirements of management as well as the operational circumstances.

The myth that agility has no plan

A widespread myth is that agility is haphazard. It is often assumed that in an agile environment, planning is only done from sprint to sprint and that there is therefore no long-term plan. However, in my opinion, this way of thinking is far too simplistic. In reality, a well-managed agile project starts with a preparatory phase in which rough concepts are created and a roadmap is developed at the epic level. This is followed by ongoing preliminary planning for the next two to three sprints, which is adapted to the results and insights from the previous sprint.

Agility does not mean that you can change your mind and your plan at any time, but that you can react flexibly to changes without losing sight of the overall product vision, the product goal and the sprint goals.

Based on the capacity of the team and the estimation of the user stories, at least the next sprints can be planned.

Agile medium-term planning

Another misconception is that story points cannot be used for planning. Although person days often give the impression of detailed planning, experience has shown that teams are often overwhelmed by this and that the estimates are ultimately more unrealistic than with story points. With story points, the so-called velocity can be quickly determined with the team after the first sprints, taking into account the uncertainties (cone of uncertainty).

Short-term planning is covered by sprint planning, while medium-term planning involves estimating and planning the next two to four sprints. The determined velocity and a stock of estimated user stories, which are continuously adjusted and prioritised, help with this.

Agile Long-Term Planning (Roadmap)

The Magic Estimation method is ideal for long-term planning. I have always had very good experiences with it. My teams were able to estimate quickly and effectively with it. In addition, this method makes it possible to create an estimate for the entire project duration. The result is a prioritised, sufficiently accurate roadmap that is regularly reviewed and adjusted as development progresses based on new insights. Using this method, our estimates were always more accurate in the end, enabling us to provide stakeholders with a reliable roadmap.

The Magic Estimation Method Process

1. Preparation

• Prepare a list of user stories to be estimated on cards or in a suitable tool (such as Miro or Jira).
• Give the developers a brief overview of each user story. This gives everyone the opportunity to ask fundamental questions that could have a significant impact on the estimate.

2. First round of estimates

• Each developer receives a copy of the list and estimates the size of each task independently. However, I have usually divided the list evenly among the team, which in my experience has led to equally good results in less time.

• The time for estimating a task is limited (time boxing). Depending on the size and level of detail of the task, I have worked with five to 15 minutes here.
• The estimates are entered accordingly.

3. Adjustments

• The participants come together and compare their estimates.
• One person at a time can change exactly one estimate, giving a reason for doing so. I then always enter the previous estimate on the card to document the uncertainty in the estimate and take it into account in the roadmap. It is not necessary to discuss the change at this point, as all other participants also have the opportunity to make adjustments and present arguments for them.

4. Further estimation rounds

• Repeat the estimation process to see if the discussion has changed the estimates.
• The goal is to arrive at an estimate that is sufficiently accurate for a roadmap. This means that there is no need to switch back and forth between two different estimates until everyone agrees on two estimates of similar size, for example three and five story points. This makes no significant difference to the roadmap.

5. Finalisation

• Create a final list with the estimated sizes for each task.
• This list serves as the basis for creating a roadmap.

The Magic Estimation method enables quick and effective estimation of tasks by taking collective knowledge and different perspectives into account. The team focuses on the essential factors for the estimation. The key thing is that it has always proven itself in practice, at least in my projects. In the project mentioned above, I was able to convince all stakeholders, including the board, of our roadmap. In all other projects, I was always able to stick to the schedule and impress the stakeholders with this reliable planning.

Conclusion

Agility can definitely be planned. By combining short-term sprint planning, medium-term planning for the next sprints and a longer-term roadmap, an agile project can be managed efficiently and purposefully. Flexibility and adaptability are not at odds with predictability, but rather enable realistic and dynamic project planning.

I hope this blog post helps you to implement your projects even more successfully in the future. Good luck trying it out!