团队不断未能达到冲刺目标

我们是一家只有一种产品的小型软件公司。

我们使用scrum，我们的开发人员选择他们想要包含在每个sprint中的功能。不幸的是，在过去的18个月中，该团队从未交付过他们致力于冲刺的功能。

我已经读过很多帖子/答案，它们都说“软件完成后立即完成工作，这无助于……给团队施加压力，让更多人参与其中， ……”我已经收到一位开发人员针对如何提高冲刺成功率提出的类似反馈。哦，是的，我们确实使用回顾。

我的问题基本上是：

寻找开发人员质量问题的公平时间是什么时候？

我开始认为，如果您选择自己的工作/功能并且仍然无法使每个冲刺都失败，则-您将无法监督自己代码的复杂性；-或代码是如此复杂，以至于没有人能够监督复杂性。

我想念什么吗？

您首先应该问，“谁在乎”？

完成sprint感觉不错，并且在某些公司中会导致Scrum父级产生cookie。但是最终的考验是公司是否达到了目标。

以上是有趣的。如果公司在从未完成冲刺计划的内容的情况下成功了，那么您最好使用看板：对积压进行排序，处理最重要的事情，而不必担心已定义的迭代。

定义的迭代的价值之一是推动流程改进（或以某种心态赶走表现不佳的公司）。你现在不明白这一点。因此，您可以采用流程的其余部分来改进流程（并最终完成冲刺），也可以决定自己喜欢自己拥有的东西。

我想念什么吗？

是！

您花了18个月的时间 -或进行回顾回顾，冲刺了36个冲刺的某个地方，但是不知为何无法解决？管理人员未持有的团队负责，那么他们的管理人员未持有他们负责对未持有团队负责？

您错过了您的公司普遍无能的情况。

因此，如何解决它。您（开发人员）不再致力于太多工作。如果故事太大而您无法做到，那么您需要将故事分解成较小的块。然后，您要让人们对完成工作负责，他们所说的将要完成的事情。如果事实证明，他们只能在每个sprint中完成一个微小的功能，然后找出原因并使其变得更好（这可能需要更换开发人员）。如果事实证明他们无法弄清楚如何进行合理的工作量，您可以开除他们。

但是在此之前，我将看一下让事情持续这么长时间的管理层，并弄清为什么他们没有做好自己的工作。

我想建议您做些小改动，并尝试看板而不是Scrum几个星期。它可能对您的团队更好。

Scrum通过限制冲刺中可用的工作时间来提高生产率，而看板则通过限制活动的并发问题的数量来提高生产率和速度。时间估计不再是该过程的一部分。（来源）

简而言之，看板是什么？

看板还是用于提高效率的组织工作的工具。像Scrum一样，看板鼓励将工作分解为可管理的块，并使用看板板（与Scrum板非常相似）在工作流程中可视化该工作。Scrum限制了完成特定数量的工作（通过冲刺）所允许的时间，而看板限制了在任何一种情况下的允许工作量（只能执行许多任务，而可以处理的任务也是如此） -做清单。）

SCRUM和看板如何相同？

Scrum和看板都允许分解和有效完成大型和复杂的任务。两者都对持续改进，工作和流程的优化具有很高的价值。两者都非常关注高度可见的工作流程，使所有团队成员始终了解WIP以及即将发生的事情。

查看此链接的其余详细信息

我的问题基本上是：什么时候在开发人员的素质上寻找问题

您的帖子中没有足够的信息来回答该问题。没有办法知道他们是由于不称职而失败，还是因为他们致力于做超出合理范围的工作而失败。

如果我是一个非常有天赋的开发人员，在一个由一个非常有天赋的开发人员组成的团队中，而我们未能在两个Sprint（或36！）中完成X故事，那么我们是否没有能力？或者，我们只是在估计中吸吮？这取决于故事是“创建登录屏幕”还是“安全地送男人去火星”。

问题始于错误的故事和/或错误的估计

估计很难。真的很难。人类对此深表歉意，这就是为什么Scrum让我们将工作分解成不超过一两天的区块，并组装这些区块的小小组，我们确定我们可以在短时间内完成。块越大，时间间隔越长，我们的估计就越不准确。

您的商店是什么样的？他们写得好，接受标准好吗？他们每个人都足够小到可以在短短几天内完成吗？没有写得很好的故事（这是整个开发团队（包括产品所有者）的错），就不能指望团队做出正确的估算。

