在梳理用户故事时，一个常见问题是：我们应不应该有独立的性能测试相关的用户故事？
这个问题并不能简单地回答是或否，在系统的复杂度不同以及团队职责分布不同的情况下，情形会有所不同。
对一般小的产品，测试比较简单，可以将性能指标作为一个用户故事验收条款的一部分，这时就不需要独立的用户故事条目。
对于复杂大系统，性能测试的环境搭建就可能不是易事，这时可以将性能测试及其优化相关的用户故事独立出来，此时有可能分成两类用户故事：
一类是得到各项性能指标和分析结果，用户为内部干系人或者系统购买方，目标是帮助分析系统瓶颈和为下一步的系统性能优化提供依据，而系统购买方的目标可能是便于规划系统容量、选择布署方案以及管理最终用户期望等。此时用户故事的描述可能是这样的：
作为一个系统架构师，我想得到X系统当前的各项性能指标，以便于分析系统瓶颈和制定恰当的优化行动
作为系统规划师，我想得到X系统当前的各项性能指标，以便于制定系统布署方案另一类则是故事本身不仅包含得到系统的各项性能数据，而且必须满足设定的性能指标（质量属性，系统好到什么程度，可以按程度分成若干用户故事），此时描述用户故事时，最需要注意的是此时的用户故事并不是性能测试本身，而是系统性能应该满足的性能指标。比如对于高可用性（high availability）的用户故事，要描述的是系统局部出现故障后对用户的影响，在具体的验收条款里，可以使用given， when， then格式描述在某些具体场景下系统应该如何反应，对哪些用户产生影响及其程度，如果要求工作正常，需要回归测试最主要的功能（smoke testing）或者全面回归测试全部功能，视风险程度和测试自动化水平而定。例如：
作为X系统的用户，我想要在系统运行的多个数据中心的一个完全损毁的情况下继续使用该系统，以便于不影响我的工作。
通常的性能优化可分为三步：
第一步：
- 明晰不同的系统配置（包括硬件和软件运行环境）和不同测试场景的质量属性的需求 （质量属性可能包括延迟，容量，响应时间，流量，稳定性，峰值等等）
- 明晰测量质量属性时要监控的系统状况指标 （CPU利用率，内存占用率，disk IO吞吐率，网络接口流量，内部各种buffer的使用情况等等）
- 各种场景下的测试方法和测试工具 （是否需要自己编写测试程序或脚本等）
第二步：
- 各种场景要考虑和定义用户或系统的典型行为，以及极端行为 （特别是容量和性能测试时），模拟或触发这些行为做测试。
- 展开测试，得到各项数据，编写当前系统的性能测试报告，分析与需求之间的GAP，识别瓶颈
- 在端到端测试即便得到数据，也无法判断瓶颈所在的情况下，分析可能的瓶颈所在，在风险最大的地方分段分component测试
第三步：
- 根据瓶颈分步优化，注重系统整体性能，切忌过度局部优化
第一步是基本的环境，为后面作准备，通常并不作为独立的用户故事。不过当需要开发相关的测试工具时，也可以作为独立的用户故事。第二步和第三步可以分成多个用户故事来做。
最后，特别需要注意，对于每一次交付的软件，我们要清晰地知道并告知客户和用户具体的性能指标和其它质量属性。一些公共的质量属性可以放入DoD，要求所有的用户故事必须满足，否则不能算Done。同时应该尽量避免出现质量属性下降的情况，即便不能达到新的更高要求，原有的质量属性至少需要保持。这就需要有强大的持续集成、自动化测试、自动化布署和系统级自动化性能测试系统，以及以特性团队方式工作，这样才能使得有可能在同一迭代之内完成对系统的质量属性的多次测试以及必要的优化。如果做不到在同一迭代期内获得所有质量属性数据，也要尽量缩短间隔时间，并根据实际的数据和优先级排定优化次序。