WSJF 敏捷框架

加权最短工作优先（Weighted Shortest Job First，WSJF）通过平衡延迟成本和工作规模，帮助你对工作进行优先级排序。这个框架在快速变化的环境中，以有限的资源交付最大价值。

WSJF 优先级排序要点

创建免费 Ducalis 账户

WSJF 计算公式

WSJF 评分 = (业务价值 + 时间紧迫性 + 风险降低) / 工作规模

评估标准

用户/业务价值按工作对用户的重要性和潜在收入影响进行排名。

时间紧迫性按紧急程度对工作进行排名——价值如何随时间衰减，或延迟可能失去多少客户。

风险降低与机会赋能突出那些可能不会立即带来收入，但有利于长期成果的工作。一些解决方案可以消除技术或法律风险，并在未来节省资金。

工作时长（也称为故事点、功能点、投入或相对规模）衡量实施复杂度。对于这个评估，数字越小越好。

评估方法

1. 使用斐波那契量表对每个标准进行评估：1（无影响）、2、3、5、8、13、21（影响最高）。

2. 与 5 到 11 人的团队一起进行协作优先级排序会议。

3. 在每次迭代规划事件（Sprint）之前评估任务。

4. 通过与团队成员讨论来标准化不同的评分。

5. 将工作规模为"21"和"13"的计划拆分为更小的项目（待办事项细化）。

6. 每 5 个迭代（计划增量）重置评估分数，以反映快速变化的环境。

应用 Ducalis 开箱即用的优先级排序模板

无需自定义标准、公式和量表。将它们用作启动会议的模板。

注意

WSJF 不仅仅是一个公式——它是企业广泛工作流程框架的一部分。当你改变决策方式时，魔法就会发生：运行协作优先级排序会议、设置评分过期、指定标准，并向团队成员解释任务描述。本文提供工具来创建这种优先级排序习惯并转变你的思维方式。

WSJF 定义

WSJF 代表加权最短工作优先——一个通过计算相对延迟成本（CoD）和工作规模（持续时间的代理指标）来对待办事项进行优先级排序的框架。CoD 计算为一个总和：**用户/业务价值 + 风险降低与机会赋能 + 时间紧迫性。**它是 SAFe 方法论的一部分。

待办事项优先级基于 WSJF 优先级评分持续更新。该框架便捷且自动地忽略沉没成本，这是精益经济学的基本原则。

在基于流程的系统中，持续的任务优先级排序以更新优先级，可提供最佳的经济成果：

• 通过推动速赢项目向前进行工作排序
• 平衡最高财务结果与降低投入资源
• 定期更新 CoD 和工作规模以反映快速变化的环境

什么是 SAFe？

根据 ScaledAgile.com，规模化敏捷框架（SAFe）是一个在规模上实施敏捷、精益和 DevOps 实践的系统。它吸收了敏捷产品交付的最佳理念，并将其扩展到整个企业以提供业务敏捷性。SAFe 是领先企业最受欢迎的框架，因为它有效：值得信赖、可定制且可持续。

它不断更新并有版本。2022 年最新版本是 5.1，SAFe 涵盖企业的七个主要领域：

• 团队和技术敏捷性
• 敏捷产品交付
• 企业解决方案交付
• 精益组合管理
• 组织敏捷性
• 持续学习文化
• 精益敏捷领导力

承诺的成果：

• 上市时间加快 50%
• 缺陷减少 50%
• 生产力提高 35%
• 员工幸福度和参与度提高 30%

在本文中，我们将专注于基础——WSJF 决策框架。

下载免费 WSJF 模板：

如何计算 WSJF

WSJF 公式

加权最短工作优先（WSJF）框架通过在快速变化的世界中找到延迟成本（CoD）和工作规模之间的平衡，帮助你决定下一步选择哪个任务以有限资源交付最大价值。

计算 WSJF 评分

WSJF 评分 = 延迟成本 / 工作规模

计算 CoD，它定义了你应该关注的三种类型的产品开发问题。

延迟成本 = 用户-业务价值 + 时间紧迫性 + 风险降低 | 机会赋能价值

使用 1、2、3、5、8、13、21 的量表评估每个标准。

评估原则：

