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