我试图弄清楚何时使用用户故事是合适的。总是还是不？
例如，考虑一个团队从头开始工作，比如电影票预订服务。为该功能想出用户故事很容易，例如： “作为最终用户，我希望能够浏览在 X 影院放映的电影”等等。
但在实现这些之前，需要设计系统：必须设计架构、必须设计数据库、为 GUI 和业务逻辑选择技术。
这些任务应该如何出现在待办事项中？它们也应该是用户故事吗？如果是这样，他们如何遵守 INVEST 助记符？它们并不单独为最终用户提供任何东西，但是在实现任何功能之前都需要它们。
【问题讨论】：
标签： scrum user-stories
但在实现这些之前，需要设计系统：必须设计架构、必须设计数据库、为 GUI 和业务逻辑选择技术。
不太同意。由于故事是一个功能，它几乎需要架构的每一层来实现故事，同时构建架构。检查 Alistair Cockburn 的 Walking Skeleton 定义。
您可以将大多数故事定义为“作为用户...”，因为故事可能还具有 UI 功能。因此，为了清楚起见，您可以将故事分成子任务。 尽管有些工作很难在 INVEST 用户故事中呈现。例如错误，技术。部门等等。它们仍然以特殊类型的故事（错误、技术故事）的形式呈现。您无法在 Demo 上展示它们，但您可以提及。
【讨论】：
(...) before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic. (...)
不完全是。例如，您不需要为实现冲刺、特定版本或任何给定时间的功能而设计的整个数据库。您可能需要的是一些共同点。
这是敏捷的一位美女（与瀑布相比）生活的地方，欢迎变化。
现在，回答您的问题：意识到用户故事中的角色不一定是最终客户的角色。可能是您的开发人员、系统管理员等。因此：
AS A server administrator,
I WANT to upgrade our webserver
SO THAT it will handle better the memory consumption
所以，您可以询问说服您的 P.O.在待办事项列表中添加或优先考虑一个（或多个）用户故事，为未来的发展奠定基础。 但是，在创建此类故事时，请记住响应变化的敏捷价值。
附言
保持产品待办列表清晰且易于访问，并在采购订单之间提供适当的交互也很重要。和开发团队。这应该由 Scrum Master 指导。
这样，团队可以从技术角度提供更好的反馈/警告 P.O.，一个故事如何相互影响以及为什么应该在故事 Y 之前完成故事 X。
【讨论】：