答案 0 :(得分：12)
正如eed3si9n所说，如果你对EBS的估计是一致的，FogBugz会为你处理这个问题。
至于更一般的，FogBugz如何适应敏捷方法，你最好的选择是将sprint作为迷你版本。创建sprint并将要为该sprint实现的案例添加到该版本（或里程碑）。如果你做了一周的冲刺，就给它一个结束日期，比如一周之后。然后EBS可以跟踪它并告诉您是否按计划进行。
“报告”部分中的图表还会显示燃尽图表。术语有点不同，因为FogBugz不仅仅是敏捷，但信息就在那里。
你想看看你要完成冲刺的预期时间是保持稳定还是继续。如果它稳定，你就会走上正轨并且你的燃尽率达到目标。如果它正在爬升，你就会失势，你的冲刺正在被推迟。是时候将事情转移到下一个冲刺阶段，也可以弄清楚为什么搞砸了你的估计：）
基本上我认为这是一张燃尽图而不是燃尽图，但它给出了同样问题的相同答案。我准时按时完成吗？我还有什么要做的？
Atalasoft的Lou Franco wrote an excellent post也是如此。 Patrick Altman也有一篇文章。
更新：修复了Altman的文章
的链接答案 1 :(得分：4)
我向FogBugz家伙询问了同样的事情，因为在XP中您可以提供IET（理想工程时间）的估算值。他们的回答是在你提供估算的方式上保持一致。
答案 2 :(得分：4)
我们开始在我们的技术团队中使用FogBugz几乎所有内容：文档，错误报告，管理任务。随着时间的推移，我们逐渐变得更敏捷。
我所做的是创建了一个名为Product Backlog的版本，并且将来会给出一个任意的发布日期。我将FogBugz字段“Version”更改为“Priority”，因此我们可以按优先级排序。为了管理产品积压，我大量使用区域对用户故事进行分类。领域可能是主题或史诗。每个迭代都是FogBugz中的一个版本。
现在，我们最近开始使用的一件事是Story Points而不是Ideal Task Days来估算我们的产品Backlog。 FogBugz不理解故事点的度量单位，因此相当容易混淆，我们的产品Backlog中的1 SP在FogBugz中被报告为1天。如果有任何混淆，这可能是危险的。但我们的团队很小。我没有在FogBugz中使用内置的报告工具，但如果可以的话，它会很棒。
因此，我的所有Story Point和Velocity计算都是在Excel中的FogBugz之外完成的。这似乎现在好了。我们使用索引卡跟踪任务，将用户故事和便利贴作为办公室董事会的任务。看看Kniberg的书“Scrum and XP from the Trenches”这本书影响了我的决定。事实上，我们在早上Scrums正在盯着它的所有东西都有一块大板真的有帮助。
我确实认为FogBugz的历史估计历史和报告非常出色。这适用于计划扑克世界吗？我想至少从一个团队的估计历史来看。
由于产品Backlog中的用户故事经常随着迭代计划会话而发展，（敏捷计划）如果存在wiki样式的案例编辑而不是描述线程，那将会很棒。
有传言称下一个主要版本将更加支持敏捷流程，所以非常非常期待看到这一点。
编辑： 现在，FogBugz 7对产品“项目”Backlogs的管理更加出色。看看吧！
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx
答案 3 :(得分：4)
以下是在规划中包含故事点的一些建议：
当您将故事输入FB7时，您可以将其作为案例进行操作，并在您创建的名为“故事点”的新自定义字段中包含规划扑克中的故事点数（如何在下面执行此操作）。然后，当您开始处理该故事时，您可以根据需要将其细分为子案例，并输入完成每个子案例的预计时间（估计时间将在故事中累计（顶部） ）案例的“估计”字段，以及提供基于证据的调度/ Burndown图表）
在FogBugz安装中需要考虑修改两件事来反映您的敏捷命名。
（1）开箱即用，FB类别“功能”最像你的“故事”。但您可以更改您的类别名称，并在Admin＆gt;处添加新名称。工作流程＆gt;自定义类别。以下是有关此内容的更多信息：
http://www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457
（2）要捕获Story Points，您可能希望在Case对话框中创建自定义字段。这是通过包含的自定义字段插件完成的。有关这方面的更多信息，请访问isl = 174461
请注意，使用“自定义字段”，您还可以为“故事”添加一个文本编辑框，该文本编辑框将始终显示在“案例”对话框标题中（无论下面的案例活动历史记录有多长。）