是否应该创建用户故事来计划系统维护和支持？

　　这个问题可能源于对敏捷开发的误解。敏捷项目团队旨在为特定项目进行组装。一旦进行了一定数量的产品规划，积压计划和冲刺计划，第一个冲刺就会启动。从那时起，敏捷团队的目标是在每次冲刺结束时递增用户价值，并使团队提供这种价值的速度最大化（Velocity只是在冲刺期间完成的Story Points数量的一个奇特术语），Story Points是用于相对彼此调整用户故事大小的度量单位。
　　所有这些都意味着速度包含了与开发用户故事所定义的特征相关的所有成本。敏捷团队中仍然存在开销。事实上，故事点根本就不可能追踪绝对时间。他们的目的是显示相对大小和复杂性的用户故事的优先次序和冲刺规划的目的。
　　通常，项目管理和产品管理时间被集中在间接成本中。其中一个主要原因是这些角色所做的大部分工作不能用用户故事来一对一映射。有大量的项目管理工作和产品管理工作的产生对用户并没有价值。例如，产品经理可以记录或引导创建一系列用户故事，这些用户故事一旦被评估，最终将被排除在优先级之外。也许做出的决定是，在用户故事中没有足够的价值来开发它们。因此，这是一个例子，用户故事不会跟踪敏捷项目团队工作人员所花费的时间。
　　所以回到我们原来的问题，是否应该为维护和支持创建不同的用户故事？简短的回答是：不，一旦开发了系统或应用程序，就会继续进行硬件和基础架构管理。有人需要监视服务器负载，当系统负载上升到服务器性能下降开始时，将新的虚拟服务器联机等。
　　稍微长一点的答案是，尽管用户故事不应该只为系统支持或维护创建，支持和维护任务有时可以在有意义的情况下被定为新的用户故事。如果预先知道用户故事中定义的特征需要大量的基础设施来支持新的功能，那么在用户故事估计中应该包括建立和配置新服务器所需的时间。当然，将时间分配给需要新后端资源的几个用户故事是有意义的。所以，这取决于工作是否是用户故事本身的结果。
　　值得注意的是，重构是敏捷开发的一个自然和必要的部分。重构描述了在不影响用户查看系统外部功能的情况下重构现有代码内部结构的行为。可能需要重构来改进系统的非功能方面，如响应时间，或者可能需要重构来支持当前体系结构结构不支持的新特性。在敏捷项目中，重构是预期的并且应该被计划。在可能的情况下，重构的增量成本应该分散在受影响的用户故事中。用户描述包含接受测试，在重构发生后需要重新测试以确保现有功能没有被破坏。