我们是一个由3名开发人员组成的小团队（2名经验丰富，但对这一特定业务部门来说是新手）开发功能复杂的产品。我们正在使用Scrum并在每个sprint结束时进行演示。很明显，功能团队有很多想法，但这些想法并没有很好地传达给开发团队，演示提出的问题多于答案。
您是否有任何关于提高功能人员输入质量的建议？
进一步的信息：我认为问题的一部分是没有规格或用户故事。就个人而言，我认为他们需要写下某些要求 - 他们应该写下什么样的东西以及敏捷过程中的复杂性？
您是否尝试过与客户合作来定义/制定验收测试？ 使用Fit之类的东西来进行这些测试 - 会产生更好的规格，并迫使客户考虑真正需要的东西。锦上添花是这个过程结束时的即时文档可执行规范。
当然，如果您的客户可以使用并且对这种方法持开放态度。试试看！
如果不是（这似乎是大多数 - 因为它的工作量较少） - 日历闪存'他们 - 每周安排会议/电话会议，直到他们像金丝雀一样唱歌:) +1 to Dana
有时，从人们那里获取意见的最简单方法就是强迫它们离开。我的公司在一个项目中使用了SCRUM，很快发现当人们已经知道他们在做什么时，他们往往会保持自我。我们最终组织了每周一次的会议，要求团队成员展示本周学到的东西。它被迫，但它运作得很好。
我非常相信用例，详细说明系统行为以响应用户操作。总的来说，这些可以构成一组松散的需求，并且在SCRUM环境中可以帮助您确定用例的优先级，这将形成特定sprint实现的功能。
例如，在与您的职能团队交谈后，您会识别出15个单独的用例。您优先使用用例，并决定计划5个冲刺。在每个sprint结束时，您将通过演示产品来完成Sprint期间实施的用例，并注意反馈和修改用例。
我知道你称之为功能性人的人是产品所有者，对吧？
我认为部分问题在于没有规格或用户故事。就个人而言，我认为他们需要写下某些要求 - 他们应该写下什么样的东西以及敏捷过程中的复杂性？
实际上，没有任何规格你也可能没有对积压的验收测试。你应该让PO写下用户故事，我喜欢“作为一种用户类型 - 我想 - 一些目标 - 所以 - 某些原因 - ”。形成。请记住，用户故事应该是投资 - 独立，面议，对用户或客户有价值，可估计，小和可测试。必须将验收测试与故事一起编写，以便团队应该知道故事必须能够做什么才能完成。
请记住，随着产品的发展，预计PO会在看到工作产品时有想法。这不是一件坏事，实际上它是你通过敏捷可以获得的最好的东西之一。您需要注意的是，这些想法应该包含在产品积压中，并且需要由PO优先处理。并且，如果它是必要的并且将为客户增加价值，那么应该计划在下一个sprint中构建该想法。
来自功能团队的人员应该成为团队的一员，并且可以回答有关您正在添加的功能的问题。
如果Backlog项目不够详细，您如何估算它？
您可以建立一个规则，即无法计划没有明确接受标准的Backlog项。
如果让功能团队的某个人充当产品负责人，确定，选择和优先处理Backlog项目，和/或作为域专家更好。
此外，确保功能团队和开发团队中的每个人都说同一种语言，以避免误解;见ubiquitous language。
跟踪大多数等待功能团队的答案的时间，以及浪费时间来开发不必要的功能或重新处理现有功能，以便它们符合要求。
他们参加了站立会议吗？
您可以建议在每个（或部分）代表处找一个代表，在冲刺结束之前要求他们提供意见
你在做单口会议吗？你有烧毁图表吗？我认为这两个方面对你有很大帮助。
我推荐这本书“Practices of an agile developer”，它充满了关于如何让scrum团队成功的建议。它还提供了如何让产品所有者/客户更多参与以及如何使整个流程滚动的良好提示。这是值得恕我直言的钱。
我同意你需要某种要求（用户故事或其他）。
我可以给出的一条建议是与功能团队一起使用某种视觉辅助工具。当客户有很多想法（如你所说）时，他们通常也会看到一个特征是什么样的，当开发的产品不适合这种视觉想法时，它会产生很多疑问，即使它确实如此。在功能上工作。
在与客户讨论功能时，我尝试非常直观。在板上画草图，甚至口头描述什么样的东西。试图找到一个共同的视觉形象。然后，您可以拍摄草图的照片并将其用作文档的一部分。
另一个建议是尽可能缩短您的冲刺速度，以便您进行更频繁的演示。但是你可能已经这样做了，因为你没有提到你当前的冲刺持续时间。