What is a Technical Story, what is the difference to a User Story and how is it managed?
The elimination of technical debts
A user story is a short description of the functionality of a system from a user’s point of view. It describes who wants what from a system with what intention and focuses on the user. But what happens if a developer identifies a problem or an optimisation possibility in an already realised solution in the course of a sprint? Here, the use of so-called technical stories is a good idea. They can be used to
- document technical debts,
- technical refinement of user stories,
- describe non-functional requirements (e.g. with criteria such as performance and availability, scaling or security).
Do technical stories belong in the backlog?
On the one hand, technical stories do not describe a user’s direct benefit and that is the main difference to user stories. The user’s benefit is important for sprint planning and for prioritising user stories. Ergo: The technical story does not belong in the backlog. On the other hand, backlogs often manage not only user stories, but also epics, features, use case slices, spike stories, etc. All backlog items – Scrum speaks of backlog items and not user stories – are prioritised and addressed in sprints. Ergo: The technical story – which is sometimes also called a technical user story – belongs in the backlog. Since technical debts typically increase in the course of development, it is common in many organisations to plan some time for the elimination of these debts in every sprint. This would also be an argument for the administration in the backlog.
Either way: In contrast to user stories, technical stories take a system perspective. In addition to documentation, visualisation in the form of user story maps is also recommended.