糟糕的回顾使问题更加复杂

看来您做错了，是您没有在利用回顾。您已经走了18个月而没有解决此问题，所以团队可能没有注意到该问题，或者没有在回顾中解决该问题。

每个回顾会议是否以至少一个行动项目结束，团队才能采取，以便在下一个冲刺阶段做得更好。是否每个回顾都包括讨论上一个冲刺中的操作项，以查看它们是否已完成以及是否有效？

解决方案不是责怪，而是学习

第一步应该是停止寻找责任，而是开始努力改善团队。您的团队可能并不无能，只是在评估和计划上很差。强迫团队完成冲刺，即使那意味着他们选择一个故事并提前一周完成。如果他们不能做到这一点，那么要么他们无能，要么故事太复杂。这个问题的答案应该很明显。

一旦他们能够完成一个故事，他们将合理确定地知道他们可以在一个冲刺中完成X个故事点。简单的数学将有助于回答他们是否可以编写更多故事。

持续改进是解决方案

一旦他们在冲刺中完成一个故事，就该看看他们是否可以做两个。泡沫，冲洗，重复。当他们开始未能达到冲刺目标时，您已经发现了其估算能力的极限。返回上一个故事的故事点数，并坚持一段时间。

在任何时候都应认真对待回顾。如果他们没有完成冲刺，请找出原因并采取行动。他们有太多未知数吗？他们的技能组合是否错误？他们的估计有多好？如果他们估计一个故事是X点，那么它是否需要与价值X点的先验故事相对等量的工作？如果不是，使用它来调整故事的重点。

您说您“使用回顾”。但是，在这些回顾中，团队实际上做了什么？由于您已经走了18个月，却没有一次解决流程的这一方面，所以我猜答案是：没有什么非常有用的。

对我而言，回顾是该过程中最重要的部分。抛弃或更改您想要的所有其他有关Scrum的东西（当然，在回顾过程中需要团队的相互同意），但要承诺定期花时间讨论该流程对每个人的工作方式，分享有效的方法以及未完成的工作不起作用，并提出改善意见。继续尝试逐步改善每个冲刺的过程，迟早您可以拥有一些效果很好的方法。

在您的情况下，该过程似乎无效。由于未达到冲刺目标，因此谨慎地回顾为什么会这样。显然，团队为冲刺花了太多工作。但是为什么他们要这么做呢？

• 他们是否低估了工作的复杂性？
• 管理层是否给他们施加了压力，使他们承担的工作量超出了团队认为可以处理的范围？
• 他们是否有太多的中断/紧急情况，使资源无法完成计划的工作？
• 他们是否遇到了延迟工作完成的瓶颈（例如，等待外部设计团队提供的资产）？
• 甚至：一个或多个团队成员根本没有能力做这项工作吗？

这些是团队在过去18个月的每个冲刺中都应该问自己的问题。然后，有了答案，他们可以提出建议的流程改进，以进行下一次冲刺的试用。这些可能包括：

• 在下一个冲刺中减少工作量（du！）
• 在估算时要更加保守
• 告诉谁在迫使我们做更多的工作，因为我们已经承担了超过现在能完成的工作
• 更好地管理中断并在下一个冲刺中调整工作量以适应不可避免的紧急情况
• 修复瓶颈或针对无法避免的问题进行计划
• 不要将故事分配给无法完成任务的团队成员（分别，从管理层的培训，指导到解雇，找出管理层的回应以应对表现不佳的团队成员的情况）

在过去的18个月中，每一次冲刺都应该发生这种对话。这不是在向团队施加压力或添加更多资源，而是关于使用回顾来持续改进您的流程。这显然不在这里发生。

您可能会认为，在第15步冲刺中错过目标的情况下，团队会在回顾中讨论很多次，以至于他们决定只为达到一个完整的目标而采取最小限度的冲刺目标。到第25个未完成的sprint为止，我只需要更改一个字符串就可以完成sprint。如果团队无法在冲刺中解决问题，那么问题甚至会比您忍受的严重。

需要明确的是，正如这里的一些人已经指出的那样，冲刺目标只是预测，而不是铁定的承诺，缺少目标本身并不表示做出错误的预测。优秀的团队可能会错过很多目标，因为他们是糟糕的预测者，而糟糕的团队可能会实现每个目标，却无法实现任何实际价值。但是，如果您连续18个月对同一方向的预测有误，则该过程中的这一部分将无法正常工作。使用回顾来确定流程，使您的预测合理地接近团队可以提供每个冲刺的实际情况。

