我们有一些产品，其中一种产品使用平面文件进行持久化。套件中的其他产品可以使用该数据（通过 API），但一次只能使用一个。
我们不能将整个文件作为其庞大的数据放入数据库中。20GB + ..但我们仍然找到了一个解决方案，可以将一些数据放入数据库中。例如用户解释、元信息、标记等。
所以故事是这样的：
“作为用户，我可以同时从产品 B、C 和 D 访问产品 A 数据”。这是巨大的，即大约 6-8 个月
即使我将其保留为“作为用户，我可以同时从产品 B 访问产品 A 数据”。它仍然很大.. 即大约 5-6 个月
即使像下面这样，它仍然很大。“作为用户，我可以同时从产品 B 访问产品 A 数据的功能 X”。即大约4-5个月。
问题是如果我们可以做一件事（一个功能，一个产品），我们可以快速完成所有事情。
我怎么能把这个故事分成子故事……或者我应该接受一些故事不能进一步分成可以适合一次迭代的子故事。
PS：我们使用scrum
问问自己（和你的团队）：是什么让故事如此之大？在此过程中绝对没有可以显示的好处吗？功能和产品将是明显的削减，但可能不一定（如您所展示的）足够好。
该功能的子组件怎么样？你在放什么？是否有任何外部可见或有价值的东西？
您是否有产品的身份验证、配置或其他“标准”方面？你可以把它们删掉，把它们作为用户故事。
也许可以进一步减少 3-5 个月的功能？
反正，
我希望这会有所帮助，
阿萨夫。
你所描述的是我们所说的“史诗”——它实际上是你用更大的描述符描述的小故事的集合。我建议您进行更多分析，以确定系统的哪些部分会受到您的请求的影响。您可能拥有单独受请求影响的报告、条目表格等分组。
以用户故事的形式处理“史诗”请求对每个领域的影响。例如，“增强报表 X 以包含来自产品 B 的数据”、“增强报表 X 以包含来自产品 C 的数据”等。我不太了解您要更改哪些内容以使标题更具描述性，但希望您能得到这个想法。继续这种解构，直到故事达到 2、3 或 5 分的最佳点。
这样做的好处是，它还允许 PO 在看到此请求的所有成本后做出决定。他们可能会决定，一旦他们看到包含产品 C 的成本，我们真的只需要访问产品 B 的数据就可以成功。
敏捷完全支持某些功能的视野比典型的冲刺期（2-4 周）更长。当然，故事可以分解为任务。在这种情况下，我建议优先考虑这个故事的任务，并使用你的 Scrum 方法将它们烧掉。在每个 sprint 结束时，您仍然应该拥有可以演示/测试的“工作软件”。您可能还没有完整的功能，这没关系。