我正在为一些scrum团队寻找团队建设/培训活动。我想要的东西真正说明了团队在实现故事时的灵活性，以定义功能本身的范围和复杂性。大多数团队都有长期的瀑布式经验，习惯于有明确的规范。我正在寻找能够说明团队需要根据可用时间和资源改变自己建设范围的内容。
我在tastycupcakes.com找不到任何内容，Google也没有多大帮助。也许某人已经准备好了自己想要分享的东西？
编辑（响应评论中的请求）
假设团队已承诺构建故事，以便在分页列表中向用户显示数据以进行分析。验收标准可以很容易地实现，但不同的实现可能会提供额外的功能，例如包装具有内置排序和分组功能的第三方控件。
关键是，因为scrum时间窗口是绝对固定的，如果团队认为他们提前完成，可能会推动实施的范围，特别是如果某些技术设计证明问题少于想象。相反，如果某些任务花费的时间超过预期，团队可以缩短用户故事，同时确保他们提供的服务符合验收标准。
我试图摆脱的是当前的思维方式，即该功能的规格设置齐全，无论在什么情况下都是如此。
答案 0 :(得分：2)
我不认为由团队来定义故事的范围和复杂性。 PO的工作是定义接受条件，然后根据PO的描述估算大小是团队的工作。如果故事大小合适，条件通常都是非常严格的。这可能就是为什么你没有看到太多......
修改：
我不认为你的例子会改变我的答案。如果PO想要这种“附加功能”，例如排序等，他们就会在故事或其他故事中定义它。建造一些不需要的东西是浪费。花时间处理积压中低优先级的故事效率低下。敏捷的基础是构建所需的东西，并且只根据重要性来构建所需的东西。所以我不赞成开发人员添加“额外的好东西”只是因为他们正在特定的屏幕上工作。
这并不意味着您不应该查看待办事项中的所有故事，并根据将来需要的内容制定架构计划。
答案 1 :(得分：1)
我想我得到了你想要的东西，但如果我弄错了，请随时澄清。我的印象是你正在寻找一个练习，它将展示团队在使用用户故事时的实施细节的灵活性。
如果是这样，请尝试这样的练习。
将团队分成两组，并在他们之间拥有相同的产品负责人（如果两个PO都知道这个练习，你可以为每个团体拥有一个产品负责人。）
PO提出了一个虚构的故事，“作为BigSales Co的一名高管，我希望能够一目了然地看到哪些销售人员正在表演哪些不是，所以我可以将表演者与表现不佳者配对提高整体团队绩效。“上面的故事很清楚实现细节，但有一个非常明确的业务问题需要解决（如用户故事所应）。使用这样的故事，给团队30分钟的时间来处理满足用户故事的纸质原型。在此时间范围内，他们可以根据需要与PO进行互动。玩PO的人应该小心，不要给他们实施细节，而是留给团队决定，同时表达和澄清业务需求。
在30分钟结束时，让每个团队展示他们的解决方案并解释它如何满足用户故事。
这里重要的是，一旦两个团队都提出，两个演示文稿可能会有很大的不同，但两者都有效。这表明团队必须提供他们认为最佳解决方案的灵活性，而无需明确说明该做什么。
希望这有帮助。
答案 2 :(得分：0)
为了估算故事费用，团队期望与PO合作，至少在广义上定义该功能的要求。在您给团队的示例中，可以明确询问PO是否排序＆amp;需要分组功能。如果他们拒绝，由于PO在该阶段无法看到它的使用，那么在此基础上给出估计并根据该实施完成。没有考虑YAGNI原理上的这些附加功能。如果要求排序＆amp;随后出现的分组是由于人们使用产品的早期版本，这是另一个故事，并且估计＆amp;因此安排在积压中。故事的实现范围不会因为你在迭代中留下一些时间而改变 - 相反，你只需从积压中提取下一个优先项目并继续使用。
当然，在实施故事时，团队可以自由使用他们认为适合不断发展的产品的最具时间/成本效益的方法。如果这意味着使用具有附加功能的组件，即功能的超集，则他们可以这样做（除非这违反了非功能性要求），只要验收标准通过，但它们不应故意添加在未经请求的功能中，仅仅是因为他们在迭代中有一些时间备用。
答案 3 :(得分：0)
我的意见介于你对功能的适应性与剩余的时间进行调整之间，以及“只是满足验收标准，那就是”其他两位评论员的POV ......
在我看来，你们都应该回想一下用户故事的正式设置：
作为 -role - 我想要 -feature - ，所以 -aim - 。
鉴于所需功能的目的，开发人员可以更好地了解PO真正想要的内容。然后他可以提出其他想法并询问PO，例如：
嘿PO，如果你想 -aim - 那么我们为什么不做 -alternative / add to feature - 。那不是更好吗？
PO可能会同意并且故事是按照描述实施的，但在另一种解释中，或者故事可能会被改编。对我来说很重要的一点：
我希望你能分享我的观点; - ）
答案 4 :(得分：0)
良好的训练和有趣的团队建设练习是XP Planning game。
前提是产品所有者提供了视觉上的要求（如咖啡机，机器人），所有要求必须是可绘制的。开发人员必须提出要求。
有几个短的迭代（整个练习需要一个小时到90分钟，具体取决于设置时间），有趣的是看到沟通如何改进，并随着游戏的进行进行权衡。我在项目启动期间以及将团队转换为敏捷实践时自己运行了这一点，团队始终认为它非常有用和有趣。