Sprint规划历来基于一个默认前提：产能等于人数乘以时间盒。你估算工作量，与团队上一周期完成的情况对比，然后承诺一个合适的范围。

当AI编码Agent加入团队后，这个等式就不再成立。Agent可以在任务就绪的瞬间认领它，与其他所有Agent并行工作，并在你计划讨论它的站会之前就带着diff和测试结果回来。执行产能急剧膨胀。诱人的回应是承诺更多范围，而这样做的团队通常会在第一个周期结束时发现失败模式：Sprint结束时堆满了完成的代码和一堵未经评审的变更墙，没有人有时间去验收。

这就是本文要论证的核心观点：当Agent加入团队后，执行不再是Sprint的约束条件，人工评审才是Sprint的约束条件。围绕验收吞吐量来规划，而不是围绕能产出多少代码来规划。我们将以HiFox中的Sprint作为具体机制，同时将规划论证与产品事实清晰区分开来。

TL;DR

HiFox中的Sprint是一个由单个Space拥有的、时间盒限定的任务集合；任务仍然是执行和讨论的源头，而Sprint在此基础上增加了日程、范围和报告。Sprint是可选的，运行在两种模式之一：自动节奏模式，由HiFox维护日程并自动结转未完成工作；或手动模式，由人员显式创建、启动和完成Sprint。报告涵盖范围、已启动和已完成的工作、完成率、产能和燃尽历史。对于混合人机团队，规划上的转变是：Agent膨胀了执行产能，但验收仍然由人员承担，因此诚实的Sprint承诺受限于评审者能验收多少已完成工作，而不是Agent能产出多少。

HiFox中的Sprint是什么

Sprint是一个由单个Space拥有的、时间盒限定的任务集合。它帮助团队规划聚焦的范围、跟踪进度，并决定时间盒结束时未完成工作的去向。任务仍然是执行和讨论的源头；Sprint在其之上增加了日程、范围和报告。

文档使用Sprint这个术语，其含义与行业标准一致。Scrum指南将Sprint描述为想法转化为价值的固定时长容器，HiFox的版本延续了这一脉络。HiFox改变的是在时间窗口内执行的主体。

三个边界保持了概念的清晰性：

• 一个Sprint恰好属于一个Space。将任务放入Sprint不会改变其归属。
• Sprint是可选的，按Space启用。偏好持续流的Space可以完全不开启。
• Sprint不是Project也不是View。当问题是"在特定时间盒内应完成什么"时使用Sprint。对于可能跨越多个Sprint或Space的成果使用Project。对于保存的任务检视方式使用View。

最后一个区分在混合团队中发挥着实际作用：Project承载成果，Sprint承载近期承诺，View承载每个人日常需要的各种切片。

自动节奏或手动模式

当你为Space启用Sprint时，需要选择两种生命周期模式之一。这个选择改变的是生命周期行为，而非任务归属。

自动节奏将日历交给HiFox管理。你配置Sprint时长、可选冷却期、开始星期几、维护多少个未来Sprint、时区，以及当任务进入选定状态类别时自动添加任务的规则。HiFox随后创建未来的Sprint，按计划启动和完成它们，并自动结转未完成的工作。提前启动即将到来的Sprint会先完成当前Sprint，并将其未完成工作滚动到正在启动的Sprint中。

手动模式将生命周期控制权留给团队。人员在需要时创建计划的Sprint，启动时无需更改配置的日期，可以并行运行多个活跃Sprint，并在完成时选择未完成任务的去向。自动创建、结转、冷却和基于状态添加规则在手动模式下保持不活跃。

	自动节奏	手动模式
日程	HiFox按配置的节奏创建、启动和完成Sprint	人员显式创建、启动和完成Sprint
未完成工作	自动滚动到下一个Sprint	完成时路由：无Sprint、另一个Sprint或新建一个
并行活跃Sprint	每个节奏一个当前Sprint	允许多个活跃Sprint
任务流入	状态类别规则可在窗口期间添加任务	人员通过规划、列表或Sprint字段添加任务
最适合	团队希望无需仪式即可维持的稳定节奏	不规则周期、发布驱动窗口或重叠工作

诚实的决策配对：当团队运行稳定节奏并希望机制被自动维护时，使用自动节奏。当周期不规则、由发布而非日历定义窗口、或需要同时运行两个活跃Sprint时，使用手动模式。切换到手动模式会保留现有Sprint但停止自动调度。完全禁用Sprint会完成活跃的Sprint、移除未来的Sprint，并保留已完成数据用于报告。

任务如何进入、离开和跳过Sprint

Sprint显示五种状态：当前、即将到来、已计划、已完成和已取消。已完成和已取消的Sprint移至Space归档，而不是杂乱地堆在活跃规划列表中。

你可以通过任务的Sprint字段、任务列表或Sprint规划期间添加或移动任务。两条规则比看起来更重要。

第一，任务可以完全没有Sprint。这是Backlog工作和未承诺到任何时间盒的任务的正常归属。

第二，将任务添加到Sprint不会改变其状态。这是混合团队需要内化的规则，因为在HiFox中，Backlog状态类别是一个停放状态：当任务处于Backlog时创建任务或分配Agent不会启动执行。将任务移出Backlog进入就绪状态才是启动已分配Agent的触发条件。因此Sprint规划和执行发布是两个独立的杠杆。你可以在周一规划整个Sprint，Agent已经分配好，但在每个任务被有意移动到就绪状态之前，什么都不会运行。状态变更自动化随后可以接管你想要标准化的转换。

另一条规则保护你的历史记录：只有已完成的任务才能添加到过去的Sprint中。这允许历史修正，而不会将未完成的工作放入已关闭的时间段。

关于日期，计划中Sprint的开始和结束时间都可编辑，而活跃Sprint的开始时间固定但结束时间可以更改。

Sprint报告告诉你什么

Sprint报告包括任务计数，以及当Space启用了估算时，六个维度的估算点总数：范围、已启动工作、已完成工作、完成率、产能和燃尽历史。

产能值得仔细关注，因为它是规划对话锚定的数字。HiFox在有足够历史时从最近完成的Sprint速度中推导产能，否则回退到基于Space规模的估算。文档建议将其视为规划输入而非保证，对混合团队来说这个警告并非套话：在纯人工团队上测量的速度，在你添加三个Agent的那一周就不再具有预测力。燃尽历史往往更具揭示性。如果范围在早期爆发式完成然后曲线趋于平缓，说明你的Agent完成了执行，而评审者花了Sprint剩余时间追赶进度。

混合团队的约束：为评审规划，而非为执行规划

本节所有内容都是规划论证，而非产品功能。HiFox提供了上述Sprint机制；如何加载Sprint是一个判断问题。

从分工出发。Agent负责研究、执行、测试和报告。人员负责设定方向、授予权限和验收结果。在Agentic编码中，方向设定和验收之间的一切都可以委派，但验收仍然由人类完成。一个Agent完成了一项任务，并不意味着在Sprint应该计数的任何意义上完成了：diff、验证结果和已知限制返回到任务中，仍然需要一个人来阅读并验收、请求修改或决定合并。

现在做算术。假设一个五人团队添加Agent后执行吞吐量翻了三倍。评审吞吐量没有翻三倍；仍然由同样的五个人承担，每次验收变更都需要真实的注意力投入。按执行产能规划Sprint，盈余不会变成交付价值。它变成了一队列未经评审的工作，而未经评审的变更是库存，不是进展。更糟糕的是，即将结束的Sprint会推动评审者走向恰恰使Agent密集型开发变得危险的那条捷径：不阅读就验收输出。

所以反转规划问题。不要问团队两周能执行多少工作，而要问你的人员两周能验收多少Agent完成的成品工作。在实践中，这改变了四个习惯：

1. 估算评审成本，而不仅仅是构建成本。 对Agent来说执行微不足道的任务，验收起来可能代价高昂。
2. 限制并发已完成但未验收的工作量。 决定每个评审者每个Sprint真正能验收多少任务，规划不要超过这个总和。这是一个工作协议而非HiFox设置，但完成指标会告诉你何时超了。
3. 有意识地释放执行。 因为Backlog停放执行，你可以错开启动时间，使成品工作以评审者能吸收的节奏到达，而不是在第二天全部涌来。
4. 将完成率解读为评审数字。 当燃尽曲线趋于平缓而Agent闲置时，约束条件已经自我宣告。这是增加评审者或减少承诺的信号，而不是增加Agent的信号。

这些都不会拖慢Agent的速度。它们让Agent更有方向。围绕验收吞吐量规划的Sprint会交付所有承诺的内容，并且永远不会要求一个人批准他们没有时间阅读的代码。

逐步规划混合Sprint

1. 为Space启用Sprint并选择模式。 稳定的团队节奏建议自动节奏；发布驱动的工作建议手动模式。
2. 塑造范围。 通过Sprint规划或Sprint字段将候选任务拉入即将到来的Sprint。将未承诺的工作保留为无Sprint状态。
3. 为每个任务分配两个角色。 HiFox将人类责任与Agent执行分开：人员进入Assignee集合，Agent或Crew进入单一执行槽位。更改一个不会影响另一个。
4. 编写Agent可以执行的任务。 描述应包含新人员或Agent继续推进所需的目标、约束和验收标准。
5. 按评审节奏释放工作。 随着评审者容量释放，将任务移出Backlog。
6. 有意图地关闭。 在手动模式下，选择每个未完成任务的去向。在自动节奏下，检查结转了什么，并询问是范围定得太大还是评审太慢。

以这种方式运行工作的更广泛纪律涵盖在我们的AI Agent项目管理支柱文章中；Sprint是该系统的时间盒切片。

如果你的Sprint目前在Jira中

你不必重建流程来尝试这些。HiFox的Jira集成可以导入Jira Sprint数据，当启用Sprint导入时，目标Space可以切换到Jira Sprint模式，因此团队已有的节奏可以迁移过来，而不是从零开始。将Jira工单分配给AI Agent的演练在单个工单层面展示了同样的思路，HiFox文档深入介绍了Sprint配置和Jira集成。

从比迁移更小的步骤开始：在一个Space中启用Sprint，根据评审者真实的验收容量规划一个两周窗口，并将燃尽曲线与你上一个纯人工周期进行比较。