On our last Deliver It Cast, Kim and I talked about what to do with Technical Stories / Debt for your product. The TL/DR version is to schedule it just like the other work and don’t skimp on it.
One thing we left out of that conversation is what most waterfall projects call “Non-Functional Requirements”. I dislike that term and the implications it has, especially for an agile project. The idea that an attribute of a system is something separate from what you are building is alien to me now. All of the “ilities” should be a part of the story you are writing for the feature/benefit you want. If performance is part what the story requires, then make that part of the story and acceptance criteria. If scaling the app is important, it should be part of at least one story that is being created. If you need to performance test your system outside of a technical / business user story then make a card for it and do it. If it’s not part of the story, or if you can’t determine it’s value then don’t do it. A product owner should only include and prioritize work that is valuable. Optional things are waste and don’t make it to the roadmap or backlog.
No matter what you want to call it ( but please not a non-functional ), it’s work that needs to be done and the team needs to do it. Because of that, it’s a story that gets prioritized with the rest of the work that’s being asked.