Developers have a clearly defined task: they translate the requirements of a product owner into code. Sounds simple enough. In practice, however, many teams struggle with this. Above all, I repeatedly observe in our training sessions that there is a complete lack of clarity about which steps need to be taken on the path from requirements to code. I realize that comparing software development with other industries is not easy. However, we differ from other industries in one respect: there are usually clearly defined processes. Building a house involves a number of steps that every planner goes through. The details are consistently planned according to an architect's design. No craftsman goes to the building site without first planning what is to be installed and where. And yes, some things do not run smoothly when building a house. Nevertheless, in the field of software development, it makes little sense to keep thinking about how to get from the requirements to the code this time. I would therefore like to present the individual steps below.
From the requirements to the code
Requirements
- Decompose requirements vertically
- Design in width
- Select a request
- Refining the design in depth
- Work organization
- Implementation incl. tests
- Integration incl. tests
- Code Review
Code
1. decompose requirements vertically
An agile approach means obtaining feedback regularly and at short notice. To do this, it is necessary to break down the requirements in such a way that a sufficiently small part is created. Implementing too much at once means getting feedback later. On the other hand, feedback is only possible if the requirements are broken down vertically. See the illustration.
2. design in width
A whole series of requirements have been identified in the breakdown from step 1. Before we focus on one of them and implement it, it is worth taking a broader look. Instead of looking in detail at how the individual requirements can be implemented, we look at all the requirements together, but only superficially. This step serves to identify dependencies between the requirements and to make decisions that have a broader scope. For example, the status of the application is discussed here.
3. select a request
In this step, the product owner decides on a requirement that is to be implemented next. Essentially, the idea behind this is that the team works together on a single requirement in order to implement it at maximum speed. This increases speed, brings focus and reduces the risk of systematic errors in several tasks that have already been started.
4. refinement of the design in depth
A solution is then designed for the selected requirement. Software development means developing solutions to problems and only then implementing them. In this step, the solution is designed in such detail that at the end it is clear which classes/files and methods need to be implemented.
5. work organization
In order to be able to work together based on a division of labor, the next implementation must be prepared. In this step, the contracts are defined and it is decided who is responsible for which parts. This is also where the project structure is created and jointly required data types are created.
6. implementation incl. tests
Now that the preliminary planning work has been completed, the coding can begin. This naturally includes automated tests. These are state of the art and should not be omitted under any circumstances. Ideally, test-first work is carried out. In this phase, unit tests are typically written for small units of the overall functionality.
7. integration incl. tests
As the individual components were implemented in the previous step based on a division of labor, they must now be integrated. The integration code must therefore be implemented and automated tests must also be written here. This phase then involves integration tests.
8. code review
Before the result is handed over to the product owner for acceptance, the entire team carries out a code review. This involves checking, for example, whether all relevant principles have been adhered to, whether the test coverage is sufficiently high, whether the requirements have been implemented, whether all agreed conventions have been adhered to, etc.
It is then the task of the product owner to evaluate the implementation of their requirements and provide feedback to the team. If necessary, the team must make corrections. The entire process is then run through again, starting more frequently at step 3, until all requirements from the decomposition (step 1) have been implemented.
This process is not in competition with Scrum. On the contrary. It fills out the framework that Scrum provides with the sprints. Within each sprint, the process described above is run through again and again. If the team has to provide estimates, steps 1 and 2 can serve as a basis, and step 4 if necessary.
If you would like to find out more about the procedure presented, you can read about it in my book "With flow design to clean code". The topic is also covered in our training Clean Code Developer Advanced discussed and practiced.
You are welcome to write your questions in the comments below.
English 
German