Is it true that agile teams don't plan? If we don't coordinate the work of several people on one topic, we end up duplicating work, working on the wrong topics or the work simply gets left undone. Planning is therefore essential to coordinate the work of several people in a team. It doesn't matter whether the Team classically developed or agile. The difference between the two approaches lies in the time. Agile teams plan evolutionarily or incrementally, whereas in the classic approach, planning takes place increasingly at the start of a project. Incremental planning reduces the costs of starting a project and allows us to react quickly to changes (e.g. in requirements, priorities) as the project progresses.
In principle, this procedure applies to all agile methods. Since the agile framework Scrum is currently enjoying such great popularity, we would like to take a look at exactly how planning takes place in Scrum using the example of a Scrum team.
Scrum & short-term planning
The shortest time unit in which a Scrum team plans is the Daily Scrum. The development team and the Scrum Master meet daily for the Daily Scrum (Daily). The Daily is used by the Development Team to coordinate their daily work and monitor their progress in the Sprint. When coordinating the daily work, the development team uses three questions to help focus the Daily on the most important points. Many development teams use burndown or burnup charts to monitor their progress in the sprint. This allows the team to tell the product owner or stakeholders whether they can implement the requirements planned for the sprint on time. And this brings us to the next planning unit of Scrum teams: sprint planning.
Scrum & medium-term planning
In each sprint, the Scrum team plans which requirements it will implement within a sprint. A sprint is a fixed time interval of 1, 2, 3 or 4 weeks. It is the Product Owner's task for sprint planning to have prepared sufficient requirements and to prioritize them among themselves. The higher the priority of a requirement, the greater the chance that it will be pulled by the team in the next sprint. This regular medium-term planning therefore leads to the Product Owner prioritizing requirements:
- continuously deals with its requirements,
- refined so that they can be completed within a sprint
- and prioritize them in relation to each other.
In order to fulfill this job, he must therefore meet regularly with his stakeholders and the team during the sprint and work on the requirements. This takes place in the backlog refinement meeting.
Scrum & long-term planning
For many customers and organizations, however, it is not enough to plan just a few weeks ahead, i.e. one sprint. At the latest when this is the case, a Scrum team should think beyond the next sprint.
Experienced product owners have prepared up to 5 sprints on average. Prepared in this case means:
- the requirements are discussed with the team in the refinement,
- Acceptance criteria are defined,
- the team appreciated the request,
- a prioritization is defined and
- the requirement pays into the product increment of the respective sprint.
In addition, the feedback providers who are particularly important for this requirement are informed by the product owner in which sprint the requirement will be addressed. This is because it is extremely important for Scrum teams to be able to reach the relevant feedback providers if they have any questions in this sprint, and they must also be present at the sprint review.
Every product owner knows that the planned content for a sprint can still change, as we learn new things during development and others don't work out as we assumed. But if more than one sprint is prepared, this brings calm to the Scrum team. It facilitates collaboration with interfaces and provides time to deal with requirements that are still unclear. Conversely, however, this also means that a product owner must have enough time to really take care of their product backlog and the Scrum team needs direct access to the feedback providers. This is the only way Scrum teams can achieve short feedback loops, get real decisions and continue working accordingly.
Conclusion
Scrum therefore involves regular planning over various time horizons. In contrast to traditional approaches with long planning phases, Scrum is implemented promptly. For long-term planning, however, it is crucial that product owners have enough time to work on the requirements and close cooperation with feedback providers is necessary.
So we ask ourselves, where does this rumor actually come from? Are organizations not looking at the real problems and just pushing the "agile teams don't plan" argument? What is your opinion on this?
Comments
Write a comment