Non-functional requirements - DoD or PBIs?

NFRs can be a good place to look for Done criteria, in so far as they might describe qualities which are invariant, and which could apply to an increment regardless of the functionality provided.

It is unhelpful to look for a direct correspondence between NFRs and Done. There can be NFRs which do not reflect usability, and some functional requirements which Developers would consider to be essential. In short they do not reflect or arise from the same understanding of professional commitment.

Hi Ian,

thank you for your answer.

I'm not sure if i understand you correctly.

My take on this topic would be, that general NFRs like minimum performance that would be applicable for every increment should be part of the DoD while NFRs that are more specific like architecture or certain security features that cannot be reached by just "checking" and keeping them in mind in other words: require active "development" will most likely end up as PBI.

I don't see why non-functional requirements can't appear in both the Definition of Done as well as their own Product Backlog Items.

I can see several examples of where non-functional requirements may appear in the Definition of Done. Some examples may be carrying out performance testing on an integrated system, performing security testing or vulnerability scanning on a fully integrated system, ensuring consistency with design systems and style guides to promote usability and accessibility.

However, I can also see non-functional requirements appearing as separate Product Backlog Items. Improving the performance of the system in a specific use case or user flow, remediation of known vulnerabilities or security issues, paying back technical debt to improve maintainability.

Context matters. Generally speaking, I'd suggest that work that must be done to ensure the quality of the system and check to ensure non-functional requirements are satisfied would generally be part of the Definition of Done and performed for all Product Backlog Items, either individually or as a small group. Work that represents changes to the product to bring it back into conformance with or improve conformance to non-functional requirements would be Product Backlog Items.

I have seen non-functional requirements represented in Definitions of Done, as part of the development standards used by an organization, as acceptance criteria, as team agreements, and as Product Backlog Items. As the others have said, it all depends on the non functional requirement, its scope and purpose. 

The Scrum Guide does not specifically mention anything about these type of items. I feel that is because it is such a widely used term that it is not consistently understood.  Those questions you are seeing on other sites can misleading and in some cases wrong.  Scrum focuses on having the Product Backlog contain all work that is needed to a product to keep it viable in the marketplace (my description, not something directly taken from the Scrum Guide).  Any details related to the quality of the work to be undertaken is dealt in the Definition of Done.  However, there are a multitude of ways to get deal with these issues and those mostly fall in the process definitions which are outside the scope of the Scrum framework. 

You have some great responses before mine.  Take time to read and think about them.  The key to passing the scrum.org tests are to understand the reasons for the framework recommendations.  The tests will challenge your ability to assess and respond based upon the Scrum framework.  Since Scrum is a framework and not a methodology, the answers are never going to be specific procedures. Learn the reasons for what the Scrum Guide states and don't take them as procedural things.