“软件是在完成后立即完成的。”

的确如此，但是对于开发人员开始执行的每个任务，组织中的每个人都了解每个任务的完成定义吗？

似乎最大的问题之一是Estimation，但是开发人员只有在他们具有明确且明确指定的“完成的定义”时才能提供实际的估算。（其中包括公司流程问题-例如用户文档，正式发行版上的工作包等）

高估会引起问题也就不足为奇了，因为大多数开发人员都认为，估算完成任务所需的时间是最难的问题。

但是，大多数开发人员倾向于在给定的时间段内合理地（尽管很乐观）对他们可以投入的工作量进行处理。

问题通常是，开发人员在处理不完整的信息时难以在任务和所需的总工作量之间建立关系，尤其是如果他们面临着为一个真正的巨大任务预先提出所有答案的压力。

这自然会导致时间估算与现实脱节，并且他们会忽略诸如构建过程和用户​​文档之类的内容。

在描述任务时，断开连接往往从一开始就开始。并且通常由非技术人员来编写需求列表，而又不知道需要多少工作量。

有时，高级管理人员会指定任务，而完全忽略公司流程问题。对于高级管理人员来说，定义测试，创建正式的发布版本或更新用户文档之类的事情只是神奇而无需时间和精力就可以了。需要。

有时项目在开发人员甚至没有编写一行代码之前就失败了，因为某个地方的某人没有正确地完成他们的工作。

如果开发团队没有参与达成共识的要求或捕获接受标准，那么这就是管理的失败-因为这意味着对代码和技术问题了解不足的人已经使业务满足了不完整的要求，并使该项目容易产生误解，示波器蠕变，镀金等。

如果开发团队参与捕获和达成需求，那么团队可能会失败，他们负责澄清细节（以及接受标准），即“交付结果是什么样？何时完成？” ）。开发团队还负责说NO的时候有方式与其它阻塞问题，或者要求仅仅是不现实的。

因此，如果开发人员参与了需求捕获：

• 团队是否有机会与产品经理坐下来，以澄清完成的要求/定义？
• 团队是否提出足够的问题来阐明隐含/假定的要求？这些问题多久能令人满意地回答一次？
• 在提供估算之前，团队是否要求接受标准（完成的定义）？
• 通常为每个任务捕获接受标准的程度如何？它是一个含糊不清，细节稀疏的文档，还是描述了有形的功能，以及措辞使开发人员可以明确地将其转换为测试？

很有可能您的团队的生产力不是问题。您的团队可能会竭尽全力进行开发。您的实际问题可能是以下一项或多项：

• 不完整和含糊的要求。
• 首先，需求/任务太大。
• 开发团队与高层管理人员之间的沟通不畅。
• 在将任务交给团队之前，缺乏明确定义的接受标准。
• 验收测试规范不完整或含糊/模棱两可。（即完成的定义）
• 分配/定义接受标准的时间不足。
• 开发人员没有考虑时间来测试现有的基准代码或修复现有的错误
• 开发人员确实测试了现有的基准代码，但在提供需求估算之前并未将其作为“ 阻塞问题”来提出。
• 管理层看到了问题/错误，并决定在编写新代码之前不需要修复错误。
• 开发人员面临着要占用其100％时间的压力，即使他们的20％（或类似数量）的时间可能被会议，分心，电子邮件等占用。
• 估计值是按照票面价值商定的，没有人调整错误或意外事件的余地（例如“我们决定这需要5天，因此我们希望它在8天内完成。”）。
• 每个人（开发人员和管理人员）都将估计值视为单个数字，而不是实际的“范围”数字-即
  • 最佳案例估计
  • 现实的估计
  • 最坏情况的估计

...列表的持续时间可能比这更长。

您需要进行一些“事实调查”，并准确找出为什么估算值始终与实际脱节。现有的基准软件是否不好？它缺少单元测试范围吗？您的开发人员是否避免与管理层沟通？管理层是否避免与开发人员进行交流？在“完成的定义”方面，管理层的期望与开发人员的期望之间是否存在脱节？

我建议重启团队的方法是，每个团队，每个冲刺选择尽可能小的故事，并完成一个故事，并且仅完成一个故事！

我同意其他海报，要么是团队能力不足，要么就是他们试图做太多事情。

