2009/03/25
It seems that from requirements management perspective there are two types of non-functional requirements. These that can be implemented once and for all ("independent" requirements) and these that affect many other user stories and hence will not get done until almost all user stories are finished ("distributed" requirement).
Sample of independent non-functional requirement written as user story: "I as CTO want all existing users to be able to keep using their old accounts so that company can keep its existing user base". Sample of "distributed" requirement: "I as CTO want the system to support IE6+, Opera and Safari so that we can maximize number of users visiting our site".
These two types of non-functional requirements should be handled in a different way. Ones that can be done once and for all can be put into the backlog as just another user story. However it makes little sense to represent non-functional requirements of the second group as user stories since we would just end up moving these stories from one sprint to the other. Better approach is to add such requirement as additional criteria in the definition of done of each story.
Of course in some cases we may not want to start implementing "distributed" non-functional requirement from the first sprint. For example PO is happy to initially have support for FireFox only so that the first version of system can be launched sooner. In such case we really need to schedule a separate story "I as CTO want all existing pages to support IE6+, Opera and Safari so that we can maximize number of users" to the first sprint where we want to start dealing with this requirement. Note that the scope of this story is limited to existing pages so that it can be done independently. To make sure that we don't forget this requirement when working on new user stories we would still need to modify the definition of done.
