我不确定何时将故事分解为故事或任务。
比方说，您有一个讲述降低服务质量的故事，要做到这一点，您必须分析和折旧5个api，每个api都需要一周时间
您将如何做？
1）将故事分为5个故事，这样每个故事都小于冲刺，可以由某人拥有（但不能被贬低）
2）将一个故事分解为任务，但随后有多个人在处理一个故事，而一个故事持续的时间比冲刺还多
其他？谢谢
假设您有一个有关降低服务水平的故事
您为什么这样做？谁将从中受益？
该信息将帮助您创建与工作项关联的故事。
作为[从这项工作中受益的人]，我希望降低服务水平，以便[原因]
现在，一旦定义了用户故事，您就可以向其中添加描述该工作如何完成的子任务。例如
子任务1 =弃用API X
Sub-task2 =弃用API Y
从我的角度来看，所谓的故事应该是史诗般的。这部史诗应该分为多个故事，每个故事都应对不同服务的退役。
将故事分成子任务也同样重要，因为您很可能会发现“隐藏的缺陷”。它还将使您在完成故事的过程中更加透明。如果从任务分配的角度讲故事相似，则可以将第一个定义为其他故事的模板。
您可以从不同的角度查看此主题：您的目的是删除一些阻碍进度的服务。放下一项服务后，您将更接近撤消所有服务的预期结果。当然，每台退役的服务器为您，您的团队或客户带来更多价值。