In the previous article "Scrum - an introduction for developers", we briefly addressed the topics of product backlog and user stories. We explained that an assessment of requirements with regard to scope and complexity is also necessary for agile product development. This article will go into this in more detail. We will provide an overview of how to move from time estimates and a content framework for a rough roadmap, or release planning to a concrete estimate of requirements for planning the iteration. It will become clear that developers help to get the estimates underway, especially during the process of estimating as a basis for planning.

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.

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 ...