故事点和工时回答的是两个不同问题：故事点衡量团队对工作项相对规模、复杂度和不确定性的综合判断，工时衡量完成工作预计或实际投入的人的时间。前者是无单位的相对量，后者是有单位的绝对量，二者参照系不同，不存在稳定的换算系数。团队在迭代计划中同时使用两套口径时，应让故事点服务于规模排序，让工时服务于排期与资源安排，避免把两者强行对齐。
要点总览（TL;DR）
- 故事点衡量团队对工作项相对规模、复杂度和不确定性的综合判断，是无单位的相对量；工时衡量完成工作预计或实际投入的人的时间，是有单位的绝对量。
- 故事点适用于同一团队内的排序与承接判断，工时适用于排期、资源占用与投入记录；故事点不承担跨团队绝对比较和对外时间承诺。
- 不能直接换算的根源是参照系不同：故事点以团队历史基线为锚，工时以人的时间为刻度，估算不确定性在前者中被吸收、在后者中被显性化为区间。
- 经验比例会随人员、任务类型和时间漂移，只能作为事后观察；强行换算会把估算分歧伪装成精确数字，让分歧在排期和交付时重新暴露。
- 并用两套口径的做法是：工作项上分别记录故事点与预估工时，计划阶段用故事点定范围、用工时排期，评审与回顾时对照偏差发现估算分歧。
故事点和工时各自衡量什么
故事点是对工作项大小的相对度量。团队选定一个基准工作项，把其他工作项与它比较，判断“这件事比那件事大多少”，再给出一个数字。这个数字综合了工作量、复杂度、技术风险和不确定性，没有统一单位，也不对应任何固定时长。同样记为5点的工作项，在不同团队、不同时期可能对应完全不同的实际投入。
工时是完成某项工作预计或实际投入的人的时间，通常以小时或人天为单位。它有明确的计量单位，可以跨任务累加，也可以与人员的可用时间直接比较。工时回答的是“这件事要占用谁多少时间”，适合用于排期、资源占用判断和投入记录。
| 维度 | 故事点 | 工时 |
|---|---|---|
| 计量对象 | 工作项的相对规模、复杂度与不确定性 | 完成工作投入的人的时间 |
| 单位性质 | 无单位，团队内部相对量 | 有单位（小时、人天），绝对量 |
| 回答的问题 | 这件事比那件事大多少 | 这件事要占用谁多少时间 |
| 可比范围 | 同一团队的历史基线内 | 可跨任务累加，与人员可用时间比较 |
一句话概括：故事点用于比较大小，工时用于衡量时间占用。两者都服务于计划，但计量对象不同，不能互相替代。
计量边界：故事点与工时各自管到哪里
故事点的适用范围集中在团队内部的相对比较。迭代计划中，团队可以用故事点给待办工作项排序，判断一个迭代能承接多少工作；经过若干迭代后，观察每个迭代完成的故事点总量，形成对自身节奏的认识。这些用法都建立在同一团队、同一基线的前提上。
故事点不承担跨团队的绝对比较。两个团队同为8点的工作项，实际规模可能相差很大，直接比较没有意义。故事点也不适合作为对外的交付时间承诺，因为它本身不包含时间信息。
工时的适用范围偏向时间与资源侧。排期时，团队根据预估工时判断工作项能否在迭代内完成；识别资源冲突时，把预估工时与成员可用时间对照，发现谁被排满、谁还有余量；投入记录时，实际工时反映真实的时间消耗。工时填报与审核的操作流程、产能与投入产出分析的指标计算属于相邻主题，本文只做概念区分，不展开具体做法。
| 场景 | 适合用故事点 | 适合用工时 |
|---|---|---|
| 迭代内工作项排序 | 适用 | 不适用 |
| 观察团队每个迭代的完成节奏 | 适用 | 不适用 |
| 跨团队规模绝对比较 | 不适用 | 不适用 |
| 对外交付时间承诺 | 不适用 | 需结合其他信息 |
| 迭代排期与完成判断 | 辅助参考 | 适用 |
| 识别成员资源冲突 | 不适用 | 适用 |
| 记录实际时间投入 | 不适用 | 适用 |
为什么不能直接换算：参照系与不确定性来源
不能换算的根本原因在于两者的参照系不同。故事点的参照系是团队自身的历史基线：团队拿当前工作项与过去做过的工作项比较，得出相对大小。工时的参照系是人的时间：一天八小时、一周五个工作日，这是外部给定的刻度。两套参照系之间没有共同的锚点，换算缺少可依据的中间量。
估算不确定性的处理方式也不同。用故事点时，不确定性被吸收进点数本身：一个技术方案尚不明确的工作项，团队会给它更高的点数，以此表达“这件事不仅大，而且说不准”。点数不区分“工作量大”和“风险高”，两者合并成一个相对判断。用工时时，不确定性通常被显性化为区间，例如“预计16到24小时”，区间宽度本身就承载了风险信息。同一个不确定性，在故事点里是隐含的，在工时里是展开的，两种表达无法一一对应。
即便某个团队在某一时期统计出“1点约等于6小时”这样的经验比例，这个比例也会随团队人员变化、任务类型变化和时间推移而漂移。新成员加入、技术栈调整、工作项从功能开发转向缺陷修复，比例都会改变。它不是一个稳定成立的系数，只能作为事后观察，不能作为事前换算依据。
强行换算还会带来一个隐蔽后果：把估算分歧伪装成精确数字。团队对某个工作项到底是5点还是8点有争议，这个争议本身是有价值的信息，说明大家对范围或风险的理解不一致。一旦用系数折算成30小时还是48小时，争议看起来被“解决”了，实际上只是被一个未经检验的比例掩盖，分歧仍然存在，还会在排期和交付时重新暴露。
相邻概念区别：故事点、工时与速率、产能
故事点与速率容易混淆。速率是单位迭代内完成的故事点总量，它仍然是相对量，衡量的是团队节奏，不是产出价值。速率的作用是帮助团队判断下个迭代大致能承接多少点，它的前提依然是同一团队、同一基线。速率不能跨团队比较，也不能折算成工时。
工时与产能的关系在投入侧。产能描述一段时间内可投入的时间总量，例如一个三人小组在一个两周迭代内约有240人时可用。产能是投入侧的上限，工时是具体工作项对投入的占用。把预估工时汇总后与产能对照，可以判断排期是否超出承受范围。产出与投入产出分析属于其他主题，本文只做概念区分。
| 术语 | 计量对象 | 量的性质 | 典型用途 |
|---|---|---|---|
| 故事点 | 单个工作项的相对规模 | 相对量，无单位 | 工作项排序、迭代承接判断 |
| 速率 | 单位迭代完成的故事点总量 | 相对量，无单位 | 观察团队节奏、预测承接量 |
| 工时 | 完成工作项投入的人的时间 | 绝对量，有单位 | 排期、资源占用、投入记录 |
| 产能 | 一段时间内可投入的时间总量 | 绝对量，有单位 | 判断排期是否超出承受范围 |
四个术语分属两组：故事点和速率在规模侧，工时和产能在时间侧。组内可以相互参照，组间只能并列使用，不能换算。
迭代计划中的具体例子与常见误解
假设一个团队在迭代计划会上处理一批工作项。团队先用故事点排序：支付流程改造记为8点，订单列表筛选记为3点，日志清理脚本记为1点。排序结果是先做支付流程改造，再做订单列表筛选，最后做日志清理脚本。接着团队用工时排期：支付流程改造预估20到28小时，订单列表筛选预估8小时，日志清理脚本预估3小时。对照两名开发成员在本迭代约120小时的可用时间，团队发现支付流程改造的不确定性区间较宽，决定先安排一次技术方案确认，再确定具体排期。
这个例子里，故事点服务的是“先做哪个”的决策，工时服务的是“谁来做、来不来得及”的决策。两套数字并存，各自回答不同问题，不需要互相折算。
常见误解有三类。第一类是认为存在固定换算系数，比如“1点等于6小时”，并把它写进团队规范。这个系数在人员或任务类型变化后就会失效，用它做计划会持续产生偏差。第二类是用故事点折算工时做绩效或承诺，例如把完成的点数乘以系数当作工作量考核，或者向外部承诺“这个迭代交付40点”。故事点原本是团队内部的相对判断，一旦被折算成对外数字，团队会倾向于给工作项虚高点数，估算失去参考价值。第三类是把工时当规模、把故事点当进度。工时反映的是时间占用，不能说明工作项大小；故事点反映的是相对规模，完成点数不等于完成进度，因为不同工作项的点数含义并不均等。
团队同时使用两套口径时的衔接做法
让两套口径各司其职，关键在于把字段用途写清楚，并在计划、评审、回顾三个环节分别使用。以下做法可以直接在迭代计划中执行。
- 在工作项上分别记录故事点和预估工时，并在字段说明中写明用途：故事点用于排序和承接判断，预估工时用于排期和资源对照。
- 计划阶段先用故事点排序，确定本迭代的工作项范围；再用工时排期，把工作项分配到成员，对照可用时间识别资源冲突。
- 评审时对照两套数字：某个工作项实际耗时明显超出预估工时，同时故事点也被团队认为给低了，说明估算基线需要调整；如果只是工时超出而点数判断不变，则更可能是执行条件变化。
- 回顾时把两套数字的偏差当作讨论素材，发现估算分歧，而不是强行让它们对齐。分歧本身提示团队需要补充信息或拆分工作项。
在工具承载上，ONES Project 支持任务工时统计，可用于估算任务持续时间；ONES 资源和工时管理解决方案支持查看项目和团队的资源利用率及负荷度，帮助识别资源分配情况，也支持多维度统计资源投入并查询、导出工时登记日志明细。团队可以把规模判断与工时预估分别记录在工作项上，在迭代视图中汇总对照。故事点字段的具体承载方式与配置细节以官方资料和实际版本为准。
需要强调的是，双口径并用的目的是让规模判断和时间安排各自清晰，而不是制造两套互相验证的数字。当两套数字出现偏差时，优先回到估算讨论，确认工作项范围、技术方案和人员条件是否发生变化，再决定调整哪一侧的判断。
常见问题
团队已经习惯了“1点等于几小时”的经验比例，继续用会有什么问题？
把经验比例当作事前换算依据，问题不在于比例本身不准，而在于它不稳定。这个比例是在特定人员、特定任务类型下统计出来的，新成员加入、技术栈调整或工作项从功能开发转向缺陷修复，比例都会变化。用它做计划，偏差会持续累积，团队却容易把偏差归因于执行不力，而不是换算假设本身失效。
更稳妥的做法是把比例当作事后观察：回顾时看看两套数字的偏差方向，判断是范围理解有误还是执行条件变化，再决定调整哪一侧的估算，而不是拿它去折算下一次的计划数字。
如果团队规模很小，只用工时不用故事点，可以吗？
可以。故事点的价值在于用相对比较吸收不确定性和复杂度，当团队人数少、工作项类型单一、成员对彼此的工作都很熟悉时，直接用工时排期也能运转。是否引入故事点，取决于团队是否需要一套独立于时间的规模判断来支撑排序和承接决策。
需要注意的是，一旦只用工时，规模判断和时间判断就合并成一个数字，估算分歧不容易被看见。团队可以在回顾时留意预估工时偏差是否集中出现在某类工作项上，作为是否需要补充规模口径的信号。
故事点给得高的工作项，是不是意味着风险也一定高？
不必然。故事点综合了工作量、复杂度、技术风险和不确定性，一个点数高的工作项可能只是工作量大，风险并不突出；也可能工作量中等但技术方案不明朗，点数被抬高。点数本身不区分这些成分。
如果团队需要单独跟踪风险，可以在工作项上补充风险标记或技术方案确认状态，与故事点并列记录。这样在计划时既能按规模排序，也能识别哪些工作项需要先做方案澄清再排期。
评审时发现实际工时远超预估，但故事点判断没变，该怎么处理？
这种情况通常指向执行条件变化，而非规模判断失误。可以先确认几件事：是否有成员临时缺席或并行任务增多，技术方案是否在执行中调整，外部依赖是否延迟。这些因素影响时间占用，但不改变工作项本身的相对大小。
处理方式是在回顾中记录条件变化，更新对同类工作项的时间预估区间，故事点基线保持不变。如果同类偏差反复出现，再考虑是否需要在规模判断中纳入新的复杂度因素。
向外部干系人汇报迭代进展时，应该用故事点还是工时？
取决于汇报对象关心什么。关心交付范围和时间安排的干系人，更适合看已完成工作项的清单和工时投入情况；关心团队节奏的内部讨论，可以用完成的故事点总量与速率对照。
需要避免的是把完成点数直接当作进度百分比对外承诺。不同工作项的点数含义并不均等，完成40点不代表完成了整体工作的固定比例。对外汇报时，用工作项清单配合时间信息更准确，也能减少团队为了数字好看而虚高点数的情况。
