As eed3si9n said, if you are consistent in your estimates for EBS, FogBugz will take care of this for you.
As to the more general, how does FogBugz fit with the Agile methodology, your best bet is to do sprints as mini-releases. Create a sprint and add the cases you want to achieve for that sprint to that release (or milestone). Give it an end date, say a week away, if you do week long sprints. Then EBS can track it and tell you if you are on schedule.
The graphs in the Reports section will also show you a burndown chart. The terminology is a bit different because FogBugz isn't Agile-only but the info is there.
You want to see if the expected time you are going to finish your sprint is staying steady or going forward. If it is steady you are on track and your burndown rate is on target. If it is creeping up, you are losing ground and your sprint is getting delayed. Time to move things to the next sprint or figure out why you messed up your estimates :)
Essentially I suppose this is a burn-up chart instead of a burndown chart, but it gives you the same answer to the same question. Am I going to finish on time? What do I have left to do?
因此，我所有的故事点和速度计算都是在 Excel 中的 FogBugz 之外完成的。 目前看来这还好。 我们使用用户故事索引卡和便利贴作为办公室板上的任务来跟踪任务。 看看 Kniberg 的《Scrum and XP from the Trenches》一书，它影响了我的决定。 实际上，拥有一块大板，上面有我们早上 Scrums 所关注的所有内容，这确实很有帮助。
We started using FogBugz for pretty much everything within our technical team: Documentation, bug reporting, managing tasks. We have progressively got more Agile as time has gone on.
What I have done is created a release which is called the Product Backlog, and this is given an arbitrary release date in the future. I changed the FogBugz field "Version" to "Priority" so we can sort by priority. To manage the product backlog I heavily use Areas to categorise the user stories. Areas could be Themes or Epics. Each Iteration is a Release in FogBugz.
Now, one thing we have recently started using is Story Points as opposed to Ideal Task Days for estimating our Product Backlog. FogBugz doesn't understand a unit of measurement of Story Points so rather confusingly, 1 SP in our Product Backlog is reported as 1 Day in FogBugz. This could be dangerous if there is any confusion. But our team is small. I don't use the in built reporting tools in FogBugz, but it would be great if I could.
So, all my Story Point and Velocity calculations are done outside of FogBugz in Excel. This seems to be fine for now. We're tracking tasks using index cards for user stories and post-it notes as tasks on our boards in the office. Have a look at the book "Scrum and XP from the Trenches" book by Kniberg which influenced my decision. Actually having a big board with everything on it which we are staring at in our morning Scrums really helps.
I do think the historical estimation history and reporting in FogBugz is excellent. Does this work with the planning poker world? I suppose at least from a team's estimation history it does.
As User Stories in the Product Backlog often evolve as there are iterative planning sessions, (Agile Planning) it would be great if there was a wiki style editing of cases as opposed to a thread of descriptions.
There is talk that the next major version will be more supportive of Agile processes so am very much looking forward to seeing that this offers.
Edit: FogBugz 7 is now out with much better management of Product "Project" Backlogs. Take a look!
我问了 FogBugz 的人同样的问题，因为例如在 XP 中你会提供 IET（理想工程时间）的估计。 他们的答案是与您提供估算的方式保持一致。
I asked the FogBugz guys the same thing because in XP for example you'd provide the estimate in IET (ideal engineering time). Their answer was to be consistent in the way you provide the estimate.
Here are some suggestions for including Story Points in your planning:
When you enter your Story into FB7 you can do it as a Case and include the number of Story Points from Planning Poker in a new custom field that you create called "Story Points" (how to do this below). Then, when you get around to working on that Story, you can break it down further into Sub-Cases, if necessary, and also enter the estimated time to complete each Sub-Case (the estimated times will add up in the Story (top) Case's "Estimate" field, as well as feed Evidence Based Scheduling / Burndown Charts)
Here are two things to consider modifying in your FogBugz installation to reflect your Agile nomenclature.
(1) Out of the box, the FB Category "Feature" is most like your "Story." But you can change your Category names, and add new ones at Admin > Workflow > Customize Categories. Here's additional information on this:
(2) To capture Story Points, you'll probably want to create a Custom Field in the Case dialogue. This is accomplished with the included Custom Fields Plugin. Additional information on this is available at isl=174461
Note that with Custom Fields, you can also add a text edit box for the Story which will always appear in the Case dialogue header (no matter how lengthy the case activity history below it gets.)
发布评论
评论（4）
正如 eed3si9n 所说，如果你保持一致在您对 EBS 的估计中，FogBugz 将为您处理这个问题。
至于更一般的情况，FogBugz 如何适应敏捷方法，最好的选择是将冲刺作为迷你版本进行。 创建冲刺并将您想要在该冲刺中实现的案例添加到该版本（或里程碑）。 如果您进行为期一周的冲刺，请给它一个结束日期，比如一周后。 然后 EBS 可以跟踪它并告诉您是否按计划进行。
报告部分中的图表还将向您显示燃尽图。 术语有点不同，因为 FogBugz 不只是敏捷，但信息在那里。
您想了解完成冲刺的预期时间是保持稳定还是向前推进。 如果它稳定，那么你就步入正轨，并且你的燃尽率也达到了目标。 如果它正在缓慢上升，那么你就会节节败退，你的冲刺就会被推迟。 是时候将事情移至下一个冲刺或找出为什么你搞砸了你的估计:)
本质上我认为这是一个燃尽图而不是燃尽图，但它为你提供了对同一问题的相同答案。 我能按时完成吗？ 我还要做什么呢？
Atalasoft 的 Lou Franco 就此撰写了一篇出色的文章：出色地。 Patrick Altman 也有一篇文章。
更新：修复了 Altman 文章的链接
As eed3si9n said, if you are consistent in your estimates for EBS, FogBugz will take care of this for you.
As to the more general, how does FogBugz fit with the Agile methodology, your best bet is to do sprints as mini-releases. Create a sprint and add the cases you want to achieve for that sprint to that release (or milestone). Give it an end date, say a week away, if you do week long sprints. Then EBS can track it and tell you if you are on schedule.
The graphs in the Reports section will also show you a burndown chart. The terminology is a bit different because FogBugz isn't Agile-only but the info is there.
You want to see if the expected time you are going to finish your sprint is staying steady or going forward. If it is steady you are on track and your burndown rate is on target. If it is creeping up, you are losing ground and your sprint is getting delayed. Time to move things to the next sprint or figure out why you messed up your estimates :)
Essentially I suppose this is a burn-up chart instead of a burndown chart, but it gives you the same answer to the same question. Am I going to finish on time? What do I have left to do?
Atalasoft's Lou Franco wrote an excellent post on this as well. Patrick Altman also has an article.
Update: fixed link to Altman's article
我们开始使用 FogBugz 来处理我们技术团队中的几乎所有事务：文档、错误报告、管理任务。 随着时间的推移，我们逐渐变得更加敏捷。
我所做的是创建一个称为“产品待办事项列表”的版本，并给出未来的任意发布日期。 我将 FogBugz 字段“版本”更改为“优先级”，以便我们可以按优先级排序。 为了管理产品待办事项，我大量使用区域来对用户故事进行分类。 区域可以是主题或史诗。 每个迭代都是 FogBugz 中的一个版本。
现在，我们最近开始使用的一件事是故事点，而不是理想任务天来估计我们的产品待办事项列表。 FogBugz 不理解故事点的计量单位，因此相当令人困惑的是，我们的产品待办事项列表中的 1 SP 在 FogBugz 中被报告为 1 天。 如果有任何混乱，这可能会很危险。 但我们的团队很小。 我不使用 FogBugz 中内置的报告工具，但如果可以的话那就太好了。
因此，我所有的故事点和速度计算都是在 Excel 中的 FogBugz 之外完成的。 目前看来这还好。 我们使用用户故事索引卡和便利贴作为办公室板上的任务来跟踪任务。 看看 Kniberg 的《Scrum and XP from the Trenches》一书，它影响了我的决定。 实际上，拥有一块大板，上面有我们早上 Scrums 所关注的所有内容，这确实很有帮助。
我确实认为 FogBugz 中的历史估计历史和报告非常出色。 这适用于计划扑克世界吗？ 我想至少从团队的估计历史来看确实如此。
由于产品待办事项列表中的用户故事经常随着迭代规划会议的进行而演变，（敏捷规划）如果有 wiki 风格的案例编辑而不是一系列的描述，那就太好了。
有传言称下一个主要版本将更加支持敏捷流程，因此我非常期待看到这一点。
编辑：
FogBugz 7 现已推出，可以更好地管理产品“项目”待办事项。 看一看！
http://www.fogcreek.com/FogBugz/blog/ post/Scrum-Friendly-Features.aspx
We started using FogBugz for pretty much everything within our technical team: Documentation, bug reporting, managing tasks. We have progressively got more Agile as time has gone on.
What I have done is created a release which is called the Product Backlog, and this is given an arbitrary release date in the future. I changed the FogBugz field "Version" to "Priority" so we can sort by priority. To manage the product backlog I heavily use Areas to categorise the user stories. Areas could be Themes or Epics. Each Iteration is a Release in FogBugz.
Now, one thing we have recently started using is Story Points as opposed to Ideal Task Days for estimating our Product Backlog. FogBugz doesn't understand a unit of measurement of Story Points so rather confusingly, 1 SP in our Product Backlog is reported as 1 Day in FogBugz. This could be dangerous if there is any confusion. But our team is small. I don't use the in built reporting tools in FogBugz, but it would be great if I could.
So, all my Story Point and Velocity calculations are done outside of FogBugz in Excel. This seems to be fine for now. We're tracking tasks using index cards for user stories and post-it notes as tasks on our boards in the office. Have a look at the book "Scrum and XP from the Trenches" book by Kniberg which influenced my decision. Actually having a big board with everything on it which we are staring at in our morning Scrums really helps.
I do think the historical estimation history and reporting in FogBugz is excellent. Does this work with the planning poker world? I suppose at least from a team's estimation history it does.
As User Stories in the Product Backlog often evolve as there are iterative planning sessions, (Agile Planning) it would be great if there was a wiki style editing of cases as opposed to a thread of descriptions.
There is talk that the next major version will be more supportive of Agile processes so am very much looking forward to seeing that this offers.
Edit:
FogBugz 7 is now out with much better management of Product "Project" Backlogs. Take a look!
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx
我问了 FogBugz 的人同样的问题，因为例如在 XP 中你会提供 IET（理想工程时间）的估计。 他们的答案是与您提供估算的方式保持一致。
I asked the FogBugz guys the same thing because in XP for example you'd provide the estimate in IET (ideal engineering time). Their answer was to be consistent in the way you provide the estimate.
以下是在您的规划中包含故事点的一些建议：
当您将故事输入 FB7 时，您可以将其作为案例进行，并将规划扑克中的故事点数量包含在您创建的名为“故事点”的新自定义字段中（如何做到这一点如下）。 然后，当您开始处理该故事时，如有必要，您可以将其进一步分解为子案例，并输入完成每个子案例的估计时间（估计时间将在故事中相加（顶部）案例的“估计”字段，以及提供基于证据的调度/燃尽图）
这里有两件事需要考虑在您的 FogBugz 安装中进行修改，以反映您的敏捷术语。
(1) 开箱即用，FB 类别“功能”最像您的“故事”。 但您可以更改类别名称，并在“管理”>“添加新类别”中添加新类别名称。 工作流程>> 自定义类别。 以下是有关此内容的其他信息：
http:// www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457
(2) 要捕获故事点，您可能需要在案例对话框中创建自定义字段。 这是通过附带的自定义字段插件来完成的。 有关此内容的更多信息，请访问 isl=174461
请注意，使用自定义字段，您还可以为故事添加文本编辑框，该文本编辑框将始终显示在案例对话标题中（无论其下方的案例活动历史记录有多长）。
Here are some suggestions for including Story Points in your planning:
When you enter your Story into FB7 you can do it as a Case and include the number of Story Points from Planning Poker in a new custom field that you create called "Story Points" (how to do this below). Then, when you get around to working on that Story, you can break it down further into Sub-Cases, if necessary, and also enter the estimated time to complete each Sub-Case (the estimated times will add up in the Story (top) Case's "Estimate" field, as well as feed Evidence Based Scheduling / Burndown Charts)
Here are two things to consider modifying in your FogBugz installation to reflect your Agile nomenclature.
(1) Out of the box, the FB Category "Feature" is most like your "Story." But you can change your Category names, and add new ones at Admin > Workflow > Customize Categories. Here's additional information on this:
http://www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457
(2) To capture Story Points, you'll probably want to create a Custom Field in the Case dialogue. This is accomplished with the included Custom Fields Plugin. Additional information on this is available at isl=174461
Note that with Custom Fields, you can also add a text edit box for the Story which will always appear in the Case dialogue header (no matter how lengthy the case activity history below it gets.)