How should technical stories be handled in Scrum‪?‬ Agile Coaches' Corner

In this episode, Professional Scrum Trainer Eric Landes addresses the questions: "How technical stories should be used in Scrum?"
Overview I have been asked how technical stories should be used in Scrum.  Great questions, and of course Scrum has a framework, while not specifically talking to this issue.
When discussing technical stories, I typically am thinking about things like product performance, system availability, and security.  I refer to these as non-functional requirements, and the Scrum guide does not specifically speak to NFRs.  However, the scrum guide has this to say about the product backlog:
"The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. "
So, looking at the scrum guide definition it would seem that we can put NFRs in the product backlog.  Of course, the last sentence of this part of the scrum guide:
"The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." means that the team needs to work with the Product Owner on NRFs that belong in the product backlog.
Example of a Non-Functional Requirement Here is an example of an NFR that might be used in the backlog.  The team has a screen on an application that shows personal information, including credit scores to a sales administration user of your application.  Your security team has deemed that Personal Information like this cannot be displayed due to certain laws within different countries. Your product owner could add a PBI that describes hiding data on the Sales administration screen, which is not adding functionality. 
Refine the Definition of Done I also tell students that NFRs that apply to multiple PBIs might be a candidate for definition of done.  For instance, if we have a security requirement that all code must be run through a static code analysis and then dealt with, we might put running a static code analyzer against source code as part of our definition of done. 
Update the Acceptance Criteria Another way to deal with an NFR is to place it in the Acceptance Criteria of a PBI. Let's say we have a feature that includes posting data to an external data store.  The requirement was that after a sales transaction the sales data needs to be pushed in that data store within 10 minutes of the transaction.  We could easily put that into your Acceptance Criteria.
Conclusion The bottom line is that while Technical Stories, or Non-Functional Requirements are not mentioned explicitly in the Scrum Guide, the framework gives teams ways to handle them.  And in typical self-organizing fashion, it is up to the team to determine the best way to handle this for their application.
Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events
See available training courses at agilethought.com/training.
Visit the website and catch up with all the episodes at AgileThought.com!
Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!