scrum打分规则斐波那契_为什么斐波那契积分系统对冲刺估计很糟糕

scrum打分规则斐波那契

斐波那契积分系统 (The Fibonacci Point System)

We employ the following point system in our sprints to size feature complexity and estimate velocity. Each point builds upon the previous point’s complexity requirements.

我们在冲刺中采用以下点系统来确定特征复杂度并估计速度。 每个点都基于前一点的复杂性要求。

• 1 — Small one line fixes, copy changes, or design tweaks.
  1-较小的一行修复，复制更改或设计调整。
• 2 — Small logic changes with potential regressions.
  2-细微的逻辑变化以及潜在的回归。
• 3 — Standard feature that often requires tracking and AB testing.
  3-标准功能，通常需要跟踪和AB测试。
• 5 — Larger features than 3 that usually involve creating new screens and components.
  5-比3大的功能，通常涉及创建新的屏幕和组件。
• 8 — Very large feature that often requires significant refactoring or designing a new architecture.
  8-非常大的功能，通常需要大量的重构或设计新的体系结构。
• 13 — Epics. Projects that are too large to scope. Highly complex multi-sprint efforts that require significant planning and testing.
  13-史诗。 范围太大的项目。 高度复杂的多冲刺工作，需要大量的计划和测试。

It’s a very common software industry standard to use Fibonacci pointing to estimate how much work we can accomplish within two-week sprints. Teams use estimations to determine sprint goals, calculate velocity and staffing needs based on burn-down charts, and plan quarterly roadmaps. Nevertheless as much as they try to estimate correctly, teams are always falling behind. From my experience, people end up not taking estimation seriously and even abandon it entirely.

使用斐波那契指标来估计我们在两周的冲刺中可以完成多少工作是非常普遍的软件行业标准。 团队使用估算来确定冲刺目标，基于燃尽图来计算速度和人员需求以及计划季度路线图。 但是，尽管他们尽力做出正确的估算，但团队总是落后于团队。 根据我的经验，人们最终没有认真对待估计，甚至完全放弃了估计。

It’s a common joke among developers to say,

在开发人员中经常说一个笑话，

“Oh just take whatever work you have to do and multiply it by 3.”

“哦，随便做什么工作，再乘以3。”

We laugh it off but there is some truth behind it.

我们笑了，但背后有一些道理。

为什么对Sprint估计不利 (Why it’s Bad for Sprint Estimation)

While Fibonacci pointing is good for measuring the complexity of a project, it by itself is a poor point system for measuring the actual amount of time and work it will take to complete a feature.

尽管斐波那契指向点可以很好地衡量项目的复杂性，但它本身是一个很差的评分系统，无法衡量完成功能所需的实际时间和工作量。

Here is where the fallacy lies. Take this scenario for example:

这就是谬误所在。 以这种情况为例：

• Person A has FIVE 2 point tickets. Total points: 10
  A人有五张2点门票。 总分：10
• Person B has TWO 5 point tickets. Total points: 10
  B人有两张5分的门票。 总分：10

On paper and from management’s perspective, both person A and B have the same amount of work, 10 points each. However in reality, Person A has a relatively light sprint with work that requires little-to-no planning and minimal code review times of about 5 minutes per ticket.

从表面上看 ，从管理层的角度来看 ，甲乙双方的工作量相同，各占10分。 但是实际上，A人的工作冲刺相对较轻，几乎不需要计划，并且代码审查时间最少，每张票大约5分钟。

Meanwhile Person B has an impossible sprint that is severely underestimated due to the number of unknown variables that typically arise with 5 point stories and above. Not to mention, it takes HOURS if not DAYS to get larger pull requests to be reviewed, updated, reviewed again, and repeat until it’s approved. Writing unit tests and QA-ing larger features also scales linearly with how complex the feature is. So in total for a 5 point feature, Person B is actually doing significantly more work to have everything done “correctly”. Otherwise they are taking “shortcuts” by writing hacky code, bypassing code review, or skipping unit testing. Either that or they are working overtime which WILL lead to developer burnout.

同时，人B的不可能冲刺被严重低估了，这是由于5点及以上的故事通常会出现未知变量的数量。 更不用说，它需要HOURS(如果不是DAYS天)就可以获取更大的拉取请求进行审核，更新，再次审核，并重复进行直到获得批准。 编写单元测试和对较大的功能进行质量检查也可以随着功能的复杂程度线性扩展。 因此，总体而言，对于5点功能，人B实际上要做的工作要多得多，才能“正确地”完成所有工作。 否则，他们会通过编写骇人的代码，绕过代码审查或跳过单元测试来“捷径”。 如果不是这样，他们正在加班加点，这将导致开发商倦怠。

The problem then becomes: how do we convey this to others.

问题就变成了：我们如何将其传达给他人。

解决方案 (The Solution)

A more accurate estimation would be that Person B has 30 points of actual work compared to Person A who has 10 points. This is calculated using the table below where the actual amount of work is the result of multiplying the story’s Fibonacci complexity by a linearly increasing scaling factor.

更为准确的估计是，人B有30分的实际工作，而人A有10分。 这是使用下表计算的，其中实际工作量是将故事的斐波那契复杂性乘以线性增加的比例因子的结果。

