填团队速度、sprint 长度和人数,13 个故事点等于多少小时、几天、几个 sprint,一眼看清,支持双向换算,全程本地。
- 本地处理
- 分类 计算度量
- 适合 买东西、做计划、训练或排期前,先算出大概范围。
把团队描述清楚:每个 sprint 完成多少点、sprint 几个工作日、几个人、每人每天真正能专注几小时。工具用「sprint 容量 ÷ 速度」推出你们自己的每点工时,再把故事点换成人时、人天、sprint 数,或者把时间预算反推回故事点。
是真专注时间,不是上班时长。实测过的团队大多在 5 到 6.5 小时,剩下的被会议吃掉。
对这个团队,1 个故事点 ≈ 10 个专注小时(sprint 容量 300 小时 ÷ 速度 30)。
这是团队平均值,不是单张工单的承诺。单个故事在它周围波动很正常。用于排期沟通,工单继续用点。
所有运算在你的浏览器里跑,团队信息不会上传。
这个工具能做什么
一个按 Scrum 团队真实估算方式做的故事点(Story Point)与时间换算器, 不是网上那种写死「1 点 = 4 小时」的假对照表。你只需要描述自己的团队: 速度(每个 sprint 完成多少点)、sprint 有几个工作日、几个人,以及每人 每天真正能专注干活的小时数(默认 6,因为没有人能写满 8 小时代码)。 工具用「sprint 总容量 ÷ 速度」推导出你们团队自己的「每点工时」,然后 双向换算:输入故事点,得到人时、人天、需要几个 sprint、全队投入要几个 工作日;反过来输入人时预算,也能算出大约能消化多少点的需求。页面还有 一张斐波那契参考表(1、2、3、5、8、13、21),把整条估算量表按你们 团队的时间标好价,排期会上从「这是个 13」到「大概要全队一周」一句话 讲清,不用假装故事点是秒表。所有展示数字都从同一个「每点工时」推导, 读到的数互相乘得回去,不会自相矛盾。输入会同步到 URL,团队档案可以 直接发给老板或客户。100% 浏览器本地运行,什么都不上传。
工具细节
- 输入
- 数值
- 页面会根据工具类型展示文本框、数值控件、文件选择或结构化输入。
- 输出
- 即时结果 + 复制
- 结果区优先给出可操作结果，支持项会显示复制、下载或可视化预览。
- 隐私
- 浏览器本地处理
- 主工具逻辑未发现外部 API 调用，输入通常留在当前标签页内处理。
- 保存 / 分享
- 可分享链接状态
- 关键设置会进入 URL，复制链接后别人能复现同一组参数。
- 性能预算
- 首屏 JS ≤ 10 KB
- 没有声明 WASM 依赖，适合快速打开和移动端使用。
- 适用场景
- 计算度量 · 产品经理
- 分类和职业标签用于推荐相关工具、组织内链，并帮助用户快速判断是否适合当前任务。
怎么用
-
1. 输入
把内容粘贴或拖入工具面板。
-
2. 处理
点击按钮,在浏览器内本地处理,文件不上传。
-
3. 复制 / 下载
一键复制结果或下载到本地。
故事点工时换算器 适合怎么用
适合快速估算、对比和规划数字,帮你在做最终决定前先有底。
适合计算任务
- 买东西、做计划、训练或排期前,先算出大概范围。
- 一次只改一个输入,对比不同方案。
- 把模糊假设变成能讨论的数字。
计算检查项
- 认真核对单位、日期、比例和取整方式。
- 健康、金融、税务、法律相关结果只能做规划参考,不能替代专业意见。
- 重要结果要保存输入条件,方便以后复算。
下一步可以接着做
这些入口会把当前任务接到更完整的工具链里。
真实使用场景
路线图评审上回答「这个 epic 什么时候能上」
一个 epic 估了 40 点。你的 5 人团队两周一个 sprint,平均做完 30 点,每天有效专注约 6 小时。填 40 点、速度 30、10 个工作日、5 人、 6 小时,工具给出约 1.33 个 sprint,折合约 13 个团队工作日、400 人时。你可以拿着完整的数字链对老板说「下下个 sprint 初能上」, 而不是含糊其辞;把 URL 发出去,所有假设大家都看得见。
算清一笔固定时间预算能装下多少需求
客户买了一个 4 人小队三周的时间。切到「工时 → 故事点」,把预算 换成人时填进去(4 人 × 15 天 × 6 小时 = 360 人时),配上你们的 速度档案,工具直接换算出这笔预算大约能消化多少故事点。范围谈判 从「尽量做」变成对着 backlog 点菜:「能装下前 28 点,也就是这 六个故事」。
sprint 排期会上给承诺量做体检
排期会上团队试探性拉进了 38 点,但历史速度平均只有 30。把 38 点 填进自己的档案:工具显示这相当于约 1.27 个 sprint 的容量,超载 27% 一目了然,不需要任何人先站出来唱反调。要么砍掉 8 个点, 要么大家清醒地接受会有遗留。
给新来的业务同事讲清估算量表
新来的销售负责人总在问「一个 5 到底是几小时」。打开工具,把 团队真实档案设好,带他看斐波那契参考表:5 点约 50 个专注小时, 13 点约 130 个,并讲清楚团队或 sprint 一变这些数就会变。十分钟 看一张表,省掉以后每周一次的走廊换算之争。
常见踩坑
把换算结果当成单张工单的承诺。每点工时是团队平均值,一个 5 点的故事实际花掉换算时间的一半或两倍都正常。它适合做聚合排期和路线图沟通,不适合拿着秒表盯单张工单。
按每天 8 小时算容量。会议、评审、来回切换每天稳定吃掉 2 到 3 小时,实测过的团队大多在 5 到 6.5 小时。按 8 算容量虚高三成,换算出的每个估算都偏乐观;没有实测数据就别动默认的 6。
速度里混进了没做完的工单。velocity 只该统计真正到 done 的点数。把跨 sprint 的半成品也算进去,分母变大、每点工时变小,所有预测会朝同一个乐观方向悄悄漂移。
隐私说明
所有计算都在你的浏览器里完成,团队速度、人数、sprint 长度和你换算的 数量都不会发到任何服务器,也没有人记录你们团队的交付节奏。唯一要 留意的是:分享链接会把这些输入写进 URL 参数(例如 ?v=30&n=5),贴到 聊天或邮件里,对方的浏览历史和沿途的访问日志都会留下你们的速度档案。 速度通常不算机密,但如果你们在意,复制结果文本就好,别分享 URL。
常见问题
类似工具组合
做你这行的人, 还会一起用这些。