我來自XP背景。我對這個過程非常瞭解，並且具有紮實的工作經驗。我發現它是開發軟件的最佳方式。用戶故事 - 無法做出用戶故事的問題
我發現自己處於某種過程醫生的位置，這使我對自己的理解產生了很多自我檢查和重估。
我聽到的一件很平常的事情是，有些作品不能成爲故事。我個人不相信這一點。藉口包括
這個問題是要得到提示，提示或建議。
我在尋找有關如何解決這些和類似感知問題的提示，技巧和建議（以及更多，如果你能想到它們）。
我會標記答案，如何繞過如何繞過用戶/開發人員誰不會寫故事和解決他們爲什麼不（我只列出了一些，還有更多）的許多借口最多的信息。
所以基本上，你的問題是「我能做些什麼，如果人們聲明一個任務太大了用戶的故事，不能分割。
以我的經驗，幾乎所有的問題可以拆分詢問他們是否可以實現簡化版本，省略高級功能，甚至可以在某些地方使用默認值;基本上，任何產生的東西都可以在一次迭代中提供有意義的（即可測試的）結果
請記住：迭代的一點不是提供完整的功能，而僅僅是有用的和可測試的功能。
這種分裂可能很困難，但它迫使你首先考慮你真正需要的東西，這非常有價值。開發商可能會喋喋不休（我經常做自己:-)），但這確實是必要的。將大任務分解爲可管理的用戶故事是所有敏捷方法的核心。這就是說，如果任務真的，真的，真的不能被分解（在研究設置中想想複雜的數學算法，需要幾周才能理解基礎知識），那麼你的迭代太短。迭代需要足夠長以產生有意義的結果。如果你的大部分問題都非常困難，需要2-3個月的時間才能完成任務，那麼這就是你的迭代時間。但我從來沒有見過一個項目，這是真正的情況......
「算法規範」問題很常見。
許多人更喜歡編寫代碼，並不關心用戶是誰或他們做了什麼。
我試着通過提出這些問題來讓他們關注。
信息決定行動。
我們只編寫軟件，爲人們準備信息做出決定，以便他們採取行動。
如果這不是重點，那麼故事就會失去控制。
用戶/開發誰不會寫故事
用戶不應該寫用戶故事。他們不應該告訴你用戶故事。你可以期望他們談論他們如何工作，困擾他們的問題以及他們想要促成他們日常工作的想法。
你反過來應該聽他們說話。如果允許，請使用錄音機或相機。然後，當您重放收集到的信息並找出您稱爲用戶故事的內容時，請將其收回。你與團隊討論他們，當你有了協議時你有用例來定位你的開發。
開發人員扮演的角色取決於您。如果他們只是編碼員，他們不參與這個過程。 如果他們部分充當顧問，那麼他們幫助定義用戶故事。
通常當你得到「它太大」時，他們真正說的是「我只有一個模糊的想法應該如何工作」。您需要與他們合作以更好地定義它，直到可以將其分成可以更容易管理的邏輯部分。
下面是我收集起來的，這可能有助於一些資源：
過大或過COM總而言之，總有一種方法可以在飲食上添加一個故事（也許在一次迭代中你不會得到最終結果，但這並不意味着你不能，而且，將有多次迭代）。
其基本上是產品所有者的義務和責任。可以有任何不能分解成用戶故事的任何要求/任務。我發現很多這樣的討論SCrum Master Forums
如果開發團隊聲稱這個故事太大而且不適合衝刺。根據它進行分割。
檢查這個流程圖..可以幫助：http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf
如果你想引起討論，使問題的社區維基。編輯問題。在底部點擊社區維基按鈕。 – 2009-11-11 11:25:33
此外，取出「引發辯論」，並將其替換爲「獲得提示，提示或建議」。這不是一個討論論壇。這是問題和答案。問一個問題（至少原則上）有答案。 – 2009-11-11 11:27:39
@ S.Lott：社區維基將刪除一大批人蔘與的動機。 – 2009-11-11 11:28:26