• WSJF 评估旨在理解不确定性水平，而不是计算小时或金额（这几乎是不可能的）。这就是为什么我们评估概率而不是完成特定任务的确切时间。这被称为相对评估。

• 由于主要目标是在每次迭代中交付价值，序列的中位数将是"一个迭代"。

• 一个迭代 = 2 周。我们的规划基准。我们计算 2 周迭代的故事点数。

• 计划增量（PI）= 5 个迭代（10 周）。根据 SAFe，PI 是一个时间盒，在此期间敏捷发布火车（ART）以工作、经过测试的软件和系统的形式交付增量价值。整个团队为产品实现一些重大成果。换句话说，组织发布一个大更新，之后他们应该重新评估待办事项，再次思考和讨论优先级。

自定义

这只是建议，你可以以适合团队的任何方式自定义该方法。本文稍后部分将介绍如何更好地理解和自定义标准，以精确满足你的业务需求。

用户-业务价值（UBV）

推动产品向前发展的新功能和创新。例如，企业安全登录选项有助于避免来自大客户的投诉，从而促进销售。

用户/业务价值（UBV）按工作对用户的相对重要性（优先考虑需求性）和对收入的潜在影响（财务优先级排序）对你的工作进行排名。在这一点上，你评估该解决方案在推动北极星指标方面的有效性。由于许多因素可能影响 UBV，开始考虑业务影响并增强你对一切都会成功的信心。

**需要回答的问题：**你可以更新哪个重要的产品指标？这对用户有多重要？对收入的影响是什么？

使用斐波那契数列的用户-业务价值评估

• **1 分：**完全没有用户-业务价值；此任务与其他内容相关
• **2 分：**最低的业务影响和信心
• **3 分：**低业务影响和信心
• **5 分：**中等业务影响，中等信心
• **8 分：**高业务影响和信心
• **13 分：**非常高的业务影响和信心
• **21 分：**最高的业务影响和信心

时间紧迫性（TC）

评估紧急程度。计划有合理的截止日期，如新法规、税务报告、季节性促销等。

时间紧迫性按紧急程度对工作进行排名。你评估价值如何随时间衰减，或如果拖延可能失去多少客户。

我们的评估时间框架从一个迭代（2 周）到一个计划增量（PI）（10 周）。每个 PI 周期，我们运行一次新的重新评估会议（评分过期后）并决定紧急程度如何变化。

**需要回答的问题：**对业务有多紧急？用户会等待还是转向其他解决方案？是否有固定的截止日期？

使用斐波那契数列的时间紧迫性评估

• **1 分：**完全不是时间紧迫的任务
• **2 分：**可以等到下一个评估周期（每 5 次迭代评分过期后）
• **3 分：**可以等待 4 个 Sprint（约 8 周）
• **5 分：**中等紧急程度，可以等待 3 个 Sprint（约 6 周）
• **8 分：**可以等待 2 个 Sprint（约 4 周）
• **13 分：**可以等待 1 个 Sprint（约 2 周）
• **21 分：**最高紧急程度，必须将该工单纳入下一个 Sprint

风险降低 | 机会赋能价值（RR | OE）

避免或减少技术或业务风险的任务。示例包括代码重构、数据库更新、安全或税务审计——确保产品健康运营必须做的事情。

风险降低与机会赋能帮助你突出那些可能不会立即带来收入但有利于长期发展的工作。一些解决方案可以消除技术或法律风险，并在未来为你节省资金。其他解决方案可能为进一步改进打开大门，这将显著增加潜在客户的数量。

**需要回答的问题：**如果任务以某种风险描述开始，该风险的影响有多大？概率如何？

使用斐波那契数列的风险降低评估

• **1 分：**完全不提供任何风险降低
• **2 分：**降低最低风险的可能性，最低严重性概率
• **3 分：**降低低风险的可能性，低严重性概率
• **5 分：**降低中等风险的可能性，中等严重性概率
• **8 分：**降低中高风险的可能性，高严重性概率
• **13 分：**降低非常高风险的可能性，非常高严重性概率
• **21 分：**可以降低高度影响事件的风险，这是最有可能发生的灾难

工作规模（工作时长）

工作规模是唯一的负面因素，按实现复杂度对工作进行排名。在不考虑所需人时成本的情况下，不可能实现最高 ROI。时长也称为故事点、功能点、投入或相对规模。

