我目前的团队（从事各种商业智能软件项目），我们最近开始采用经典“敏捷”项目规划和估算的变体 - 到目前为止，每个人似乎都对此非常满意，包括我们（不同经验水平的开发人员），产品经理（技术含量高的人，通常也有一些开发经验，但主要对业务方面感兴趣），管理人员（在我们报告的水平上相当技术，但也较少- 技术性更强的董事和副总裁）和其他利益相关者（我们软件的用户和潜在用户）。但是，当然，这是早期的，我们会随着时间的推移进行调整。 （在过去的几年里，我在非常不同的应用领域中使用了它的其他变体，例如集群管理软件；但我也经常使用更多的临时、更少结构化的方法。
大纲如下。在每次迭代中（我们目前处于 2 周的迭代周期），PM 选择一些他们可能希望从我们所在地区的项目中获得的“基本业务价值单元”——一个典型的单元将是一个特性，一个 bug修复，一些优化方面等。在与技术主管和一两个高级工程师的小型会议中，每个单元被分解为工程任务（并确定任务之间的依赖关系）。在更大的全团队会议中，每个任务的相对“成本”（相对于其他任务执行该任务大约需要多少时间）被集体评估（我们使用我们称之为的完全抽象的工作单位“点”，尽管我见过其他团队使用较少抽象的单位，例如“理想工程日”）。评估的成本包括单元测试和技术文档。
这些任务，每个都有其评估成本，继续进行所谓的团队“积压”任务，以及“内部重组”任务（通常是重构不会带来新的用户可观察到的加分，但将 使进一步的开发和维护更有成效），还包括评估成本和预期收益的总结（必须以 PM 可以理解的方式表达——幸运的是，正如我所说，我们是高技术人员）。根据工程团队的共识，重构也可能被视为某些业务请求任务的先决条件（例如，“在组件 X 上进一步工作没有意义，直到 Y 类太大，被正确拆分，这将需要 N 分”） .
PM 现在可以根据完成这些任务所组成的单元将交付的业务价值，以他们喜欢的任何方式对积压中的任务进行排序，但要受到依赖关系的限制。根据过去的结果，他们很清楚团队在 2 周的迭代中可以完成多少“点”（我们的“速度”），因此他们试图确保最终可以执行一些具有业务价值的发布迭代（而不是让许多具有商业价值的东西“在飞行中”......但还没有完成并交付给利益相关者！-）。
然后，团队将大约 80% 的时间和精力用于处理 PM 设计的最优先任务（包括有时结对编程、特别紧急的任务或团队成员需要学习的情况）更多关于某些技术或代码库的某些部分的信息，以及另一位在这些方面的专家的团队成员可以与他们配对一段时间）。优先级顺序是一个重要的指标，但它并不完全严格（例如，如果首要任务需要 Java 中的大量工作，而第二个任务需要 Python 中的大量工作，我可能会选择第二个，因为我的相对生产力会大大提高那样——对于 Java 大师等团队成员来说，反之亦然）。
“优先级 0”又名“红色代码”问题可能随时出现，如果出现，根据定义，它们将优先于任何其他任务（并且仅在计划中追溯考虑，以确保速度被正确评估）。但是，由于我们在测试、发布工程和其他质量保证实践方面做得很好，幸运的是，这些紧急情况很少发生。
加上工程师花费时间的其他“强制性”方式（培训课程、全体会议、季度绩效自我评估和同行评审等），应该占工程师时间的 80% 左右-- 剩下的 20% 是每个工程师应该致力于“完全不同的事情”（“蓝天”探索项目、“工程社区”工作、开源贡献等），与手。没有人真正精确地测量时间，但这仍然是一个有用的指导方针（我一直在想办法让测量变得容易和无痛，我可以在 20% 的时间里实施，以帮助我更精确地分配时间和精力，但我没有实际上还没有得到任何轮训；-)。