我很感兴趣阅读Ron Jeffries的这篇博客文章，内容涉及 烧掉用户故事而不是任务。对不起，双关语，但这是我目前的热门话题-
如果它’可以避免花费时间 Sprint计划，将用户故事分解为任务 并以小时为单位进行估算，这将减少过多详细计划迭代的开销。我相信这是任何开发团队都会欢迎的。
仅以分数估算还可以使团队实现以下优势： 速度，导致团队’估计是自我纠正的。否则那里’人们倾向于将点转换为小时并与可用时间进行调和，这本身可能会引起一些问题（看到这里的例子）。
话虽如此，这只有在 用户故事很小，例如1或2天。否则，较长的故事可能会在Sprint结束时完成，这意味着 燃尽图 不会在整个Sprint中提供早期反馈和进度可见性。我个人认为燃尽图是非常有价值和强大的工具，因此我认为这非常重要。
关于罗恩的评论之一’职位表明团队必须具备多种技能–都有能力做所有事情–使其真正起作用。我不’真的相信’是这样。如果用户故事很小，我不会’看不到团队真正协作需要完成的工作。假设您在团队中拥有设计师，前端开发人员，后端开发人员和测试人员。一世’确保他们可以根据自己的技能找出如何划分工作以完成故事的方法，而不必经过在Sprint计划会议中分解每个故事的过程。
另一方面，我确实相信Sprint规划会议具有真正的价值，并且作为团队来完成本次会议的大部分内容。但我认为最大的价值在于 Sprint计划的第一部分 –了解用户故事并阐明要求。
I’我听说过并阅读了各种不同的观点。一世’d喜欢听到您对此发表评论吗？
凯莉
摄影者 ViaMoi