The framework: simply estimate the complexity of a feature, then multiply it by the scaling factor, and use the result to calculate the actual amount of work required to complete the feature without taking shortcuts. If the amount of work cannot fit within a sprint, break up the ticket until it does. If shortcuts can be taken and repaid later, do so but make a debt ticket to repay it. Make sure to communicate this debt ticket to management so they understand the costs of taking shortcuts.

框架：简单地估计功能的复杂性，然后将其乘以缩放因子，然后使用结果来计算完成功能所需的实际工作量， 而无需采取捷径 。 如果工作量不能满足冲刺的需要，请分拆工单，直到可以。 如果可以采用快捷方式并在以后偿还，则可以这样做，但要开一张债务票以偿还它。 确保将此债务单传达给管理层，以便他们了解采取捷径的成本。

But…points vary from person to person

但是……点因人而异

One common reason why point estimations are considered inaccurate and why teams stop doing them is because every developer has a different level of experience, aptitude, and perspective. What’s often a 2 pointer could easily be a 3 pointer and vice-versa depending on the person. This is often the case for newer teams or teams switching to sprints so management finds it confusing and unpredictable. However as the team becomes more experienced and develops a rhythm, the Fibonacci complexity estimation will improve in accuracy over time.

认为点估计不正确以及团队停止进行点估计的一个普遍原因是，每个开发人员都有不同的经验，才能和观点。 2指针通常很容易成为3指针，反之亦然，具体取决于人。 对于较新的团队或切换到冲刺的团队通常是这种情况，因此管理层发现它令人困惑且不可预测。 但是，随着团队变得越来越有经验并发展出节奏，斐波那契复杂度估计将随着时间的推移而提高准确性。

回顾性事后 (Retrospective Hindsight)

It’s no wonder why teams are always missing their sprint goals — they are doomed to fail without management truly understanding why. The developers know why: there’s so many subtle nuisances and scope creep that often arise as the feature grows in complexity — but it’s difficult to anticipate and plan for them. In retros, teams will undoubtedly end up talking about the same underlying issues over and over again rather than actually using retro to improve the agile and estimation process. The psychological impact to team’s morale becomes noticeable and detrimental. Leadership by this point may get involved — even if things are going well because deadlines have been missed and quarterly roadmaps are thrown out the window.

难怪团队为什么总是错过他们的冲刺目标-他们注定要在没有管理层真正理解为什么的情况下失败。 开发人员知道原因：随着功能的复杂性增加，经常会出现许多细微的扰动和范围变化，但是很难为它们进行预期和计划。 在回溯中，团队无疑将一遍又一遍地谈论相同的潜在问题，而不是实际使用回溯来改善敏捷性和评估过程。 对团队士气的心理影响变得明显而有害。 到那时，领导才能可能会参与进来-即使事情进展顺利，因为错过了截止日期，而且季度路线图也被抛在了窗外。

Generally I’ve noticed that these issues begin to arise with 3 point features and frequently occur with 5 and 8 point stories. The amount of work required to complete those larger features often requires many hidden tasks such as refactoring code, handling edge cases, discovering and addressing race conditions, and debugging issues discovered in code review and QA. Not only that but resolving these issues often involves other people who are already busy themselves and thus causing downtime from blockers. This downtime is very disruptive to flow; is mentally taxing due context switching; and requires waiting time for replies and impromptu meetings to reach a decision. These hidden costs would be accounted for during the estimation by the framework and would be much better for psychologically framing how scalable the architecture is and how well the team is doing.

通常，我注意到这些问题开始出现在3点要素上，并经常在5点和8点故事中发生。 完成那些较大功能所需的工作量通常需要许多隐藏的任务，例如重构代码，处理边缘情况，发现和解决竞争状况以及调试在代码审查和QA中发现的问题。 不仅如此，解决这些问题通常还涉及其他本来就很忙的人，从而导致阻塞者停机。 这种停机时间对流量造成很大的破坏； 在精神上使适当的上下文切换费劲； 并且需要等待时间才能做出答复和即席会议。 这些隐性成本将在框架进行估算时予以考虑，并且对于从心理上确定架构的可伸缩性和团队的工作状况将更好。

配对编程 (Pair Programming)

One solution to alleviate downtime and improve estimation is through pair programming. It is often much better to tackle problems and design solutions together where you can help catch fallacies that the other person may not realize. You’ll discover issues sooner, learn A TON from each other, spread domain and technical knowledge across the team all while building friendships along the way.

减少停机时间并改善估计的一种解决方案是通过对编程。 通常在一起解决问题和设计解决方案要好得多，这样您就可以帮助捕获其他人可能没有意识到的谬论。 您将更快发现问题，彼此学习一顿，在整个团队中传播领域和技术知识，同时一路建立友谊。

结论 (Conclusion)

My takeaway to any reader is to try it out. If humans are great at one thing, it’s that we are all great at underestimating. This framework accounts for that — it accurately estimates how complex a new feature is and how much work it will take to build while conveying the hidden costs of building larger features to management. Try it out and let me know what you think.

对所有读者来说，我的主要收获是尝试一下。 如果人类在一件事上很出色，那就是我们所有人都在低估自己。 这个框架可以解决这个问题-它可以准确地估算新功能的复杂程度，以及将要构建的工作量，同时还要向管理人员传达构建较大功能的隐性成本。 尝试一下，让我知道您的想法。

翻译自: https://medium.com/swlh/why-the-fibonacci-point-system-is-terrible-for-sprint-estimations-385d2d4dc7b2

scrum打分规则斐波那契