许多在敏捷环境中工作的UX专业人员感到沮丧、过度劳累，并且在满足业务和用户目标方面效率低下。敏捷的快速、有时间限制的节奏是产生这些负面情绪的主要原因。

敏捷对UX并不容易．当面对堆积如山的设计要求时，说“不”是不可能的，管理人员通常会将用户体验人才分散开来跨越众多的团队和项目。

成功的敏捷开发需要整个团队的全力参与，包括用户体验设计师。但是在多个不同的敏捷项目中工作的用户体验设计师很可能会失败。当制作原型是一种生存手段时，深思熟虑的设计解决方案和用户体验最佳实践往往被搁置一旁。结果，不仅最终产品会受到影响，用户体验专家也会精疲力尽，变得不满意。

跟踪UX团队的能力(即给定时间段内可完成的最大工作量)的经理可以更有效地分配UX资源。有了能力值和准确的工作估计，管理者就可以做出良好的决策，并与涉众进行富有成效的对话，讨论他们的团队实际能够承担哪些任务，以及如何最佳地划分请求的优先级。

在开发之外评估UX工作

敏捷开发过程中的基本实践是通过将故事指向分配给每个用户故事或功能来估算工作。传统的Scrum团队通常选择单一估计，以代表团队成员之间共享的努力水平，无论纪律如何。这种练习理论上听起来很好。

然而，在许多情况下，对用户情景的单一评估并不能很好地代表用户体验的工作。UX工作可以与开发工作明显分离。以撤销功能为例。对于UX来说，它可以是一个快速的按钮设计，但对于开发人员来说，确保返回正确的数据可能需要更多的努力。

使用不同的工作评估，一个用于用户体验，一个用于实现，在某些情况下更现实，并允许团队适当地计划他们的工作。

使用两种不同的工作评估的一个主要缺点是，它可能需要在用户体验和开发之间进行更多的协调，但这并不意味着团队成员不同步。通过深思熟虑的沟通，特别是产品经理、开发人员和用户体验团队之间的沟通，团队成员可以朝着相同的目标努力，同时更有效地利用他们的才能。

对于许多团队，尤其是那些构建复杂系统的团队来说，分离UX和交付工作流程是一个常见的做法。（实际上，双轨敏捷项目已经是十年最佳实践．)这种分而治之的方法允许来自每个规程的成员贡献足够的时间来处理当前特性，从而提高效率。如果在您的组织中，UX工作和交付工作主要是并行进行的，那么对于两组来说，分别估算每种工作类型所需的工作量是很有好处的。

然而，如果你的Scrum团队为每个用户故事分配了一个数字来表示团队的努力，那么在UX工作中继续这种做法是完全正确的。事实上，它是理想的，因为沟通中断的风险降低了。

计算用户体验速度

在评估工作时，UX组经常借用开发团队常用的尺度。例如，不同的UX用户故事可能估计1、2、3、5、8、13、21个故事点。这些值表示的相对大小UX用户故事．例如，一个估计需要8个故事点的项目比一个估计需要2个故事点的项目需要多4倍的工作。

假设您的UX团队的容量是一次迭代的50个故事点。基于这个值，您可以确定您的团队可以投入多少UX故事。在这个例子中，如果一个设计需要21个故事点，那么你已经在这个功能上花费了将近一半的设计预算，所以最好是值得的。

你使用哪种规模并不重要，只要你是一致的，并且能够有效地向团队之外的其他人传达它的意义。

如果您尚未估计以前，它可以感到令人生畏。您可能担心您的估计可能是不准确的。不要放弃。大多数UX团队发现，在估计精确之前需要多次尝试。随着时间的推移，估计变得更好。重要的是要知道您的UX-Team容量如何随着时间的推移而发展。随着团队成员获得经验并加强工作流程，他们可能会做得更多。

建立容量限制的优点

协商用户体验的承诺

了解你的团队的能力是一个有用的沟通工具，可以协商你可以承诺什么。它消除了在你的论点中关于你能做什么和不能做什么的知觉主观性的任何概念。

与其简单地说，“我做不到”，工作评估可以令人信服地说明，为什么接受一个请求，无论大小，都需要某种程度的重新谈判。预估消除了拒绝或推迟请求时经常附加的情感因素。

如果您有一个具体的数字来表示容量，您可以将其作为为什么某个特性可能需要等待或重新确定优先级的理由。当需要更多员工时，用户体验能力在与人力资源沟通时也很有用。

显示透明度

当用户体验的努力没有得到恰当的体现时，用户体验的价值就会降低。跟踪用户体验能力可以让用户体验在外人看来不那么模糊。所以当他们让你多做一件小事时，他们就会明白为什么你可能需要拒绝。

保持你的顶级人才

缺乏评估会导致糟糕的资源规划，导致UX专业人员感到工作过度和幻想破灭。当评估不存在时，很难拒绝或推迟工作。因此，许多用户体验成员感到压力，过度投入项目，这导致用户体验的整体影响被严重损害。

在不测量容量或理解项目所需的努力，要求UX设计师立即在多个团队上工作，因为DOMS UX进行故障。太多的组织通过将它们设置失败而失去了顶级UX人。更好地将UX努力放在关键的项目中，其中UX焦点将显着影响释放目标，而不是在许多举措中传播较短的结果，其中结果不太理想。

如果您需要雇用更多UX专业人员，请指向容量估计作为您的要求的原因。

回顾过去的估计

在您遵循了解UX故事的推荐后几个月后，您应该双击并比较过去估计，并在您完成的这些活动上花费的实际资源进行了比较。最有可能的是，估计有点偏离。始终估计，您可以确定，开发估计也不是100％。没有羞耻，没有每一个估计都击中靶心。

但在那些你的估计与现实相去甚远的情况下，你应该试着找出原因。什么早期的预警信号应该导致你增加一个确定的估计?或者什么问题在你开始工作之前看起来很麻烦，但很快就被解决了?

有时，个人特质会导致估计错误。但其他时候，你可以识别出一些系统性的问题，这些问题导致估计在特定情况下始终是错误的。发现这样的条件可以使您将来的估计更准确，从而改进ux资源分配的管理。

结论

保持独立的UX用户故事并不是UX成功的必要条件。如果您在团队成员(和管理层)之间已经有了很强的沟通，那么跟踪用户体验工作就不是关键了。然而，如果管理UX工作感觉很随意，那么UX用户故事可以对您有利。

敏捷依赖于沟通速度的评估。用户体验评估允许您使用其他敏捷成员理解和相关的术语进行交流，从而使您更有效地协商用户体验承诺。

在我们的网站上获取更多关于如何在敏捷环境中实现用户体验的技巧精益UX和敏捷研讨会,我们的有效的敏捷用户体验产品开发报告．