我刚刚完成了监督学习算法的原型实现，自动为我们公司数据库中的所有项目（大约 500 万个项目）分配分类标签。
结果看起来不错，我已获准计划生产实施项目。
我以前做过这种工作，所以我知道软件的功能组件如何。我需要一组网络爬虫来获取数据。我需要从抓取的文档中提取特征。这些文档需要被分成“训练集”和“分类集”，并且需要从每个文档中提取特征向量。这些特征向量自组织成簇，簇通过一系列的再平衡操作。等等等等等等等等。
所以我制定了一个计划，其中包含大约 30 个独特的开发/部署任务，每个任务都有时间估算。开发的第一阶段——忽略一些我们希望长期拥有的高级功能，但还没有足够高的优先级将其纳入开发计划——预计需要大约两个月的工作时间. （请记住，我已经有了一个工作原型，所以最终实现比从头开始项目要简单得多。）
我的经理说这个计划对他来说很好，但他问我是否可以将任务重新组织成用户故事，原因如下：（1）我们的项目管理软件完全围绕用户故事进行组织；(2) 我们所有的调度都是基于将整个用户故事融入到 sprint 中，而不是单独调度任务；(3) 其他团队——比如 Web 开发人员——已经充分利用了敏捷方法，他们从将所有软件功能建模为用户故事中受益。
所以我在项目的顶层创建了一个用户故事：
作为系统的用户，我想按类别搜索项目，以便在庞大、复杂的数据库中轻松找到最相关的项目。
或者，这个功能的更好的顶级故事可能是：
作为内容编辑器，我想为我们数据库中的项目自动创建分类名称，以便客户可以在我们庞大而复杂的数据库中轻松找到高价值数据。
但这不是真正的问题。
对我来说，棘手的部分是弄清楚如何为机器学习架构的其余部分创建从属用户故事。
恰当的例子......我知道该算法需要两个主要的架构细分：（A）训练和（B）分类。而且我知道架构的训练部分需要构建一个集群空间。
我读过的所有敏捷开发文献似乎都表明，用户故事应该是“提供任何商业价值的最小可能实现”。在设计最终用户软件时，这很有意义。从小处着手，然后在用户需要附加功能时逐步增加价值。
但集群空间本身提供零商业价值。爬虫或特征提取器也没有。部分系统没有商业价值（对最终用户或公司内部的任何角色都没有）。训练有素的集群空间只有使用爬虫和特征提取器才有可能，并且只有当我们还开发了一个随附的分类器时才相关。
我想可以创建用户故事，其中系统的从属组件充当故事中的用户：
作为监督学习的集群空间构建例程，我想使用来自特征提取器的数据，这样我才能存在。
但这似乎真的很奇怪。作为开发人员（或我们的用户，或任何其他利益相关者），对我的用户故事进行建模有什么好处？
虽然主要故事可以很容易地沿着架构组件边界（爬虫、训练器、分类器等）划分，但从用户的角度来看，我想不出任何有用的分解。
你们有什么感想？您如何为复杂的、不可分割的、非面向用户的组件规划敏捷用户故事？