@Christian-Sauer The theoretical answer is that non-functional requirements are to be modeled as constraints on user stories, per this guidance from the Scaled Agile Framework website.
Mike Cohn covers this in Chapter 16 of User Stories Applied, where he illustrates how to add constraints to a paper-based story card.
Unfortunately, this doesn't work well in practice with large teams because the constraints aren't easily tracked in most agile requirements management tools.
In practice, I like to write user stories and acceptance criteria for these types of requirements, using the requesting system as the user in the story. Why? This approach forces the technical team to explain what "good" looks like, in a manner that is fully testable via well formed acceptance criteria.
The non-functional user stories can be linked to what I call "architecturally significant user stories," prioritized, and assigned for implementation during one or more sprints.
UPDATE: What makes a story architecturally significant?
A story is architecturally significant when implementation of the required business behavior impacts or stresses one or more non-functional constraints of a system.
Example: On a top 20 Internet Retailer website that caters to business customers, display of customers-specific pricing during search is an architecturally significant user story.
User story: As a Purchasing Agent, I want to see my discounted pricing during search so I can know I am getting the lowest contracted price before adding an item to my shopping cart.
Customer-specific pricing for B2B websites is very complex because a given customer may simultaneously participate in multiple contracts that have varying discount levels across product categories. Therefore, the ability for the end user to see the "lowest contracted price" during search is architecturally challenging. A large B2B website may contain hundreds of millions of customer-specific prices.
These prices must be accessible in less than 200 milliseconds if the search results are to be returned to the shopper's browser in less than 1 second. Implementing this user story early in a project allows the project team to verify whether the architecture of the application can deliver to the 200 millisecond constraint.
NFR Story: As the website presentation layer, I need the pricing component to return catalog and/or customer specific prices for a page of search results within 200 milliseconds so I can render a web page of search results for products within 500 milliseconds.
Acceptance Criteria: The acceptance criteria for a user story provide additional details about the story for the development team, explaining the conditions that must be present for the product owner to agree that the story has been fully implemented.
For a non-functional requirement, the acceptance criteria should describe how we would observe achievement of the requirement under various real world usage scenarios. Returning to our pricing service response time user story, here are some acceptance criteria for this story.
- Verify that the average response time to price a list of 16 products is less than or equal to 200 milliseconds.
- Verify that the average response time does not degrade by more than 5% when pricing larger groups of products, including 50, 100, and 200 products.
- Verify that the 95%-ile in response time is within 20 milliseconds of its average.
- Verify that the average and 95%-ile response time goals are met when the pricing service handles requests at the following volumes: 100 requests / second, 500 requests / second, 1,000 requests / second.
- Verify that the average and 95%-ile response time goals are met when the pricing service must price from product data that includes the following numbers of customer-specific and program prices: 10,000,000, 50,000,000, 100,000,000, and 150,000,000.
- Verify that the average and 95%-ile response time goals are met when the pricing service must price a mix of products including catalog pricing, standard discount pricing, and customer-specific pricing where the customer qualifies for pricing on multiple contracts (e.g. State of Colorado, Colorado University System, and Western States Contracting Alliance).
I encourage my engineering leads to schedule architecturally significant stories early in projects so we can find potential problems in the architecture as soon as possible, because this gives the team more time to solve the problems than when the hard parts are deferred to program increments / sprints later in the delivery cycle.