With agile, planning and estimates come from teams that are also responsible for their eventual implementation. Even though agile Development Teams usually do not recognize official roles such as user experience designer, developer, tester, etc., team members still have their specializations, of course. At least in this article, developers, programmers, or coders will also be recognized and referred to as such.
STAY TUNED
Learn more about DevOpsCon
From vision to estimate
As mentioned at the beginning, agile development approaches such as Scrum insist that planning the scope and timeframe of the upcoming product development must be meaningful. However, during this process, you may ask, “Why plan at all? We’re agile now.”
Agility does not only mean planning in iterations with a maximum limit of four weeks. One of the major challenges for product management working with the team, including developers, is finding an answer to the question “What content can we make available by when? This does not fulfill an end in itself, but serves the company both in decision-making and in planning issues along with product development. Measures such as marketing, advertising, training, and establishing infrastructure that flanks development and releases need associated planning. Even in agile, it is important to estimate costs, calculate profits, and minimize risks by bringing the scope in line with time requirements and available resources. Unlike other process models, such as the waterfall model, the focus is on planning and not the plan itself. Many companies have struggled and continue to struggle with trying to come up with a concept for completing software projects within even a modicum of precision. Agile planning focuses more on the planning process rather than the outcome at the end of the process.
In other words, it teaches us to not view the plan as a document set in stone, where changes are introduced via change requests and changelogs. With the Agile Manifesto (box: “The Agile Manifesto”) and the principle “Responding to change over following a plan”, changing plans is even encouraged. This does not mean that you have to tinker with the timing of releases, but instead, you learn something new or are able to foresee a mistake and avoid it. This is reflected in the changed concept through planning. This could be, for example, changes in the demands of the market, new user behavior, or simply new legal requirements. At the moment, it won’t help to stick to the 19 percent tax in the plan if – influenced by the COVID-19 pandemic – the 16 percent tax is a done deal. During agile planning, decision-making occurs repeatedly (using empirical inspection and adjustment mechanisms) and is distributed throughout the project, taking all available information into account. In this process, changes to the plan are encouraged. The Development Team and individual programmers are regularly involved with a high level of impact.
The Agile Manifesto
The Agile Manifesto formulates values and principles for agile teams. The “Manifesto for Agile Software Development” by Kent Beck, Ken Schwaber, Jeff Sutherland, and fourteen other authors [1] was published in 2001. It defines four core statements:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Planning Onion
Planning is an essential and recurring part of agile product development, which is why agile teams go through this process at varying levels of granularity. This approach can be reflected in the agile planning onion, shown in Figure 1.
Fig. 1: The agile planning onion
Vision
The outermost layer on the planning onion is the vision. The vision serves as a mission statement that defines where the organization wants the product’s future to be. What stakeholders and customer requirements should be met? How does the product differentiate itself from current offerings from competitors? By setting this direction at a high level at the outset, it is clear to the market, customers, organization, and team what added value the product should have and what differentiation it has from products aiming to address similar challenges.
Roadmap
The next layer in the planning onion is the roadmap. It outlines a general plan for how the goals defined in the product vision can be achieved in the long term. During the process, the contents of the roadmap are often summarized in features and associated releases, establishing a rough timeline. The measures mentioned at the beginning can be scheduled along with the releases.
The granularity of content on the agile roadmap varies from team to team. Associated requirements are described at a still-low level of detail and should not be broken down into individual, small-scale requirements (stories) or tasks. Additionally, the roadmap should visually depict dependencies between features so that the team can determine the most effective approach for addressing those features. The roadmap also touches on the development approach that the team will use to implement requirements. Again, the focus is on getting the Development Team involved in planning during an early stage.
Release
One layer deeper in the planning onion, the goal is to flesh out the specific features that make up each release defined in the roadmap. We slowly leave the high level, while stories and tasks that were too specific for the roadmap level are now fleshed out in the release planning layer. If several teams are involved in development, then teams should be assigned different stories and tasks. With a well-defined release plan, the company is equipped to set a realistic timeline for the delivery of each release. A well-thought-out concept helps map realistic expectations for progress and product implementation while remaining transparent for the entire company. When developing the release plan, the requester, stakeholders, and the Development Team should already be working closely together to ensure a realistic strategy.
Iteration
Planning an iteration within a release typically spans one to four weeks and includes the stories and tasks that define the next product increment’s content. It is important that the agile teams have broken down the requirements to such an extent and formulated them in detail so they can be implemented independently of one another in the iteration’s time frame. This is probably the biggest difference to other development procedures for developers to recognize. Requirements are not simply imposed, but are co-designed by the team and, if necessary, even contributed by the team itself.
Daily
The innermost layer is the team’s daily planning. Typically, team members update each other on how they are progressing, what needs to be implemented by the next daily round, and what challenges need to be addressed along the way. This meeting is only for the Development Team and is not intended to give a status report to superiors.
At this point, we should mention again that agile planning is not solely about making a precise prediction about the delivered scopes at specific points in time. The focus of agile planning is on making timely adjustments to content or timelines in the surrounding layers of the planning onion, with transparency and learning effects when needed. This ensures that the correct requirements are worked on and appropriated added value is generated for stakeholders and customers.
Estimates
When planning releases, you must ask questions about how much effort development will take. Answering the question “Which scopes will be delivered at which times?” is the most challenging part of the planning process. The planning onion clarifies information, making elaboration higher the more detailed the requirements become.
Let’s start with the explanation of one potential approach to a statement about an estimate of how much effort is necessary. There is no agile template for how to estimate “correctly”. On the contrary, it is one of the most controversial topics discussed in agile.
You can also start in an agile environment by estimating person-days and expressing units of time in absolute terms. This is especially useful for teams that come from established development approaches such as the waterfall model, where both developers and their company are used to estimating effort in person-days. By far, most teams involved in product development with an agile approach use relative size specifications for estimates. The primary goal is to gain a common understanding of the size of requirements and factors involved in the estimate. We can assume that people find it easier to put things in relation to each other than to estimate absolute values. For many of us, it’s very difficult to state how tall a house is, for example. It’s much easier to understand that a house is taller than a garden shed and shorter than a church steeple.
With this in mind, teams use a wide variety of units to estimate requirements in relative terms, such as T-shirt sizes (XS, S, M, L, XL, XXL) or Fibonacci sequence numbers (0, 1, 2, 3 5, 8, 13, etc.). A requirement that was rated an XL T-shirt size on one team may have been rated an L or even XXL on another team. Different teams who may even be working on the same product may prefer using the Fibonacci sequence. Estimates in relative terms do not necessarily have to be comparable between teams. The most important thing is that the estimate ratios fit within the teams, and teams agree upon what factors go into an estimate. Here’s a few examples of what these factors might be:
- Complexity: How complex is the implementation?
- Effort: How much time does it take to implement the requirement?
- Insular knowledge/experience: Who on the team is doing it?
- Dependencies: What interdependencies are there outside of your own team? (for example, to systems such as data delivery systems, CRMs, or even other Scrum teams).
- Uncertainties and risk
Here, complexity does not necessarily mean “complicated”. The latter always refers to a task, an activity, or a part of a problem. “Complex”, on the other hand, describes a system of interlinked tasks and problems, whose individual parts can also be complicated. Effort should be averaged over the capabilities of the team and included in the estimate, taking island knowledge into consideration. A common procedure is to repeatedly check the relationship between the estimated requirements, especially for the first estimates. It’s useful to define reference requirements for various sizes from S to XXL or from 0 to 13. In this process, tasks that have already been completed are re-evaluated with regard to influencing factors and the initial estimate before implementation using one of the relative size specifications. These reference requirements can be compared to the new requirements when estimating again. The more experienced a team becomes in their estimations, the more meaningful and accurate planning from inside the onion will be. The clearer and more detailed requirements from the roadmap to iteration are, the more precise estimates become. Over time, as teams gain experience, they will have more and more information about which content can be implemented in which time frame. Estimates for requirements that have already been implemented can also be used to derive forecasts for similar requirements in the future. Of course, the granularity of the descriptions for the requirements must still be taken into account. Estimates for the iteration’s content must already have a high level of detail and is meaningful for the team, so that they can implement it with as little friction as possible. In this dimension, the stakeholders’ requirements differ from high-level requirements in the roadmap. When estimating the contents of the roadmap, teams can include the influencing factors “uncertainties” and “risk”.
STAY TUNED
Learn more about DevOpsCon
From iteration to roadmap
Teams learn to estimate how many requirements of what size they can implement per iteration. If a team implements requirements in previous iterations with an average of n, then this value, or velocity, can also be used to start planning the surrounding layers of the onion.
Together with the estimates for requirements of the contents of releases, the velocity can be used to set up a plan for the next iterations and releases.
All in all, planning should not be neglected, nor does it take care of itself, even with agile development procedures. Nevertheless, willingness to make adjustments from experience can help eliminate the risk of developing the wrong product in impossible time constraints.
The most serious difference for developers is that they are involved in the process of planning and estimating from the high flight level to the implementation of a requirement in the iteration.
