刚开始一个项目时，您将一无所有--没有UI，没有数据层，之间也没有任何东西。因此，像“用户应该能够查看其foos”这样的单一故事将需要大量工作。一旦有了这个故事，诸如“用户应该能够编辑其foos”这样的故事就更现实了，但是第一个故事将涉及设置UI层，表示逻辑层，域逻辑层和数据访问层。
这与我的“任务”概念不符：对我来说，我宁愿有以下“任务”之类的东西：
所有这些都属于上面的单个“故事”吗？如果是这样，我觉得故事在项目的早期并不是一个非常有用的框架。如果是这样，那很好--我只是想确保我没有错过任何东西，因为我真的在尽我所能尝试学习这种敏捷方法。
Answers:
这是一个很好的问题，可能会有几个很好的答案。我的看法是：
故事是用户故事，因此必须以描述它如何使用户受益的术语进行定义。
如果敏捷和故事对您有用，那么即使在开始阶段，它们也应该起作用。第一个要点是单个用户故事（虽然措辞有点技术性），但是其他三个是技术任务描述。
在项目的开始阶段，当你不具备相应的框架到位，使CRUD（ç reate，[R EAD，ū PDATE，d elete）发展快速和容易，你的故事必须要小的多，增量件。
而不是“用户应该能够查看其foo”，而是这样的：
请记住，大多数似乎无法在单个冲刺中发展的用户故事（我发现，大于约8个故事点或开发天数的东西都太大了）可能可以分解为仍然有意义的部分用户。
故事/功能不必适销对路，对产品所有者而言必须有意义。在上述情况下，你可以把一些快速的演示片，显示发生了什么变化和故事现在是如何完成的 -例如，对＃3，您可以显示的页面为两个不同的用户提供数据预填充数据库。在阶段2，所有用户都将看到相同的数据。
您要问的是至关重要的“您如何考虑问题空间”，以便将其分解为明智的部分，您可以从中进行设计。
无论您将其称为用户故事，分析，分解，规范还是需求收集……最终都会归结为几件事，通常情况下会有一些迭代。
您需要从用户的头上得到他们想要的东西。（他们可能知道他们想要的一些东西，并且想要一些不一致但还看不到的东西。）
您需要以某种形式捕获它-您实际上只有2个选择：文字或图片。两者都有力量，如果可以，请同时使用它们。从后来发生的合同纠纷的角度来看，言语最终会更有力。
您需要提出此意见并寻求协议。
有些人在没有业务或其他逻辑的情况下进行了早期的视觉原型。这可能是一项强大的技术-从某种程度上讲，因为它仍然涉及一定量的挥手。
一些故事板-然后介绍和解释。
有些人会编写严格且经过仔细分析的文档。
每种技术都有其优点和缺点。
关于我唯一要提供的建议是：过早地编码解决方案通常是一个错误的举动。在您做之前，先了解对WHO和WHY做什么，通常可以减少返工，并加快开发速度。
当您谈论“任务”时，在我已经了解了以上内容，目的和原因之后，这似乎是对工作的分解。在您了解用户故事并在文档中被客户认可为您要进行的工作范围之前，您无法弄清楚WELL任务。知道要实现的目标（输出）可以找出任务（到达目标所涉及的步骤）。
不要无视前端分析和文档。
我认为您所缺少的是用户故事是关于描述用户期望如何使用该系统的。这是确定业务需求的一种方式。它们并非旨在直接告诉您技术上应该做什么，这似乎是您想要的。
可以说，这是项目中最重要的部分之一。如果您没有正确地满足业务要求，那么该系统将对用户无用。