从最小的东西，最精简的故事开始，并完成一次冲刺。让团队完成冲刺并取得成功，这将帮助他们了解如何确定时间和工作承诺的优先级。随着时间的流逝，团队将能够从事越来越多的工作，直到达到最高生产力。

您应该收集数据并根据过去的表现来建立置信度。

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

最简单的例子是持续不断的冲刺，例如每两周一次。估计团队将在两周内完成多少故事点。然后，在两周的冲刺结束之后，查看实际上完成了多少故事点。随着时间的流逝，您可能会看到估计15点，但只能完成10点。在这种简单情况下，您可以开始进行速度调整，因此每个冲刺仅计划10点。或者您计划完成预计工作的66％。

通过建立具有标准偏差的置信度水平，您可以告诉管理层：根据当前的项目目标，我们预计只有50％的信心可以在3周内完成，而95％的信心可以在5周内完成。

敏捷和Scrum背后的想法是建立一个紧密的反馈循环，以便您可以评估您的过程。您必须问“它在哪里分解了？”，因为它似乎已经完全分解了。

1. 计划您要做什么并列出清单
   • 这应该包括从积压的需要完成的项目中挑选项目。在将任何东西放入冲刺的待办事项列表之前，团队需要同意他们完全理解它，并大致估计完成冲刺所需的时间少于冲刺。
   • 理想情况下，待办事项按优先级排序（到业务），您可以按优先级排序。
   • 如果积压的项目太大，请将其分解为较小的块。然后将这些块分解成可以在一天或更短时间内完成的单个任务。
   • 不要期望这个计划容易或快速。
2. 在定义的时间内对列表中的项目执行（冲刺）
3. 回顾您的成就
   • 什么故事完了？
   • 如果没有完成故事，那么构成故事的哪些任务已经完成？
   • 如果没有完成任何任务，那么每个人上周一到底做了什么？上个星期二？等等-在这一点上，是时候进行自省了...

4. 解决问题（分析反馈并进行调整）

   • 完成的事情花了多长时间？
   • 是什么导致任务无法完成？
   • 团队成员是否将故事（功能）分解为可以在1天或更短时间内完成的任务？如果不是，请执行此操作并将其纳入待办事项列表。
   • 在冲刺期间对任务列表或任务列表上的项目进行了哪些更改？这是未完成的原因吗？如果是这样，请勿更改列表或功能。将更改的功能扔到待办事项列表上，直到稳定为止。
   • 如何将某些项目的大小和范围缩小为可以在sprint中完成的项目？选择一些小东西，例如日志记录改进，简单的错误修复，错别字，以完成一些工作，以便团队评估他们可以做什么。如果您无法执行此操作，请停止冲刺并重新计划。

5. 返回第一步，重复直到释放...

是否存在文档障碍，建立依赖关系的耦合问题，沟通问题，需求中的信息不足？...什么？开发人员是否花时间尝试学习新技术？他们是否在设计上花费了大量时间？在冲刺任务列表中是否包含学习之类的内容？

您是否认为您的团队认为他们每次回顾都隔离了问题？团队是否已采取措施纠正问题。团队是否没有回应，而管理层只是简单地决定了解决方案和行动方针？

在很长的时间范围内，系统地出现了问题，而不仅仅是开发人员。在某些时候（每年上涨之前）的球队（包括Scrum管理员）应该有人问过，是什么，无论多小，可我们完成了？

在您的情况下，回顾为时已晚。
您是否每天举行站立会议并真正从人们那里获得他们在过去24小时内所做的工作的状态？
Scrum主管是否使用这些会议来衡量每个开发人员针对其目标的进度？
您需要使用Scrum方法的一部分来监视进度。它应该使您深入了解人们在做什么。
他们分心了吗？花太多时间在咖啡上，或在SE / SO上帮助其他人，或阅读新闻，或进行无法解释的检查？还是他们真是低头，全力以赴，过度投入？每日视图应该给您一个好主意。这也有助于使开发人员专注于手头的任务，因此他们不必承认自己昨天没有做任何事情。
当然，如果他们在整个sprint中都报告了稳定的进展，但最终还是没有交付，那么他们就是在撒谎，这可能是新开发人员的时机。

估计完成复杂任务（例如编程代码）所需的工作量和时间很困难。正如Joel Spolsky所说：

软件开发人员真的不喜欢制定时间表。通常情况下，他们试图逃脱。他们说：“一切都会完成！”他们期望这样勇敢，有趣的歌手会减少老板的笑容，在随之而来的欢乐中，时间表会被遗忘。

