待办事项优化（以前称为修饰-但显然在某些国家这个词的含义有所不同）是Scrum实践中结构最少的。 积压细化可能会变得混乱！
是什么使积压细化感到不舒服？ 我们该怎么做才能使这些会话更流畅？
待办事项优化会议有两个主要目的：
- 明确要求
- 优先工作
简单吧？ 哪里出错了？ 让我们看一下“积压细化”在哪里误入歧途，以及您可以对此做些什么。
明确要求。 在过去，业务合作伙伴将其要求写下来，将其编译为一个大文档，然后将其传递给开发团队。 没有太多的协作，因此，我们遇到了延迟和Frankensystems。 协作定义需求需要花费一些时间，而且还没有一个整洁的过程，至少目前还没有！
如果您想“由产品负责人决定”，那么我想知道您是否在一个真实的组织中工作。 对于任何给定功能，大多数组织都有多个利益相关者，更不用说可以确定其技术可行性的人员了。
以下是一些典型的待办事项优化陷阱：
陷阱1：团队在圈子里说话 。
团队四处走动，讨论功能的行为方式。 如此多的信息被抛到了一起，以至于没人能看清混乱的情况。
你能做什么？ 我建议使用“对话映射”来处理共享信息和决策过程。
陷阱2：需求/用户故事具有团队无法控制的外部依赖性
当您遇到需要外部各方配合的用户故事时，由于他们的工作重点可能与您的工作不符，这确实会使您烦恼。 在这里，我的建议是从依赖团队获得所需的知识之前不要开始任何事情。 “但是我们想领先于游戏”。 不，你没有前进，你正在制造浪费。 为相关性写一个占位符故事，完成后就可以处理故事了。 否则，您将得到一堆半完成的故事，并且没有任何有价值的东西可以显示。
陷阱3：合适的人不在讨论中。
我们需要主题专家的信息，但尚无这些信息。 再说一次，不要再努力了。 您将不得不再次进行重新访问，这很浪费。 找到您需要的人，然后进行讨论。
陷阱四：我们的用户故事太大
“我们写了这个不错的故事，但后来开发人员告诉我们，这个故事太大了。”团队随着时间的推移，需要适当地调整规模。 没有合适尺寸的公式。 您将不得不拆分它。 这是一个有关故事拆分的小图表。 故事分解图我有团队将一个故事分解为400多个故事。 我问他们“瀑布会发生什么？”的回答是：“要完成这个单一要求要花一年的时间。”黑暗的一年！ 拆分它，现在我们可以获得反馈。
您在待办事项优化会话中遇到了什么？ 让我们在评论中知道！
