管理峰值
我需要一些关于管理未知/峰值(功能/技术)的见解和想法。
我们有一个目前处于维护阶段的项目，主要是缺陷管理和有限的增强。我们还面临着多地点团队的挑战，其中一些人对产品的功能知识有限。
用这个,
-开发请求(包括缺陷和改进请求)通过HelpDesk/ Support进入，被记录和分类(为了准确性和完整性)，然后被PO作为Bug或故事转移到PB中。
-在sprint计划的时候，如果scrum团队不清楚bug或故事的功能/技术影响，团队就会创建一个峰值并包含在sprint中。
然而，经过分析，我发现
-在大多数情况下，在sprint结束时，调查是不确定的，
- scrum团队已经解决了最初的spike ticket，并为接下来的sprint创建了一个新的spike ticket。这个循环在多个sprint中持续了很长一段时间。
-我们的主要问题是可追溯性和向客户提供计划解决方案/实施日期的能力。
需要克服的一些建议是
-为了解决可追溯性问题，如果scrum团队在sprint计划中有顾虑，将原始的开发请求包括在sprint中，并在该请求中记录所有更新和发现
-确保非常严格的时间限制，如果有溢出，那么在整个开发团队中进行技术分类以解决此类问题
我希望我已经把问题讲清楚了。请问您对上述的最佳管理有什么想法?
非常感谢,
听起来好像在将工作计划成sprint之前需要对backlog进行更多的细化。如果开发团队不确定它的范围，或者他们按照完成的定义交付相应增量的能力，他们就不应该将工作引入Sprint Backlog。
为了适应这些细化会话，每个Sprint的范围可能需要缩小。在敏捷实践中，预测(并交付)一点比预测(并未能交付)更多要好。
谢谢你，伊恩，非常感谢你的时间。
我同意你关于需要减少冲刺范围的看法，是的，联合backlog改进会议将有相当大的价值。我会向团队中的POs和Scrum master建议这一点。我目前的职责是定义/审查/完善所有产品、项目和开发过程框架。
再次感谢您的宝贵时间。
伊恩，这是最新消息。
我已经和PO团队以及各自团队的Scrum master开过会，讨论了你们的反馈以及联合举办产品改进会议的价值。他们将从下一个sprint开始这些会议，我们在3个sprint之后再次会面以评估进展。
再次感谢您的反馈。