我来自 XP 背景。我非常了解这个过程，并且有扎实的工作经验。我发现它是开发软件的最佳方式。
我发现自己处于某种流程医生的位置，这产生了很多自我检查和对自己理解的重新评估。
我听到的一个很常见的事情是，有些作品不能变成故事。我个人不相信这一点。借口包括
这个问题是为了获得提示、提示或建议。
我正在寻找关于如何解决这些和类似的感知问题的提示、技巧和建议（如果你能想到的话，还有更多）。
我将标记关于如何绕过不会写故事的用户/开发人员的信息最多的答案，并解决他们为什么不写故事的许多借口（我只列出了几个，还有更多）。
以下是我收集的一些资源，可能会有所帮助：
Too big or too complicated, there is always a way to put a story on diet (maybe you won't obtain the final result in one iteration but this doesn't mean you can't and, well, there will be more than one iteration).
所以基本上，你的问题是“如果人们声称任务对于用户故事来说太大了，我该怎么办，并且无法拆分。
根据我的经验，几乎任何问题都可以拆分。询问他们是否可以实现简化版本，省略高级功能，甚至在某些地方使用默认值；基本上任何可以在一次迭代中产生有意义（即可测试）结果的东西。
请记住：迭代的目的不是提供完整的功能，而只是提供有用且可测试的功能。
这种拆分可能很困难，但它迫使您首先考虑您真正需要的东西，这非常有价值。开发人员可能会抱怨它（我自己经常这样做:-)），但这确实是必要的。将大任务分解为可管理的用户故事是所有敏捷方法的核心。
也就是说，如果任务真的、真的、真的无法分解（想想研究环境中的复杂数学算法，甚至需要数周时间才能理解其基础知识），那么你的迭代就太短了。迭代需要足够长的时间才能产生有意义的结果。如果您的大多数问题都非常困难，以至于需要 2-3 个月才能完成任何事情，那么这就是您的迭代长度。但我从未见过真正如此的项目......
不会写故事的用户/开发者
用户不应该编写用户故事。他们不应该告诉你用户故事。你可以期待他们谈论他们的工作方式、困扰他们的问题以及他们希望有什么来促进他们的日常工作。
轮到你，你应该听他们做笔记。如果他们允许，请使用录音机或照相机。然后，当您重播收集的信息并确定您所谓的用户故事时，您可以将其带回。您与团队讨论它们，当您达成协议时，您可以在开发中定位用例。
开发人员扮演什么角色，取决于您。如果他们只是编码人员，他们就不会参与这个过程。如果他们部分充当顾问，那么他们会帮助定义用户故事。
通常当你得到“它太大了”时，他们真正想说的是“我只有一个模糊的想法这应该如何工作”。您需要与他们合作以更好地定义它，直到可以将其拆分为更易于管理的逻辑部分。
“算法规范”问题很常见。
许多人更喜欢编写代码，并不真正关心用户是谁或他们做什么。
我试图通过问这些问题来让他们集中注意力。
信息-决策-行动。
我们只编写软件来准备信息以供人们做出决策，以便他们采取行动。
如果这不是重点，那么故事就会失控。
Its basically the duty and responsibility of the product owner. And there can be any requirements/task that cannot be split into User Stories. I found many such discussions on SCrum Master Forums
If development team claims that the story is too big and can not fit within the sprint.. take their feedback and try to split the story with must have and nice to have tasks and try to split it based on that.
check this flowchart.. can be a help: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf