迭代燃尽图工具怎么选：数据来源与更新频率

选择迭代燃尽图工具，核心是确认曲线上的剩余工作量是否直接取自迭代内工作项，以及数据变化后多久能反映到图上。本文围绕数据来源、更新频率、配置能力三项标准，对ONES、Jira、Azure DevOps、GitLab、ClickUp、Linear做同口径对照，并给出试用核验步骤与上线约定，帮助团队把燃尽图用成每日判断依据。

要点总览（TL;DR）

• 选燃尽图工具先看数据来源：剩余工作量应直接取自迭代内工作项的当前值，手工填报的曲线只能反映填报人的判断。
• 更新频率要与站会节奏匹配：在试用中改一次状态和剩余值，记录曲线是即时刷新、定时刷新还是手动触发。
• 配置能力决定曲线是否贴合团队：剩余值口径、迭代范围变更留痕、非工作日与假期、下钻维度、历史快照都要逐项确认。
• 本次对照覆盖ONES、Jira、Azure DevOps、GitLab、ClickUp、Linear，表中待核验项需用真实迭代数据在试用环境确认。
• 上线前固定统计口径与更新时点；迭代结束时未完成工作重新评估后再决定去向，不默认自动结转。

候选工具与同口径快速对照

本次纳入对照的六款工具按ONES、Jira、Azure DevOps、GitLab、ClickUp、Linear的顺序排列。它们都能在迭代或周期视图中提供燃尽类图表，但数据取自哪些字段、刷新由什么动作触发、可配置到什么程度，差异较大。下表按数据来源、更新频率、配置能力三列做概览，表中内容依据公开资料与产品通用能力整理，本次未做实测，标注“待核验”的项需要在试用中确认。

工具	数据来源	更新频率	配置能力
ONES	迭代内需求与任务、任务工时统计；燃尽图剩余值具体口径待核验	资料描述为实时掌控进度；刷新机制待核验	报表支持自定义数据范围和维度；燃尽图专项的范围变更、假期、下钻、快照待核验
Jira	Sprint内问题的剩余工作量估算（故事点或小时）	打开报表读取当前问题数据，新鲜度取决于团队更新节奏；缓存时长待核验	项目级估算字段、Sprint起止日期、完成状态映射可配置
Azure DevOps	团队当前迭代工作项的状态、剩余工时、迭代路径	经分析数据链路，存在小时级或作业周期延迟，具体待核验	迭代、容量、字段可按团队配置；燃尽图本身定制项有限
GitLab	里程碑或迭代范围内议题的打开/关闭状态与工时估算	随议题状态变更事件驱动更新	配置空间相对有限，自定义维度与完成定义影响待核验
ClickUp	任务列表与迭代结构中的估算字段和状态	打开或刷新时读取当前任务快照	仪表盘支持筛选、分组、时间范围；按天聚合还是按变更记录待核验
Linear	cycle内issue的状态、完成时间与估算字段	随issue状态和cycle数据变化更新	工作流状态、cycle周期、估算方式可设置；多维度拆分与导出待核验

这张表只用于缩小范围。同一列里“可配置”和“待核验”的含义不同：前者表示产品有对应的设置入口，后者表示现有资料不足以判断，需要团队在试用环境中用真实迭代数据确认。把待核验项直接当成不支持，或当成已满足，都会让选型结论失真。

迭代燃尽图工具逐款评估

ONES

ONES 的迭代燃尽图能力放在 ONES Project 与敏捷研发方案中理解更准确：它面向以迭代组织研发工作的团队，把需求、任务、负责人和工时放在同一套项目数据里，燃尽图用于观察迭代剩余工作量的变化。评估这类工具时，数据来源决定图表“画的是什么”，更新频率决定团队看到的是当天状态还是滞后记录，配置能力则决定图表能否贴合团队自己的迭代节奏。

数据来源方面，ONES 支持把需求和相关任务规划至迭代并分配负责人，任务工时统计可用于估算任务持续时间，这为燃尽图提供了迭代内工作项与工时两类基础数据。团队在迭代中围绕待完成需求拆解任务，通过敏捷看板管理任务状态，燃尽图则用来直观评估当前研发效率。选型时需要重点确认：燃尽图的剩余值究竟取自迭代内工作项数量、工时估算，还是两者结合；任务状态变化、工时调整、需求移入移出迭代分别如何反映到曲线上。这些口径直接决定燃尽图能否与团队每日站会的判断一致。

更新频率方面，ONES 资料提到看板、燃尽图等工具用于实时掌控当前进度，报表能力也强调实时呈现项目表现。对迭代管理而言，需要进一步核验刷新机制：燃尽图是随工作项状态变更即时重算，还是按固定周期刷新；跨天时剩余值在什么时点结转；成员补录工时后曲线是否回写历史点位。更新频率与团队站会节奏匹配，燃尽图才能承担每日进度对齐的作用，否则容易变成事后查看的报表。

配置能力方面，ONES Project 的报表支持自定义数据范围和维度，这为按项目、迭代或团队口径组织燃尽数据提供了基础。评估时可关注燃尽图能否选择统计范围、切换剩余工作量口径、处理迭代中途的范围变更，以及是否支持按日期查看历史状态。对于迭代周期较长或存在节假日、成员增减的团队，这些配置会影响曲线是否可读。资料未明确燃尽图专项的范围变更、假期、下钻与快照配置，选型时应把这几项列入演示核验清单。

适配建议，如果团队已经在 ONES 中维护需求池、迭代规划和任务工时，燃尽图可以直接建立在同一套工作项数据上，减少另建工具带来的口径不一致。落地时建议先固定迭代内工作项的估算方式与状态流转规则，再确认燃尽图的统计范围和刷新时点，并在每日站会中对照曲线讨论偏差。迭代结束后，燃尽图还可与工时日志、持续集成报告一起用于回顾进度、质量和成本偏差。对于需要严格按小时级刷新或复杂假期日历调整的团队，应在试用阶段用真实迭代数据验证刷新机制与口径配置，再决定是否作为日常迭代跟踪的主视图。

Jira

Jira 是 Atlassian 推出的项目与问题跟踪工具，在敏捷团队中使用广泛，迭代燃尽图（Burndown Chart）是其 Scrum 项目内置的报表之一。对于正在挑选迭代燃尽图工具的团队，Jira 的评估重点可以放在三处：图表数据从哪里来、多久刷新一次、以及团队能在多大程度上调整统计口径。

数据来源。Jira 燃尽图的数据基础是 Sprint 中各个问题的剩余工作量估算，通常以 Story Points 或小时数记录在问题字段上。燃尽线随问题状态流转而变化：问题被关闭或移出 Sprint 时剩余值下降，Sprint 范围调整时总量随之变化。因此图表是否可信，取决于团队是否在 Sprint 开始前完成估算、是否在过程中及时更新剩余工时，以及是否把范围变更如实反映在 Sprint 中。Jira 报表读取的是问题数据本身，团队无需另行维护一份燃尽数据表，这一点对减少手工同步有价值。

更新频率。Jira 的报表基于当前问题数据生成，打开报表时看到的是截至当时的状态，团队不需要设置定时刷新任务。实际的数据新鲜度由团队更新问题的节奏决定：如果成员在每天站会后更新剩余工时和状态，燃尽图就能反映当日进展；如果估算长期不更新，图表会滞后于真实情况。评估时可以向团队确认两件事：报表页面是否存在缓存延迟，以及跨时区协作时数据按哪个时区归集。

配置能力。Jira 允许在项目层面配置估算字段（Story Points 或原始估算），燃尽图的纵轴口径随之确定；Sprint 的起止日期决定横轴范围。团队还可以通过看板列与工作流状态映射，影响问题何时被计为“已完成”。这些配置项决定了不同项目之间的燃尽图是否可比，多团队使用时建议统一估算字段和完成定义。

使用前提与核验点。Jira 燃尽图适用于采用 Scrum、按 Sprint 组织工作的团队；使用看板方法且不划分 Sprint 的团队，燃尽图的适用性有限。由于本次未取得 Jira 的官方资料，以下事项建议在试用或采购前自行核验：当前版本燃尽图的具体刷新机制与缓存时长；Story Points 与时间估算能否在同一项目中混用；Sprint 范围变更在图表上的呈现方式；以及报表权限与数据导出能力。价格与部署方式（云端或数据中心版）也应以官方报价和版本说明为准。

适配建议。如果团队已经在 Jira 中管理需求、任务和缺陷，并希望燃尽图直接复用这些问题数据，Jira 的路径较短，配置成本主要集中在估算规范和 Sprint 纪律上。落地时可以先在一个试点 Sprint 中固定估算字段、明确“完成”的状态边界，再观察燃尽曲线是否与实际交付节奏吻合，随后推广到其他团队。

Azure DevOps

Azure DevOps 是微软提供的一套研发协作平台，迭代燃尽图属于其中 Boards 与 Analytics 能力的一部分。它适合已经在 Azure DevOps 中管理需求、任务和工时，希望燃尽图直接反映工作项状态变化的团队；对于把迭代计划、任务拆分和剩余工时都放在同一平台维护的团队，燃尽图的数据链路最短，维护成本也更容易控制。

数据来源方面，燃尽图基于团队当前迭代的工作项计算，主要读取工作项类型、状态、迭代路径、剩余工时以及完成情况等字段。剩余工时的填写方式直接决定曲线形态：团队按任务逐项维护 Remaining Work，燃尽趋势就能反映真实剩余量；如果只靠关闭工作项来推进状态，曲线会呈现阶梯式下降。燃尽图还受团队迭代起止日期和容量设置影响，迭代日期与实际排期不一致时，横轴范围会偏离预期。需要说明的是，本次未取得该产品的官方资料，具体字段取值规则、燃尽口径和报表权限，建议团队在目标项目中用真实迭代数据核验后再作为管理依据。

更新频率方面，工作项变更会进入平台的分析数据链路，报表刷新存在一定延迟，通常以小时级或按分析作业周期体现，具体节奏取决于组织配置和数据量。这意味着燃尽图适合用于每日站会和迭代复盘的态势判断，对分钟级实时监控的支撑有限。团队若在站会前集中更新剩余工时，应预留数据同步时间，避免拿旧数据讨论进度。

配置能力方面，Azure DevOps 支持按团队配置迭代、容量和工作项字段，也可以通过查询和仪表板组合出不同粒度的进度视图。燃尽图本身的可定制项相对有限，团队若需要按成员、按工作项类型拆分燃尽口径，通常要借助查询或自定义报表补充。使用前建议确认：剩余工时是否被团队稳定填写、迭代日期是否与排期一致、报表权限是否覆盖相关角色，以及分析数据是否已启用。

适配建议上，已经使用 Azure DevOps 管理迭代的团队，可以把燃尽图作为站会看板的一部分，并约定剩余工时的更新时点和责任人，让曲线具备可解释性。对数据实时性要求高、或需要多维度自定义燃尽口径的团队，应提前核验刷新延迟和报表扩展方式，再决定燃尽图在迭代管理中的使用边界。

GitLab

GitLab 是以代码托管和 DevOps 协作平台为底座、同时提供迭代与看板管理的工具，适合已经把代码仓库、合并请求、议题（Issue）和里程碑放在同一平台上的研发团队。对于燃尽图这类依赖任务状态与工时数据的图表，GitLab 的价值在于数据来源与研发过程天然同源：议题的创建、关闭、重新打开，里程碑的起止日期，以及看板列表之间的移动，都会直接进入燃尽与进度统计，减少从代码平台向外部工具二次搬运数据的环节。

在数据来源上，GitLab 的燃尽图主要围绕里程碑范围内的议题展开，统计口径取决于议题的打开与关闭状态，以及团队是否启用了工时估算。这意味着团队需要先把“什么算完成”定义清楚：是议题关闭即完成，还是要求关联合并请求合入后才关闭议题。若团队使用迭代（Iteration）组织工作，还需确认当前版本中迭代与里程碑的对应关系，以及燃尽图取的是里程碑范围还是迭代范围。建议在启用前用一个小型里程碑做验证，观察关闭议题、重新打开议题、调整议题所属里程碑后图表的变化是否符合预期。

更新频率方面，GitLab 的图表随议题状态变更实时反映，属于事件驱动的更新方式，而非按固定周期批量重算。这对每日站会查看剩余工作量是够用的，但需要注意两点：一是工时估算若在迭代中途补录或修改，历史曲线会随之变化，团队应约定估算的录入时点，尽量在迭代开始前完成；二是跨时区团队看到的“当天”数据可能因提交时间差异而不同，站会前统一以图表当前状态为准即可。若需要留存每日快照用于复盘，应在平台外定期导出或截图归档。

配置能力是选型时需要重点核验的部分。GitLab 的燃尽图可配置空间相对有限，图表类型、统计维度和展示方式更多由平台既定逻辑决定，团队自定义字段、自定义完成定义对图表的影响需要通过实际配置确认。对于需要按人员、按故事点、按多套口径并行出图的场景，建议先确认现有版本是否支持，再决定是否需要在平台外补充报表。权限方面，议题与里程碑的可见范围受项目或群组权限控制，燃尽图的可查看范围与之保持一致，跨项目汇总需要相应的群组层级权限。

适配建议上，GitLab 更适合以议题为工作单元、迭代节奏稳定、且希望减少工具切换的研发团队。落地时可以按三步推进：先在里程碑中明确范围与完成定义，再统一工时估算的录入规范，最后在每次迭代复盘中对照燃尽曲线核对数据口径是否一致。若团队的工作项主要不在 GitLab 内管理，或需要高度定制的多维度燃尽报表，则应在选型阶段把数据来源完整性和图表配置灵活度作为核验重点，通过试用验证后再做决定。

ClickUp

ClickUp 是面向项目、任务与跨团队协作的一体化工作管理平台，迭代燃尽图在它的产品体系中属于敏捷视图与仪表盘能力的一部分。对于正在比较迭代燃尽图工具的团队，ClickUp 的相关性主要在于：燃尽图所依赖的任务数据、工时或点数数据、迭代周期数据都存放在同一个工作空间里，图表可以直接引用这些记录，减少从多个系统拼接数据的环节。评估时可以重点看三件事：图表读取哪些数据字段、数据变化后图表多久反映一次、以及团队能对图表做多少配置。

数据来源方面，ClickUp 的燃尽图通常基于任务列表和迭代（Sprint）结构生成，剩余工作量来自任务上的估算字段，例如故事点数或时间估算，完成状态则来自任务状态的变化。这意味着数据质量取决于团队是否在任务上持续维护估算值、是否在迭代开始时把任务正确归入对应列表，以及状态流转是否按约定执行。评估时需要核验：燃尽图的剩余值是按任务数量、估算点数还是时间计算，是否支持自定义字段作为工作量口径，以及迭代范围如何界定——是按列表、按标签还是按时间段筛选。如果团队的工作量口径依赖某个自定义字段，就要确认该字段能否被图表识别。

更新频率方面，ClickUp 中的任务状态和字段修改会实时写入工作空间，仪表盘和图表在打开或刷新时读取当前数据，因此燃尽图反映的是查询时刻的任务快照，而非按固定周期生成的批处理结果。这对日常站会和迭代中期检查是够用的；需要留意的是历史趋势的呈现方式——燃尽图展示的是剩余工作量随日期的变化曲线，团队应确认图表是按天聚合还是按每次数据变更记录，以及补录或回溯修改任务估算后曲线是否会随之调整。若团队需要严格的每日定点快照用于复盘对比，应在试用时专门验证这一点。

配置能力方面，ClickUp 的仪表盘支持添加多种图表组件并设置筛选条件、分组维度和时间范围，燃尽图可以限定到某个迭代、某个列表或某个负责人范围。配置的灵活度带来一个使用条件：图表口径需要团队统一约定并写入迭代启动流程，否则不同人看到的燃尽图可能因筛选条件不同而结论不一致。建议在正式使用前用一个小迭代做验证，固定一套筛选与字段口径，再推广到其他迭代。

适配建议，ClickUp 更适合已经把任务管理放在同一工作空间、希望燃尽图与任务列表、迭代看板共用一份数据的团队。若团队的工作量估算习惯尚未稳定，或迭代边界依赖外部系统定义，则需要先梳理估算字段和迭代归集规则，再评估图表的可用性。上述关于图表字段、聚合方式和筛选能力的细节，建议在试用环境中用真实迭代数据逐项核验，确认与团队的口径一致后再作为迭代评审的正式依据。

Linear

Linear 面向以软件研发为主、希望把需求、迭代与缺陷放在同一套工作流里管理的团队。它把 issue 作为核心对象，迭代通常通过 cycle 组织，进度视图和燃尽趋势围绕 issue 的状态、估算与完成情况生成。对于正在选迭代燃尽图工具的团队，Linear 的评估重点可以放在三处：数据从哪里来、图表随什么动作更新、以及团队能在多大范围内调整统计口径。

数据来源方面，Linear 的燃尽数据主要来自 issue 本身。issue 所属的 cycle、状态变化、完成时间，以及团队启用的估算字段，共同构成燃尽曲线的计算基础。这意味着数据质量取决于日常操作是否规范：issue 是否在开始前进入对应 cycle、状态流转是否及时、估算值是否在迭代中保持稳定。若团队习惯在迭代中途把大量 issue 移入或移出 cycle，燃尽曲线会出现明显跳变，需要提前约定范围变更的记录方式。燃尽图反映的是 issue 层面的完成情况，工时明细、跨团队依赖等更细的数据通常需要借助其他视图或集成补充，选型时应确认这些信息是否影响团队对进度的判断。

更新频率方面，Linear 的图表随 issue 状态和 cycle 数据的变化而更新，属于由操作驱动的实时视图，团队无需等待固定的批量刷新时点。这种机制适合每日站会前查看剩余工作量的变化，也便于在迭代中随时发现进度偏离。需要核验的是团队对“完成”的定义：如果完成状态由多个状态合并统计，或存在验收后才关闭的流程，燃尽曲线的下降时点会与团队感知的完成时点产生差异。建议在试用时用一轮真实迭代观察曲线拐点，确认它与实际交付节奏一致。

配置能力方面，Linear 允许团队按自身流程设置 issue 状态、cycle 周期和估算方式，燃尽视图会跟随这些设置呈现。配置空间集中在工作流和迭代范围上，适合流程相对统一、希望减少额外报表维护的研发团队。若团队需要按项目、客户或自定义字段拆分多条燃尽曲线，或需要把燃尽数据导出到外部报表平台做二次加工，应提前核验现有视图和导出能力是否满足，必要时通过集成补齐。对于多团队共用一套工作区的情况，还要确认 cycle 的划分方式能否对应各团队的迭代节奏。

适配建议上，Linear 更适合 issue 驱动、迭代节奏稳定、愿意用统一状态和估算口径约束日常操作的研发团队。落地时可以先固定三件事：迭代开始前完成 issue 范围确认，迭代中变更范围时留下记录，统一“完成”对应的状态集合。这样燃尽图的数据来源和更新时点就能与团队的实际节奏对齐。若组织同时存在多个节奏差异较大的团队，建议先在一个团队跑通 cycle 与燃尽视图的使用习惯，再逐步推广，并在推广前核验权限、视图共享和跨团队统计口径是否符合管理要求。

数据来源与更新频率的核验方法

演示环境里的燃尽图通常数据干净、曲线平滑，很难暴露口径问题。有效的做法是带着具体动作去试用：改一个工作项、移一次范围、跨一个周末，观察曲线如何响应。下面四组核验动作可以按顺序执行，每步记录实际表现。

验证数据来源是否取自工作项

• 在迭代内新建一个带估算值的工作项，不填任何燃尽专用字段，观察总工作量和剩余值是否自动增加。若图表要求单独录入“今日剩余”，说明存在手工填报环节。
• 修改某个工作项的估算值，确认曲线起点或对应日期的剩余值是否随之调整，判断图表读取的是工作项当前值还是历史快照。
• 关闭一个工作项但不修改其他字段，观察剩余值下降的幅度是否等于该工作项的估算值，以此确认统计口径是工时、故事点还是事项数。

测试更新频率与刷新机制

• 在工作日中途修改一个工作项的状态和剩余值，分别在修改后立即、5分钟后、30分钟后查看图表，记录曲线变化的时间点，区分即时刷新、定时刷新和手动刷新。
• 跨天观察：在站会前查看一次，站会后集中更新剩余值再查看一次，确认当日数据是否在团队讨论前就位。
• 补录前一天的工时或剩余值，检查历史点位是否被回写，判断图表是否保留每日快照。

检查范围变更与日历设置的影响

• 迭代中途把一个工作项移出迭代，观察总工作量线是否下调、已完成的剩余值如何处理，确认范围变更是否在曲线上留痕。
• 在迭代周期内设置一个非工作日或假期，检查横轴是否跳过该日、理想燃尽线是否相应调整。
• 尝试按负责人或工作项类型筛选，确认下钻后各条曲线之和是否与总量一致。

向厂商确认的问题清单

• 燃尽图的剩余值默认取哪个字段，是否允许切换为工时、故事点或事项数？
• 刷新是实时计算、定时任务还是打开页面时触发，最长延迟是多少？
• 迭代范围变更后，历史日期的曲线是否重算，还是只影响变更之后的点位？
• 是否支持非工作日与假期日历，按团队还是按项目配置？
• 历史快照保留多久，能否导出用于迭代复盘？
• 燃尽图的数据权限如何与项目角色对应？

选择与落地建议

把对照表和核验结果放在一起看，选择动作可以按团队规模与迭代节奏分两步走。迭代周期为一到两周、每日站会依赖曲线判断进度的团队，优先选择数据直接取自工作项、刷新能跟上当日更新的工具，并把范围变更留痕作为硬性要求。迭代周期较长、存在多团队并行或节假日较多的团队，需要把假期日历、按团队拆分和下钻能力提到更前面，否则曲线会被日历因素扭曲。规模较小的团队可以接受配置项少一些，但数据来源必须是工作项本身，手工填报的曲线在成员变动后很难维持。

上线前需要固定的统计口径与更新约定包括：

• 明确燃尽图统计的是工时、故事点还是事项数，并在所有迭代中保持一致，避免跨迭代比较失真。
• 约定剩余值的更新时点，例如每日站会后由任务负责人更新，站会前不集中补录。
• 约定迭代范围变更的记录方式，移入移出迭代的工作项需说明原因，便于复盘时解释曲线跳变。
• 配置团队的非工作日与假期，确保理想燃尽线与实际工作日一致。
• 明确“完成”对应的状态集合，避免验收环节导致曲线下降时点与团队感知不一致。

迭代结束时未完成的工作项应重新评估后再决定去向，根据剩余工作量和优先级判断是放入下一迭代、拆分为更小事项还是退回待办，不默认自动结转。自动结转会让下一迭代的起始总量虚高，也会掩盖上一迭代的估算偏差。试点阶段建议选一个节奏稳定的团队，跑完一个完整迭代后对照曲线与实际交付复盘：哪些跳变来自范围变更，哪些来自更新滞后，哪些来自估算偏差。确认口径可用后再推广到其他团队，并把上述约定写入迭代启动流程。

常见问题

燃尽图的数据来源是工作项剩余值，团队还需要额外维护一张燃尽数据表吗？

不需要。燃尽图的价值在于直接读取迭代内工作项的当前值，团队维护好工作项本身即可。需要额外维护一张表的情况通常出现在两种场景：一是工具本身要求每天手工录入“今日剩余”，二是团队想保留每日快照用于复盘而产品不提供历史留存。前者说明数据来源存在人工环节，选型时应优先排除；后者属于补充手段，可以在平台外定期导出或截图归档。

判断方法很简单：新建一个带估算值的工作项，不填任何燃尽专用字段，看总工作量是否自动增加。若图表要求单独录入，就说明存在手工填报环节。

更新频率是实时刷新就一定更好吗？

不一定，关键是与团队的使用节奏匹配。每日站会依赖曲线判断进度的团队，需要工作项状态和剩余值变更后能在站会前反映到图上；如果团队本身每天只在站会后集中更新一次，分钟级刷新带来的收益有限，反而可能因为频繁跳变让讨论失焦。

更值得关注的是刷新机制是否可预期：即时计算、定时任务、打开页面时触发，三种方式对“看到的是什么时候的数据”影响不同。跨时区团队还要确认数据按哪个时区归集，避免站会上对同一条曲线得出不同结论。

迭代中途移入或移出工作项，燃尽曲线应该怎么处理？

处理方式取决于团队约定，工具需要能把这个动作在曲线上留痕。常见做法是范围变更后总工作量线相应调整，并在复盘时能说明变更原因；如果工具只重算历史点位而不保留变更记录，曲线跳变就无法解释。

试用时可以专门做一次验证：迭代中途把一个工作项移出迭代，观察总工作量线是否下调、已完成部分如何处理、历史日期是否被重算。把结果写进迭代启动流程，约定移入移出需说明原因，复盘时才能区分哪些偏差来自范围变更、哪些来自估算不准。

团队节假日较多，燃尽图的理想线需要特别设置吗？

需要。理想燃尽线通常按工作日递减，如果迭代周期内有假期或非工作日而图表未做设置，理想线与实际工作节奏就会错位，实际曲线看起来像“进度落后”，实际只是当天没有工作日。

核验方法是：在迭代周期内设置一个非工作日或假期，检查横轴是否跳过该日、理想线是否相应调整，并确认这项设置按团队还是按项目配置。多团队并行且假期安排不同的组织，应优先选择支持按团队配置日历的工具。

试点阶段应该用多长的迭代来验证燃尽图工具？

建议跑完一个完整迭代，覆盖迭代启动、日常更新、范围变更和迭代结束四个环节。只跑几天无法暴露跨天结转、补录回写和范围变更留痕的问题。

试点团队优先选节奏稳定、成员愿意按约定更新剩余值的一个团队。迭代结束后对照曲线与实际交付复盘：哪些跳变来自范围变更，哪些来自更新滞后，哪些来自估算偏差。确认口径可用后再推广，并把统计口径、更新时点、完成定义写入迭代启动流程。未完成的工作项重新评估后再决定放入下一迭代、拆分还是退回待办。