**需要回答的问题：**实施需要多长时间？是否有可能使其更耗时的依赖关系？

使用斐波那契数列的工作规模评估（故事点）

• **1 分：**根本不需要任何投入。我们不能除以零，因此工作规模评估应从 1 开始。
• **2 分：**评估基准。80% 的概率是，对于 2 周迭代，1 天足以编码，1 天足以测试和验证。
• **3 分：**大约占你 Sprint 投入的四分之一的任务
• **5 分：**大约占你迭代的一半。80% 的概率是，对于 2 周迭代，任务需要 5 个工作日编码，1 天测试和验证。
• **8 分：**80% 的概率是，任务将在 2 周内（一个迭代/Sprint）开发和测试完成
• **13 分：**介于 1 到 2 个迭代之间
• 21 分："巴斯光年评估"，需要 2 个 Sprint 甚至更长时间的事情（"飞向宇宙，浩瀚无垠"）。根据我与团队合作的实际经验，你会评估许多超过一个迭代的想法，这些想法应该被分解为更小的块。

计算 WSJF 评分的最终公式：

WSJF 评分 = (业务价值 + 时间紧迫性 + 风险降低 | 机会赋能) / 工作规模

为团队自定义标准

在标准 Scrum 框架中，每个团队的故事点估算——以及由此产生的速度——是一个本地和独立的问题。这是你评估过程的起点。你可以从 Ducalis WSJF 模板应用它并修改标准描述。

对于量表没有单一的正确定义。如果你和你的团队对任何术语感到困惑——改变它！Ducalis 在这方面相当灵活。

迭代

敏捷流程的核心是称为迭代或 Sprint 的基本构建块。每个迭代是一个标准的固定长度时间盒，敏捷团队在其中交付增量价值。

迭代规划事件（产品增量）

每个迭代都应该从明确的优先级列表开始。在该规划之前，你应该有一个已评估的待办事项。团队通常会在开发周期之间花费整整一周的时间进行评估、优先级排序和规划。然后，在短迭代（Sprint）中部署价值。

Ducalis 可以通过异步评估流程为你的团队节省整整一周的时间。设置一个规划日，Ducalis 将完成其余工作。你可以通过团队评估进度报告跟踪评估进度。

为了激励你的团队成员按时评估，提供鼓励性消息的支持。前往优先级排序习惯设置，并为在即将到来的迭代规划会议之前按时完成评估的团队成员设置奖励消息。

重新评估的力量

首要优先级、紧急程度和业务价值是易变的产品。有太多输入——新客户请求、Bug、技术债务、新法规、奇思妙想等等。

SAFe 的整个理念是以新的方式适应快速变化的世界。公司的环境每 5 个迭代（一个 PI）都会发生变化。因此，强烈建议重置评估分数。

在基于流程的系统中，持续更新优先级可提供最佳的经济成果。在这样的流程环境中，工作排序而不是理论上的单个工作投资回报率会产生最好的结果。

待办事项重新评估的一个附带好处是待办事项整理/细化。在思考每个待办事项时，你会得到一些关于如何合并、更新或删除任务的想法，因为某些信息由于某种原因已经过时。根据 hi.ducalis.io 的经验，我们在每个重新评估周期删除 2% 到 5% 的待办事项。

设置重新评估周期：

1. 点击 Meeting in # days (# 天后会议)。
2. 向下滚动到评分过期部分。

默认情况下，你团队的评估分数将在开始下一个 PI 周期后过期。

默认情况下，Sprint 为 2 周。在优先级排序习惯部分自定义它。

专业提示

如果你的分数已过期但你没有完成上一个 PI，你始终可以恢复分数并延长优先级排序期限。

协作优先级排序

敏捷评估是一项团队运动。每个敏捷团队由 5 到 11 名成员组成。邀请你的敏捷团队（跨职能团队）参与优先级排序过程。

当团队评估产品待办事项时，他们不知道谁将处理每个任务。团队通常在迭代规划（Sprint）期间确定这一点。

这就是为什么整个敏捷团队评估每个产品待办事项的原因。

减少偏差

整个团队需要理解故事点分配背后的逻辑，以达成一致的实践。所有团队成员在投票时不受其他团队成员的影响。外部压力或不充分的团队合作可能迅速夸大故事点，影响预测。

