Requirements engineering in practice - agile, approachable and from the T3DD25 community
Our CEO Fabian Stein and my colleague Dex addressed the topic of requirements engineering in practice at T3DD25 and received a "Best Speaker Award" for this. You can read more about what happens when theory and practice meet here.
Wer nichts wagt, kann auch nichts gewinnen!
Marco Schiffmann
packt jede Gelegenheiten am Schopf und scheut sich nicht vor neuen Herausforderungen
There are those moments at conferences when you immediately sense that people are talking here who know what they're talking about - and who aren't too shy to laugh about their own construction sites. This is exactly how Fabian (Product Owner & CEO) and Dex (Architect & Developer) began their presentation at the TYPO3 Developer Days 2025 - T3DD25 for short.
"Welcome to our little self-help group for requirements management!", Fabian greeted the audience - and it was already clear that this was not going to be a dogmatic process lecture or a collection of patent solutions. Instead: real-life requirements engineering, many learnings from agile practice and an honest look behind the scenes of our Scrum teams.
Conflicts but also opportunities
Why requirements engineering so often offends
Fabian and Dex have been working together for over 14 years - and have been friends for 16 years. This long collaboration also shapes their view of agile requirements engineering. For them, it is not simply a step between concept and implementation. It is relationship management, communication - and sometimes also conflict resolution.
They made it clear right at the start why the topic is so important: requirements are often the biggest source of friction between project management and development. In the agile world, especially in Scrum, this friction can quickly become visible - and this is not only stressful, but also an opportunity for better communication.
One key image from the presentation stuck with me: the "real" project management triangle. Officially, people talk about time, budget and quality. In the reality of your development team, it is more likely to be time, money and nerves. Because good quality can often be achieved under pressure - but not indefinitely, without affecting mood and motivation.
From theory to agile practice
Then there's politics: requirements are rarely just technical. The customer wants a good product, the product owner wants satisfied customers and efficient processes, the dev team wants cool technical solutions, the agency thinks about profitability. All of this is in one ticket - and often you don't even realize that you're not talking about the same things. Only when all interests are openly on the table can a sensible compromise be reached.
Fabian and Dex explained how they went down this path themselves. In their "Bembel" project - the start of their Frankfurt location - they were convinced: "We know each other well, so communication will work. But it didn't. The result: misunderstandings, duplication of work, frustration.
Step by step, they built up a structure that works both in the Scrum process and in day-to-day business: a common ticket template in Jira, fixed RE meetings, the separation between refinement (in small, focused groups) and estimation (in the whole team). This not only led to better results, but also to a greater sense of responsibility among individuals. Particularly valuable: when an expert works with someone who is not yet familiar with the topic, the very questions that drive a project forward often arise.
Just Do It
Agile also means: pragmatism before dogma
Despite all the structure, they remained realistic: not every requirement has to go through the entire requirements engineering process. Sometimes it is more efficient to just get started. "If it takes me four hours to prepare a ticket that can be implemented in an hour, I've probably overdone it," said Dex dryly.
In the end, they summarized their attitude: Talk to each other early. Share responsibility instead of passing it on. Create clarity instead of making assumptions. Communicate directly - even across roles. And don't forget: Humor helps.
The aim of her presentation was not to sell the one perfect process. It was to show that agile requirements engineering is a lively interplay of people, processes and framework conditions. It will never be perfect - but with openness, structure and a dose of serenity, you can create great things together.
And this was obviously well received: Fabian and Dex won second place in the Best Speaker Award at T3DD25 with this talk - and we are delighted with this appreciation from the community.
Some funny reels
Thank you very much
Thanks at this point: We used some reels from our colleagues at tl;dv to illustrate our theses. Thanks to the uncomplicated exchange and direct support, we were able to lighten up our presentation and get some laughs from the audience. Many thanks at this point and feel free to check out her Instagram channel.(https://www.instagram.com/tldv.io/?hl=de)
Would you like to delve deeper into the topic of requirements engineering with us?
If you were unable to attend T3DD25 or missed the talk, but know the challenges in requirements engineering - let's talk. We are happy to share our experience from agile Scrum projects, help you optimize processes and support you in achieving better results for your team and your customers.
We are passionate about open source software. For us, this also includes communication between systems, including proprietary solutions. We see consulting as comprehensive support for your software projects. Depending on the project, this may includeAgile methods such as Scrum, sprints and short innovation cyclesAnalysis of your market environment and review of solutions in practiceIntelligent networking of different systems (web applications, smartphone/tablet apps, ERP, SAP, etc.)Automated testing and quality assuranceInfrastructure concepts for software projects with or without the involvement of our own data centerIt is particularly important to us to keep our work efficient. This means that we always look at the individual project and only do what really makes sense. Of course, we are always available and live agile working: We can adapt our approach at any time and always ensure transparency.
Old certainties are crumbling, new questions are emerging. Who actually decides on technology? How independent are we really? And what role does open source still play? We share our observations from a year that has reorganized many things.
Working at punkt.de - getting started and the first few months
I've been at punkt.de for four months now and in that time I've already taken part in the team days, the Just Do It Day, as a helping hand at a conference and experienced a project going live.