但是，公司需要截止日期才能运营。正如乔尔（Joel）所建议的那样，尝试使用基于证据的计划，它将产生具有相关概率的时间估计，该估计可能与任何类型的风险相关。

Scrum做一些事情。

首先，它鼓励确定优先级。工作的提供者必须先说出他们想做的事情，而不是说“一切都同样重要”。

其次，即使还没有完成所有工作，它也会产生可用的产品。这就是在每次迭代结束时拥有“潜在可运输产品”的意义。

第三，它给出了更紧密的反馈回路。通过坚持在冲刺结束时“完成”事情，可以避免出现“ 90％功能已完成，但仅完成一半”的问题；在争取截止日期时，您可以将需要做的事情放在一边，这样看来您快要达到截止日期了，或者您可以伪造它。通过定义完成并坚持要完成的事情，您会知道某事是否比看起来早而不是以后难。

第四，它通过将详细的计划移到工作附近来避免库存。对事物进行远距离规划是一种库存形式：花费在无法出售给客户或客户无法立即使用的资源上的资本。这样的库存可能会腐烂（计划在脚下改变，新信息使其过时），与需求不符（结果是我们不需要分布式网络，因为使用它的东西是不值得的），并降低了装运商品的价值（如果在过去的一年中，您有一半的时间花在了对明年及以后的计划上，那么如果您为现在准备的东西工作，则本来可以得到两倍的发货量）。如果您可以使计划更接近执行而不会造成损失（麻烦！），则可以减少库存。

这不是解决这些问题的唯一方法。您似乎在使用scrum，它为开发人员在每个时间段内提供工作流，并定期添加要执行的新工作并检查进度。

这是使用Scrum式模式的有用方法。它使工作保持顺畅，使计划与生产保持紧密联系，提供一些反馈循环，等等。它甚至具有的优势在于，它不会扭曲开发和测试以匹配系统（如果最好在工作完成的前提下进行最好的测试） ，尝试在相同的sprint中完成工作并进行测试会迫使sprint的后端不涉及新开发！）

未能准确地将他们要做的事情放入冲刺中，并不表示您的开发人员没有做得很好。这意味着他们没有从头开始遵循SCRUM，而是使用框架的某些部分。

如果他们将对每个sprint的投入减半（或减少了四分之一），但保持其他所有内容不变，那么他们完成的工作将比对每个sprint的投入多！您将产生相同数量的代码。显然，“冲刺失败”不是重要的部分，因为那只是内部流程的细节。公司的目标是把狗屎做好，把狗屎做好。除非您的目标是某种ISO流程认证，否则不要遵循某些特定流程。

该过程存在于完成目标的前提下。

在另一方面，因为他们没有关注SCRUM的规则，你没有得到同样的反馈。您应该检查结果，以查看所产生的缺陷类型是否是SCRUM旨在解决的缺陷；有没有像僵尸一样永远存在的故事，直到深夜被杀死？有没有看起来似乎很容易的故事，它们爆炸了，并且回顾起来不值得进行全部工作？产品在您需要/想要运输的时候确实可以运输吗？

如果您尚未定义“完成”的模样，那么“完成后立即完成软件”是失败的秘诀。

大多数工程师将尝试提供最佳解决方案，但这很容易导致镀金，尤其是对于经验不足的工程师而言。管理的唯一职责是准确定义目标位置并保持工程师朝该方向前进。工程师将经常尝试进行侧弯以改进功能，并且取决于管理层来决定侧弯是否可以长期加快速度，或者是否只是在进行改进以达到同样的改进效果。

敏捷开发的重点是，每一项新工作都应与满足该冲刺要求的性能一样好，并且没有更好的选择！！！！ 是的，这是我可以在StackOverflow中添加的最大重点-仍然不够重点。如果您发现人补充说，不是必需的东西，正确的第二个这时就需要对如何正确地做敏捷开发培训。

哦，是的，我们确实使用回顾。

哦，很好，您知道您的团队为什么会失败吗？您已经有36次机会讨论什么有效和哪些无效，因此Scrum管理员应该完全了解如何解决问题，对吗？

根据您的描述，我有一种直觉，即您的公司陷入了“ SCRUM使我们富有生产力”的思想。 事实是，SCRUM无法提高您的生产力。而是，它是一种工具，可帮助您以发现开发现实的方式来提高自己的工作效率，而开发现实常常被管理层和开发人员所忽视。