有时优先级排序会议可能由房间里声音最大的人主导。这意味着在评估会议期间你们可能会互相干扰。让每个人按自己的节奏进行优先级排序。

选择"正确的影响"

我们在文章开头讨论了业务影响。但如果你问不同角色这样一个简单的问题，"我们接下来应该做的最有影响力的事情是什么？"你会得到什么答案呢？例如，我敢打赌开发人员会告诉你"更快的数据库"，销售人员会说"最大客户的功能请求"，产品经理会要求"新的留存消息"等等。

几乎不可能比较哪个更有影响力。然而，这对每个敏捷团队来说都是一件好事，也正是 Ducalis 可以为你处理的。

收集不同意见

优先级排序框架非常适合将情绪和政治排除在决策之外，这样你就可以依赖事实。然而，当你单独进行优先级排序时，你仍然是有偏见的。为优先级排序借用扑克规划技术。使用 Ducalis，邀请每个团队成员参与优先级排序。

邀请团队成员：

1. 打开标准设置。
2. 邀请团队成员加入你的共享评估团队。

这为每个团队成员提供了他们的评估列表以进行独立估算。

为每个角色指定标准

假设你需要为网站开发一个新功能。你至少有三个角色——UX 设计师、前端和后端——对该功能都有不同的工作规模。UX 需要 3 天的工作规模，前端需要 1 天，后端需要 5 天。总项目的工作规模是多少？

问题不在于计算；你的团队应该找到一个时间段来讨论它。在远程优先的世界中，这意味着又一次 Zoom 通话和讨论。更多围绕工作的工作。

Ducalis 可以通过异步优先级排序方法为你处理这个问题。

按角色分配标准：

1. 打开标准设置。

2. 根据每个用户的专业知识为他们分配一个要评估的标准。

   

之后，每个团队成员将使用他们负责评估的标准集评估待办事项。

当每个人都参与时，会增加认同感

协作优先级排序的副作用是团队成员更好地理解产品的情况。我们知道我们面临哪些挑战、请求和想法，以及为什么有些比其他更重要。这提高了士气和团队参与度。

标准化评分

通过定期实践会进行一些标准化，有助于确保团队中的每个人在规模评估背后做出相同的假设。例如，如果一个人将一个项目评为"2"，但另一个人将其评为"8"，鉴于他们具有相似的能力，他们对需求的解释不同或从不同的方向处理它。当这种情况发生时，开发人员与产品负责人合作澄清假设并就规模达成一致。（这不需要达成共识——人们可以同意不同意。）

当团队学习斐波那契量表对他们意味着什么时，凭借他们独特的技能、任期和领域知识，将新请求与具有共同相似性的已完成工作进行比较是有帮助的。例如，当一个新项目被分配了 5 个故事点值时，将其与具有相同规模的类似事物进行比较，并相应地调整点数。

使用 Ducalis，你可以快速检查团队一致性报告以获得分歧的热图。这是异步优先级排序的另一个工具，而不是运行扑克规划会议，在那里大多数评估根本不需要任何讨论。

分解为更小的块

关于 WSJF 的最大误解之一是，它可能会让你的团队只专注于简单的任务（速赢项目）。相反，特定任务的工作规模越小，优先级评分越高，任务排名越高。

使用矩阵将待办事项切分为片段，并决定如何处理你的任务。

通过细化的实践——将工作分解为更小、更有价值的块——开发人员继续获得洞察。随着每个请求变得更小并了解更多信息，他们不断重新审视规模。因此，最好提供三个接触点来帮助团队进行新兴设计、开发和依赖关系。

实用建议

• 不要试图过于精确。如果你有一个小时的任务，不要害怕将基准设置为一天。从长远来看，这一切都会得到补偿和平衡。

• 将评估四舍五入到下一个值。

• 然而，最终决定权仍由负责对相关待办事项中的项目进行排序的产品专业人员决定。诸如监管截止日期、遗留系统脆弱性或为未来功能奠定基础等因素可能难以用财务术语表达，但仍需要考虑。

相关资源

• WSJF Google Sheets 模板

---

hi.ducalis.io 与规模化敏捷框架或 SAFe 没有关联。请在 https://www.scaledagileframework.com/ 阅读他们的愿景和宣言。