It has been over 20 years since the Agile Manifesto was published. A lot has changed in software development since then. The previously common waterfall models have been replaced by development strategies that are far more suitable for software. Management tools such as Kanban or Scrum are now used in many companies. They provide the framework for agile work. This change has given rise to new job profiles: the Scrum Masterthe Product Ownerthe Agile Coach and others.
Agile development is not only alive within the development department. It runs throughout the company. In this respect, most developers seem to be familiar with the term agile and apply it when working with Scrum or Kanban. But that shouldn't be enough. In the following article, I would like to go a little deeper and give a few suggestions on how developers can work in a truly agile way these days. An important aspect of day-to-day work is the vertical decomposition of requirements.
Learning to read requirements
Developers work with requirements. They are happy to receive detailed requirements. They ask, hopefully, if there are gaps in the requirements. They translate the requirements into code and deliver a result. They know that this result is not always what the product owner wants. This is why it is so important to be able to generate feedback frequently and regularly. Scrum has established itself as a management tool to enable frequent and regular feedback. It uses sprints for this purpose, which are intended to deliver a specific set of requirements over a period of two to three weeks. At the end of a sprint, the product owner receives a result on which they must provide feedback. This sets the framework. But what does it look like within this framework? The requirements are usually formulated as user stories or epics. The developers are supposed to implement a solution from these user stories.
User story not the same as use case
Many programmers read a user story and immediately pull out the keyboard to add new methods to the code base. Far too early! A user story is an excellent way for users to formulate their wishes for the software. It is unsuitable for technical implementation. The technical translation of user stories are use cases. A user story can contain one or more use cases. A use case represents an interaction of the user with the system. The first task of developers is to convert a user story into use cases. An example:
The initial product is a graphics program for creating vector graphics. New requirements are to be added. The associated user story is:
As a graphic designer, I would like to be able to save a preview of my graphic with the "Preview" watermark as a PDF file via an "Export as PDF" button.
I immediately have a picture in my mind's eye. A graphical user interface appears in my imagination. The button is displayed, I press it and next a file browser opens in which I can save a PDF file with a desired name. A very familiar, superficial view from the perspective of a user. I don't really get an idea of what the associated code has to do in terms of transformation work in order to fulfill this requirement. Before I jump straight in and add a new button to the GUI, I should switch to the developer's perspective. A closer look reveals three aspects of the application that are affected by this requirement.
The block in this graphic represents requirements from the user story. It is divided into the three aspects of our application affected by the requirements. The UI aspect represents the graphical user interface. The Domain aspect comprises the logic that our application should fulfill. And the Resource aspect represents the access to external services, in this case the file system. In the next step, the requirements are assigned to the aspects.
Of course, the button itself remains one of these requirements. The user uses it to start the interaction that is to generate the PDF. In addition, I read three features that are part of this interaction:
- The vector graphic is to be converted into a PDF.
- A watermark is to be added.
- The PDF should be saved as a file.
Now I have the translation of the user story into a use case. An interaction with three features. In addition, an assignment of the features to the existing aspects.
Conclusion
The user story is a horizontal description of the requirements. It conveys the user's perspective and wishes for the system. The UI aspect is the most important. The user's interaction with the application is in the foreground, technical details are unknown. In the first step of a vertical view, we relate the user story to the aspects of the application. The aspects are a template to which the information of the user story is linked. This results in the use cases, or interactions, and the associated features. They represent the technical details in all parts of the system.
English 
German