在梳理用戶故事時，一個常見問題是：我們應不應該有獨立的性能測試相關的用戶故事？
這個問題并不能簡單地回答是或否，在系統的復雜度不同以及團隊職責分布不同的情況下，情形會有所不同。
對一般小的產品，測試比較簡單，可以將性能指標作為一個用戶故事驗收條款的一部分，這時就不需要獨立的用戶故事條目。
對于復雜大系統，性能測試的環境搭建就可能不是易事，這時可以將性能測試及其優化相關的用戶故事獨立出來，此時有可能分成兩類用戶故事：
一類是得到各項性能指標和分析結果，用戶為內部干系人或者系統購買方，目標是幫助分析系統瓶頸和為下一步的系統性能優化提供依據，而系統購買方的目標可能是便于規劃系統容量、選擇布署方案以及管理最終用戶期望等。此時用戶故事的描述可能是這樣的：
作為一個系統架構師，我想得到X系統當前的各項性能指標，以便于分析系統瓶頸和制定恰當的優化行動
作為系統規劃師，我想得到X系統當前的各項性能指標，以便于制定系統布署方案
另一類則是故事本身不僅包含得到系統的各項性能數據，而且必須滿足設定的性能指標（質量屬性，系統好到什么程度，可以按程度分成若干用戶故事），此時描述用戶故事時，最需要注意的是此時的用戶故事并不是性能測試本身，而是系統性能應該滿足的性能指標。比如對于高可用性（high availability）的用戶故事，要描述的是系統局部出現故障后對用戶的影響，在具體的驗收條款里，可以使用given， when， then格式描述在某些具體場景下系統應該如何反應，對哪些用戶產生影響及其程度，如果要求工作正常，需要回歸測試最主要的功能（smoke testing）或者全面回歸測試全部功能，視風險程度和測試自動化水平而定。例如：
作為X系統的用戶，我想要在系統運行的多個數據中心的一個完全損毀的情況下繼續使用該系統，以便于不影響我的工作。
通常的性能優化可分為三步：
第一步：
明晰不同的系統配置（包括硬件和軟件運行環境）和不同測試場景的質量屬性的需求 （質量屬性可能包括延遲，容量，響應時間，流量，穩定性，峰值等等）
明晰測量質量屬性時要監控的系統狀況指標 （CPU利用率，內存占用率，disk IO吞吐率，網絡接口流量，內部各種buffer的使用情況等等）
各種場景下的測試方法和測試工具 （是否需要自己編寫測試程序或腳本等）
第二步：
各種場景要考慮和定義用戶或系統的典型行為，以及極端行為 （特別是容量和性能測試時），模擬或觸發這些行為做測試。
展開測試，得到各項數據，編寫當前系統的性能測試報告，分析與需求之間的GAP，識別瓶頸
在端到端測試即便得到數據，也無法判斷瓶頸所在的情況下，分析可能的瓶頸所在，在風險最大的地方分段分component測試
第三步：
根據瓶頸分步優化，注重系統整體性能，切忌過度局部優化
第一步是基本的環境，為后面作準備，通常并不作為獨立的用戶故事。不過當需要開發相關的測試工具時，也可以作為獨立的用戶故事。第二步和第三步可以分成多個用戶故事來做。
最后，特別需要注意，對于每一次交付的軟件，我們要清晰地知道并告知客戶和用戶具體的性能指標和其它質量屬性。一些公共的質量屬性可以放入DoD，要求所有的用戶故事必須滿足，否則不能算Done。同時應該盡量避免出現質量屬性下降的情況，即便不能達到新的更高要求，原有的質量屬性至少需要保持。這就需要有強大的持續集成、自動化測試、自動化布署和系統級自動化性能測試系統，以及以特性團隊方式工作，這樣才能使得有可能在同一迭代之內完成對系統的質量屬性的多次測試以及必要的優化。如果做不到在同一迭代期內獲得所有質量屬性數據，也要盡量縮短間隔時間，并根據實際的數據和優先級排定優化次序。