I don’t see it as a red flag. The example might be a bit too generic. But consider a story like “As Mary I want the homepage to be completely loaded within 500ms.” A lot of stories in the development process will affect the homepage later – let’s say of a web shop. Developing this NFR would mean 2 things in my point of view:
1. Make it load within 500ms now – this could be an epic in itself depending on the current state.
2. Create an automated test that will check with each new iteration that the constraint is still met.

What about a reliability requirement which expresses a scenario where after a system failure the system reboots and is operational in a certain amount of time? In this case, this is not associated to a particular functionality…

It does seem like a judgment call. However, I find that nonfunctional requirements that apply to the entire system or more than one epic are a red flag. For example, it’s unlikely that the same performance constraint truly is “required” for all functionality of the system.

Hi Roger, Thanks a lot for your comment. I share your view, as long as an NFR or constraint is limited to an epic or story. But when nonfunctional properties constrain the entire product or several epics, I find the introduction of a separate constraint story helpful. Examples are generic performance requirements, or a robustness requirement that applies to all payment stories. Do you agree?

Accordingly, I think it makes sense to capture the nonfunctional requirements as acceptance criteria for epics or user stories, without separate stories for nonfunctional requirements.

I consider a constraint story as “done” when its narrative has been implemented successfully and the acceptance criteria are met. You may want to state in your Definition of Done that the generic NFRs in your Product Canvas or product backlog – those NFRs that apply to all stories – have to be fulfilled. Does this help?