Most of us have gotten accustomed to treating non-functional requirements (NFRs) as a sidebar. It's easy to forget about them as we're heads down trying to complete functional requirements before the end of the iteration. Sometimes (if we're really honest with ourselves) we notice a performance issue but choose to ignore it. We hope that it will simply go away. For the experienced practitioners we know that is never the case. Front loading NFRs into your development process early on is one of the keys to success. What does that even mean? Take performance for example. Let's say your user base is only willing to accept page loads of under 5 seconds. That should now become part of your Definition of Done (DoD). But most users won't provide a quantitive metric like 5 seconds. Instead, qualitative expressions (e.g. fast page loads) are used that are difficult to turn into acceptance tests. So, work with your users to figure out what that quantitative threshold really is (if possible) and add it to your DoD. Then you don't have to worry about it. If you ignore NFRs or address them late, you may not be able to deploy to production due to failed UAT (user acceptance testing) or a production rollback. To make matters worse, there may be a mad scramble to figure out the nature of the problem followed by a lengthy process to fix the problem. For instance, performance issues could be related to the application, operating system, network, Internet, etc. which could involve the procurement/replacement of hardware. It's much easier to deal with these issues up front as opposed to later on when everyone is breathing down your neck because you're holding up a production deployment. Final Thoughts: Incorporate NFRs sooner than later.
