Technical Stories
A back log consists of user stories. However, we often find items in there that developers need to do on their way to completing the user stories. And if they’re not on the back log, you can’t work on them. That leads to “user stories” like:
“As a resident I want to communicate with a consultant through the cloud, so that I know that my exchange is handled in a secure way”. Obviously, the wish to communicate with a consultant is valid. However, this story includes the means (the cloud), which most users don’t care or don’t think about. And, arguably, the same is true for security of an exchange.
Should we delete that part of the story? Of course not. If the designated solution is to work with a cloud, then that should be part of the back log. But be clear about it and don’t hide it in a user story.
In a lot of texts about the subject, this type of user story is often called a “technical user story”. If you think about it, that means the word “user” has lost its meaning in this construction. Bob Galen, who wrote books like “Agile Reflections” and “Scrum Product Ownership”, defines a technical (user) story as “…focused on non-functional support of a system”.