Scrum管理员认为团队潜在的问题是什么？他们是否不断分配两倍于他们可以处理的工作？如果是这样，Scrum主管应该轻轻地建议他们减少工作量，因为Scrum主管可以查看团队的速度。

寻找开发人员质量问题的公平时间是什么时候？

您确定是问题所在的那一刻，就是应该在开发人员素质上寻找问题的时候了。这不是SCRUM创建的新问题。这是企业的现实。与传统方法相比，SCRUM应该为您提供有关团队成员能力的大量信息。 您应该知道问题是“软件开发人员不够好”还是“管理期望不切实际”，其程度要比传统方法更好。 现在是时候让管理层做最擅长的事情了：找到合适的人选，以便公司赚钱。如果您不知道问题出在哪里，那么请想象一下，如果没有所有这些回顾，要说出来将是多么困难！

如果您认为员工可能足够好（这意味着聘用并不是管理层的错误），那么我的建议是开始在框外思考。如果工作尚未完成，请考虑为开发人员更改工作的形状。我发现达到冲刺完成截止日期的最简单方法之一就是调整“完成”标准，以便无论结果如何完成，您都会对结果感到满意。这样完成成为重言式。

这给管理（尤其是SCRUM管理员）带来了责任。 诀窍是编写任务，这些任务如果完成，将非常有价值，但是如果不完整，它们仍然可以为公司提供足够的附加值，值得他们付出薪水。 18个月后，我希望您的回顾会教给您一些知识。如果还没有，那么您应该以失败的故事的明确意图写这些故事，以发掘您公司中的错误并予以揭露。考虑到公司对开发团队的挫败感，这将为公司提供大量有价值的数据。正如您所问，问题确实可能是开发人员。或问题可能是您至今不了解的公司思维方式中的病态！

如果确实是公司而不是开发商的问题，那么您从这些不完整故事中收集的信息确实比从成功案例中收集的产品有价值！可能是拯救您整个公司的信息！ 对于我来说，这似乎是非常有价值的信息，您可以使用SCRUM作为帮助您收集信息的工具。

“什么时候看开发商的素质公平？”

每时每刻。显然，有些人比其他人更有生产力，您不需要借口作为雇主来衡量他们的表现。

棘手的是如何做到这一点。我的建议是雇用一些经验丰富的承包商，与您的烫发团队一起处理烫发人员所估计的相同任务，并查看他们的工作速度是否更高。

这将使您与当前市场保持良好的对比，而不会陷入长期雇用的困境。

这也可能会给烫发小伙子们振作起来。

另外，如果他们抱怨承包商为了提高速度而跳过质量等，那将引发关于业务价值在哪里的对话。长期可维护性或短期产品已发货。

如果是长期的东西，那么它将迫使您对其进行量化，并根据需要将其放入sprint中！

已经有几个很好的答案。尤其是，错误的估计，过度的投入和/或计划外的工作是滑倒的常见原因。

但是我很好奇为什么“ [您的开发人员选择他们希望在每个sprint中包含的功能”。开发人员通常应该首先处理具有最高优先级的功能-优先级是业务决策，即，它应该来自产品所有者，作为业务利益相关者的代理。
（对此有一些例外。特别是，高风险功能通常较早就可以使用。在某些情况下，面向用户的功能可能取决于其他功能，例如“在实现X之前，我们确实需要添加数据库”。 ）

在另一方面，估计是技术决定的，应该不是由业务人员进行（或第二猜到）。您什么都没说-我提出这一点只是因为，根据我的经验，当开发人员选择要进行的工作时，商务人士通常会尝试决定需要多长时间。

听起来您的过程相当不正常。我建议至少暂时不要聘用开发顾问，因为这可能会对士气产生负面影响。但是，听起来您的组织可以在项目管理方面使用一些帮助。从那开始，我将聘请一位经验丰富的敏捷教练-如果不是为了中长期参与，那么至少要进行评估或“健康检查”。一个好的教练会告诉您您是否有表现不佳的开发人员，但至少这样，整个团队（而不仅仅是开发人员）都需要受到审查。

另一个观察结果：根据我的经验，如果您不遵循良好的开发流程，很难使Scrum作为项目管理方法成功。您正在执行自动化的单元测试吗？甚至更好的自动化验收测试？您的开发人员是否配对，或者您至少执行了频繁的代码审查和/或演练？您是否正在练习某种形式的持续集成？