非功能需求一般和系統的狀態有關而與系統需要提供的功能無關。通常是系統的“ ilities”功能，比如可擴展性(scalability)、互操作性(interoperability)、可維護性(maintainability)、移植性(portability)、性能和安全性都包括在此類。
敏捷團隊經常糾結于定義和估算項目的非功能需求。
Mike Cohn建議幾乎所有的非功能需求都能以用戶故事表述。他給出了幾個例子展示非功能需求能夠適用標準的用戶故事模板
幸運的是約束/非功能需求能很容易的按用戶故事處理。這里給出幾個例子：
作為客戶，我要在從
Windows 95之后的所有版本的Windows上運行產品。
作為CTO，我要(新)系統使用我們已有的訂單
數據庫而不是創建新數據庫，這樣我們就不用再多維護一個數據庫了。
作為用戶，我要網站在99.999%的時間是可訪問的，這樣我就不會感到沮喪并找其它的網站來用。
然而，Mike也警告說用戶故事模板只是用來作為一個思考工具。不應該用一個固定的模板來記錄所有的非功能需求。
Jason建議不要試圖在用戶故事級別記錄非功能需求，團隊應該把它們作為(項目)大圖景的一部分。按照Jason所說，在他的團隊，他們嘗試過在每個單獨的用戶故事級別記錄非功能需求，但是沒起到作用。他提到：
我喜歡把這些非功能需求(NFR)用戶故事寫在墻上并在
工作區都能看到，這樣可以提醒團隊在給出估算時考慮這些約束的因素。
Mike還提出一種明確的方法來估算非功能需求。按他所說，非功能需求與兩個成本相關聯
初始遵循(非功能需求)成本——團隊滿足非功能需求所用的工作量。比如，在sprint 5花在
性能測試上的工作量。
持續遵循(非功能需求)成本——在以后的sprint中滿足非功能需求的工作量。
一旦團隊接受非功能需求作為項目的一部分(就像我們團隊在sprint 5中做的)，他們需要把持續達到非功能需求作為項目的提示。我認為這種成本就像上稅。進行性能測試(或者說遵從任何非功能需求)產生了一些額外的開支(稅)。這種開支，或者說稅，是必須定期付出的。
為了估算，Mike認為這兩種成本需要單獨考慮。初始遵循成本應該和任何其它的用戶故事或產品backlog中的任務一樣被估算。持續遵循成本，團隊和product owner需要決定多久要進行一次遵循驗證工作。
例如，假設團隊和product owner同意每四個兩周的sprint中進行一次性能測試。團隊估算每次第四個sprint有六個點的工作要做。那就是大約每個sprint1.5點。如果團隊的速度(velocity)是30個點，1.5點可以認為是大約5%的稅。
Nick Xldis對遵循成本進行了一次非常有意思的觀察。據Nick所說，
如果這種稅持續增長，那你的架構或流程上就有問題了，需要格外關注。這是對于技術債的很好的晴雨表。
Scott Ambler通過提升一個獨立測試團隊的能力分享了管理非功能需求的想法。
Kassab、Olga、Maya和Alain介紹了NFR大小測量方法(NFSM)來減少估算非功能需求中的不確定性。
因此，處理非功能需求可能不是痛苦的掙扎。關鍵是盡早處理它們并關注持續成本。
注意：關于非功能需求這一術語的使用有很多想法和爭論。Mike Cohn稱其為約束而Tom Glib強烈建議稱之為質量需求。