Every nonfunctional requirement you have is a candidate for inclusion in your definition of done. Let me explain why.
Potentially Shippable
I’ll start by revisiting a few key terms and concepts. As you might recall, the result of each sprint should be a potentially shippable product increment. Potentially shippable doesn’t mean that what was built must actually be shipped. Shipping is a business decision that often occurs at a different cadence than sprints; in some organizations it may not make sense to ship at the end of every sprint.
Potentially shippable is better thought of as a state of confidence that what got built in the sprint is actually done, meaning that there isn’t materially important undone work (such as important testing or integration and so on) that needs to be completed before the product increment(s) could be shipped, if shipping was our business desire. To determine whether what got produced is potentially shippable, the Scrum team must have a well-defined, agreed-upon definition of done.
Definition of Done
Conceptually the definition of done is a checklist of the types of work that the team is expected to successfully complete before it can declare its work to be potentially shippable. Most of the time, a bare-minimum definition of done should yield a complete slice of product functionality that delivers validated customer value. At the most abstract level, a definition-of-done checklist might include:
- Designed
- Built
- Integrated
- Tested
- Documented
To have a useful checklist, however, these larger-level work items need to be further refined. For example, what does tested mean? Unit tested? Integration tested? System tested? Platform tested? Internationalization tested? Performance tested? You can probably think of many other forms of testing that are specific to your product. Are all of those types of testing included in the definition of done?
Nonfunctional Requirements
This brings me to nonfunctional requirements. Nonfunctional requirements represent important system-level constraints that affect the design and testing of most or all items in the product backlog. Nonfunctional requirements are used to specify various characteristics such as system performance, accuracy, portability, reusability, maintainability, interoperability, capacity, platform fan-out, and so on.
For example, a website-hosted application commonly has a Web Browser Support nonfunctional requirement that lists the specific versions of web browsers supported by the application. When the team develops the website features, it must ensure that these features work with all of the specified browsers. In this respect, nonfunctional requirements affect the design of all (or at least most) other items in the product backlog. In addition, the team must also decide when to test features in each and every web browser. So, nonfunctional requirements also affect the testing of all other items in the product backlog.
Here is the key point: Each nonfunctional requirement is a prime target for inclusion in the team’s definition of done. If the team includes the Web Browser Support nonfunctional requirement in the definition of done, the team will have to test any new features added in the sprint with all of the listed browsers. If it doesn’t work with all of them, the feature isn’t done. I recommend that teams try to include as many of the nonfunctional requirements in their definitions of done as they possibly can. Waiting to test nonfunctional requirements until late in the development effort defers getting fast feedback on critical system-performance characteristics.
Conclusion
Every development effort will have multiple nonfunctional requirements. To the extent possible, you want to identify each of them early on, since the nonfunctional requirements affect the design and testing of all other items in the product backlog. For each nonfunctional requirement that you have, I suggest the default assumption is that you include it in your definition of done. You would back off of this assumption if you have a real impediment that you can’t immediately address that prevents you from including a nonfunctional requirement in your definition of done. In those instances, you should quickly address the underlying impediment so that you can include the nonfunctional requirement in your definition of done as soon as possible.