EN 
DE How to plan correctly in agile projects
Author: Markus Unterauer, Software Quality Lab GmbH
Contribution – Embedded Software Engineering Congress 2015
Agile is often interpreted and practiced as "without planning" or "just going for it." In reality, the opposite is true. In agile projects, highly structured and careful planning takes place at multiple levels, from the product itself through releases and iterations to the tasks to be performed within each iteration. The foundations of this approach are rolling planning, which becomes increasingly detailed as implementation approaches, and the continuous adaptation of plans based on feedback from the iterations.
At the start of a software project or product development, very little is known. Stakeholders and the team have a rough idea of what the software needs to do and what it should look like. Only as the project progresses do they all learn together what is needed in detail and what the best solutions are. Even in systems development, where the requirements for the system, hardware, mechanics, and electronics are already very precisely defined, the requirements and the exact appearance and behavior of the software are often only vaguely specified at the beginning.
Agile methods take this fact into account and accept that you don't know everything at the beginning and therefore can't plan everything in detail. One of the most important foundations of agile methods is therefore rapid learning cycles (see Fig. 1)., PDFPlanning, implementation, testing, and adjustments based on customer and user feedback are carried out in short iterations. This principle is consistently applied in agile planning as well.
To avoid wasting effort on detailed planning of functions that are then implemented differently or not at all, only those aspects that are due in the next iterations are planned in detail. Functions further in the future are only roughly outlined (see Fig. 2)., PDFThe plan is adjusted on a rolling basis at the beginning of each iteration, and the next upcoming software components are specified in more detail.
The 5 stages of agile planning
Agile projects are planned in 5 stages (see Fig. 3, PDF) [1][2]:
- Product Vision: The vision statement describes the shared vision for the new product. It outlines the project's broad objectives and serves as a guide for all involved, showing them where the journey is headed. It can certainly be written in a motivating style, explaining why the product is necessary, how it differs from existing products, what benefits it offers the user, and how it makes the world a better place.
- Product Roadmap: A roadmap outlines when (in which releases) the essential core features of the product will be completed. It serves as an initial guide for the team and stakeholders on how the implementation project will proceed. The product roadmap includes only very broad topics and features and focuses on the customer perspective.
- Release Planning: Release planning involves planning the next release in more detail. In agile projects, a release typically lasts between one and six months. In a joint workshop with all project teams, the goals and features to be implemented are defined, and an initial, high-level iteration plan is developed. This serves as the basis for ongoing monitoring during implementation.
- Iteration Planning: In agile projects, an iteration lasts between one and four weeks. Iteration planning consists of two parts: The first part defines which requirements the team can complete within the iteration. "Completed" in this context means implemented, documented, tested, and accepted. The second part plans which activities (tasks) need to be performed to complete the planned requirements. The result is a populated iteration backlog and a task board listing the tasks to be completed.
- Daily Stand-Up: The team meets daily for a short planning and coordination meeting. Together they go through who will complete which tasks and what obstacles there are.
Artifacts for planning
Different artifacts are planned depending on the planning level (see Fig. 3, PDF) [1]:
At the highest level, the product vision, there is only a vision statement. This is usually a fairly short document, in which the big picture is outlined on a maximum of one A4 page.
The product roadmap typically only outlines the key features of the new product at the heading level, in a rough chronological order. These features are described primarily from a market or customer perspective. In agile development, epics are often defined at this stage. These are also larger functional blocks or topics, but they can be implemented within a single release.
In release planning, features or epics are broken down into smaller parts called stories. These describe useful functions or functional components for the user, which can be completed within one iteration.
Within an iteration, the activities necessary to implement the stories are planned. Task items are created for this purpose. These work packages should not exceed one person-day in terms of effort.
Effort estimation
Even in agile projects, planning is based on estimates. Depending on the planning level, different estimation methods are used (see Fig. 4)., PDFThe more precisely the plan elements are specified, the more accurate and detailed the planning will be.
For roadmap planning, many projects estimate the individual functions (features) and broad topics (epics) using T-shirt sizes (XS, S, M, L, XL, XXL). Each size corresponds to a range of effort, e.g.:
- XS………. < 5 PT
- S…………. 5 – 10 PT
- M………… 10 – 50 PT
- L…………. 50 – 100 PT
- XL………. 100 – 200 PT
- XXL …… > 200 PT
The estimate is carried out by the implementation teams after a brief presentation of the function or topic by the product manager.
Stories for release and iteration planning are often estimated in story points. This is a fictional unit that describes the complexity of a story compared to other stories. A story with twice as many story points is correspondingly twice as complex. Capacity planning can then be performed using velocity, which is the average number of story points a team can complete per iteration.
Within an iteration, the work packages (tasks) for implementing the stories are estimated in person-days or person-hours.
Ongoing monitoring and adjustment
Based on the current release and iteration plan, a plan/actual comparison is performed at the end of each iteration. Depending on the deviations, the current plan is then adjusted. Many agile projects use burnup charts for this purpose, which allow for a forecast of the further project progress in various scenarios (see Figure 5)., PDF).
Lessons Learned for Agile Planning
The following tips will help you stay on track in software projects. They apply to agile projects as well as to traditional, plan-driven ones:
- When something goes into a project, something else has to go out.
With constant resources, this insight is actually quite obvious. If the client wants a new, additional function, and at the same time neither the number of employees is increased nor the release date postponed, the only options are to eliminate a previously planned function of the same size or to scale back existing functions. This must be taken into account at all planning stages.
- Never trade estimates downwards.
The common belief that software developers generally overestimate effort is not borne out in practice. They typically underestimate the required effort. The subsequent costs of underestimating effort are significantly higher than the disadvantages of overestimating. Therefore, effort estimates should generally never be questioned; instead, if they are too high, the focus should be on reducing the scope or exploring alternative technical approaches.
- Consider secondary employment when planning capacity.
Besides the actual programming work, agile teams have a whole range of other tasks to fulfill: supporting the product owner in specifying stories, meetings, bug fixing, etc. All of this must be taken into account in capacity planning. On average, agile teams have about 34% of their time available for the actual programming of new features (see Fig. 6)., PDF).
Summary
Agile planning is based on continuous learning and flexible adaptation to changes. The planning elements are refined step by step in five planning phases. The closer implementation approaches, the more precise the planning becomes. Ongoing comparisons between planned and actual progress prevent surprises due to deviations at the end of the project.
Literature and sources
[1] Ponomareff, „The 5 Levels of Planning,“, www.slideshare.com, 01.10.2015
[2] Bergsmann, „Requirements Engineering for Agile Software Development“, dpunkt.verlag, 2014
[3] Brokenbuild, „Release Burnup Plugin for JIRA“ , 01.10.2015
Agile & Scrum – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Agile & Scrum.
Training & coaching on the other topics in our portfolio can be found here. here.
Agile & Scrum – Expertise
Valuable expertise on the topic of Agile & Scrum is available here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
