How do you handle non-functional requirements and technical debt in user stories?

Numerosos requisitos no funcionales son aplicables a todo el producto (software). En estos casos, es preferible discutirlos y documentarlos de forma independiente a las historias de usuario. Otros requisitos no funcionales se aplican a historias de usuario específicas. En estos casos, es más adecuado considerarlos como criterios de aceptación para cada historia. En todo caso, no debemos olvidar que lo más crucial de las historias de usuario es la conversación que generan para asegurar que todos los involucrados estén en sintonía, es decir, comprendan las necesidades del usuario y compartan una comprensión común.

Auch nicht funktionale Anforderungen müssen in User Stories so genau wie m?glich definiert werden. Nehmen wir das Beispiel Benutzerfreundlichkeit. Es ist nicht hilfreich, wenn in der User Story steht, dass das Feature benutzerfreundlich sein soll. Stattdessen muss genau definiert werden, woran diese Benutzerfreundlichkeit festgemacht wird. Hierzu ist es hilfreich, in cross-funktionalen Teams inkl. UI/UX und Design zu arbeiten, da somit direkt im Team passende Anforderungen ausgearbeitet werden k?nnen. Diese werden dann in den Akzeptanzkriterien festgehalten. Nur wenn diese - neben den funktionalen Anforderungen - erfüllt sind, gilt die User Story als fertig.

Non-functional requirements in software engineering describe the qualities and characteristics of the software system beyond its functional requirements, ensuring that the system meets user and stakeholder expectations and performs efficiently under various conditions and loads.

My journey in Agile methodologies has shown me firsthand the immense value of embedding Non-Functional Requirements (NFRs) within the Definition of Done (DoD). It's a game-changer, elevating the quality and completeness of our delivered increments. I've witnessed how NFRs in the DoD solidify the foundation for exceptional outcomes.

An example I have used for one of the project is to add a 'technical debt' label to the respective stories and allocate X amount of story points per iteration jus for technical debt. This way you can easily filter your stories with the label and stories that sum up to X story points to every iteration.

La deuda técnica debe ser abordada sin falta. No hay alternativa. Sin embargo, lo que sí es factible es liquidarla de forma progresiva mientras se continúa ofreciendo valor en cada iteración. Es fundamental promover una cultura que desaliente la acumulación de más deuda técnica en las nuevas historias de usuario. Si la deuda técnica resulta excesiva, emplea uno o más sprints para su resolución, incluso involucrando personas o equipos adicionales. Además, es importante evaluar y priorizar la deuda técnica, así como elaborar un plan para su resolución continua sprint tras sprint. Esto restará capacidad al equipo para mantener el ritmo habitual de entrega de valor en términos de calidad y cantidad. Sin embargo, es una medida necesaria.

Um technische Schulden weitestgehend zu vermeiden, gilt auch in der Softwareentwicklung der Leitsatz "Qualit?t vor Quantit?t". Entscheidend ist hier, Transparenz gegenüber den Stakeholdern zu schaffen. Denn diese müssen verstehen, welche Risiken eingegangen werden, wenn man die Qualit?t vernachl?ssigt. Sollte es aus Zeitgründen und in Abstimmung mit den Stakeholdern unvermeidbar sein, technische Schulden aufzubauen, müssen diese unbedingt verschriftlicht werden. Ein Eintrag im Backlog mit entsprechender Priorisierung ist ein guter Anfang. Das Team sollte unbedingt regelm??ig Zeit bekommen, technische Schulden z.B. durch Refaktorings abzubauen.

In one of my previous projects (a fintech app with a fair amount of legacy code), we used to have a label for such tasks, and the special robot in Jira, which distribute tech debt tasks randomly. Each team fixed several of them every sprint