我们正试图在开发环境中实现敏捷方法论。一个故事需要一个开始和结束日期吗？还是它完全适用于Sprint？
-Alan-
"结束日期"是什么意思？你期望完成故事的日期（可怕的截止日期）或你实际完成故事的时间。
我想说，故事在Scrum²中没有"我希望开始/结束这个故事的日期"。相反，你所拥有的是"团队致力于承担故事的冲刺"。这就像一个结束日期，因为你得到了一个"一切顺利，它将在这个sprint结束时发布"，但它的粒度不那么精细，因为在sprint开始时承诺的所有工作，如果一切顺利，将在sprint结束后发布。在团队真正承诺之前，你也不会得到这些信息
您还可以估计剩余积压工作的规模和团队的速度。这可以为故事何时开始提供指导。但这是一个冲刺的指南，而不是一个艰难而快速的日期，你会拿起这个故事。
那么，你需要什么开始/结束日期呢？一旦你知道你可能会找到其他指标之一，Scrum/你的敏捷风格将为你提供你想要的数据。或者发现你想要的数据和敏捷不能协同工作。
1） 我注意到一种远离"承诺"的趋势，因为当它真正意味着"我们将努力在那时完成"时，听起来相当固定。
2） Scrum只是众多不同敏捷方法中的一种，尽管许多人认为他们拥有一种真正的Scrum形式，但让每个人都同意一种真正Emacs绑定，即一种真正形式的Scrum，会更容易。敏捷或Scrum的一些实现可能有截止日期。
故事没有开始和结束日期。
故事是有价值的部分，可以（也可以不）在您的应用程序中实现。
在Scrum中，实现故事的决定是在sprint计划会议上做出的，在会议上，故事被转移到正在计划的特定sprint积压工作中。有时，尽管故事在这一点上是分开的，所以一个特定的（原始）故事实际上可能只是部分实现或在不同的时间实现。
因此，从某种意义上说，故事的"开始"one_answers"结束"日期是实现它的sprint的开始和结束日期，还有上面的注意事项。
就像其他人说的那样，用户故事会在你开始工作时得到开始日期，而完成日期则是你完成工作时。我想你可能想知道这个故事需要多长时间才能完成——如果是这样的话，我通常会把它们放在1小时4小时8小时的桶里。如果它们不属于这些类别，你可能需要重新思考用户故事的复杂性，因为这可能是你正在处理的一项艰巨任务，需要一部用户史诗。。。这只是一个更大的故事。