我們使用Scrum。當我們發現用戶故事的粒度不足以捕捉完成衝刺所需的努力時，我們在衝刺期間遇到了問題。提高用戶故事質量
特別是，我們發現我們提供的UI線框包含的複雜性比原始故事隱含的要複雜得多（例如，出於可用性原因而複製的功能）。這導致burndown圖表看起來像在衝刺的最後一天完成所有事情。
我們花費每個2周衝刺開始時的星期一來審查由項目團隊創建的故事，在此期間，我們通常會細化這些故事並將其分解爲任務，估計每個故事的時間創建burndown圖表。在這一天裏，我們覺得沒有時間去有意義地提高故事的質量。
如何最好地打破我們衝刺的不完整/不足故事的循環？
這是項目團隊在一開始就沒有充分確定故事的原因，或者我們是否應該（即開發團隊）承擔一些責任？
那麼，你說：
開發團隊是否有可能實際與客戶/用戶交談？用戶故事有時被視爲啓動對話的一種方式，而不是要求文檔/規範。
編輯：有些鏈接：
編輯：馬丁·福勒昨天ConversationalStories覆蓋，比我這更好做了一個博客帖子。
+1：「比原始故事複雜得多的UI線框」聽起來好像沒有發生對話，有人感到驚訝。敏捷方法的重點在於防止意外。 – 2010-02-04 19:30:47
我們有（並繼續在某些方面）這個相同的問題。我認爲這個問題缺乏前期分析，缺乏開發人員花費足夠的時間來估計用戶故事。
你可能會像一個故事開始：
As an administrative user I can create a new widget.
OK，這是什麼意思？經過一番分析，這可能意味着：
As an administrative user I can create a new widget in created status with complex data validation errors.
後場，有多大，什麼必填字段保存到數據庫的上市如此。基本的用戶界面模擬也很好。
下一個衝刺另一個用戶故事可能是：
As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.
的複雜的驗證規則，那麼名單。
我們花費每個2周衝刺開始的星期一去審查由項目團隊創建的故事，在此期間我們通常會對故事進行一些細化。
在衝刺開始時，故事應該是READY。如果您需要對它們進行一些改進，我認爲您（開發團隊，ScrumMaster，項目團隊）應該在之前的衝刺階段提前完成。
如何最好地打破我們衝刺的不完整/不足故事的循環？
你可能低估了故事，或者他們太大，太模糊。在這兩種情況下，這聽起來像是一個估計問題，改善的一個好方法是減少故事的大小。爲了解決這個問題，您可以花費一些時間（例如每次衝刺的5％）到Product Backlog Grooming以準備最重要的故事並通過將它們放在on diet如果需要在下一個衝刺之前來減小它們的大小。這實際上會使衝刺計劃會議變得更加順暢。
這是項目團隊在一開始就沒有充分確定故事的原因嗎？還是我們（即開發團隊）應該承擔一些責任？
責任不是那麼重要恕我直言（除了政治原因可能，但他們不會產生太多價值），開發團隊和項目團隊都在一起工作和「失敗」在一起。這裏重要的是檢查並適應消除障礙。所以，這是開發團隊的責任，使這個問題可見（它是阻礙）。 ScrumMaster負責處理這個障礙。失敗將是不工作。積壓梳理會議是實現這一目標的一種方式。最後，我確信項目團隊將會改進並更好地理解開發團隊的期望。而且你們都會產生更好的結果。
您是否正在運行sprint回顧？在回顧結束時，您應該有高度優先的可操作項目來改善上一次衝刺中發生的事情。 同樣的事情不應該反覆出錯。
在衝刺期間您的產品所有者是否可以訪問？如果不是，您可能需要增加額外的任何估計，因爲用戶故事的細節不完整。
@Pascal建議將5％的sprint專用於產品積壓梳理是一個很好的選擇。這應該能夠讓用戶故事在開始Sprint之前處於更加詳細的位置。
我們花了週一的 開始每2個星期的衝刺準備在 故事由項目 團隊創建，在此期間，我們通常 細化的故事一點點，打破 下來到任務，估算每個 小時以創建燃盡 圖表。在這一天它不覺得 就像我們有時間去有意義的提高故事的質量 一樣。
聽起來像這是您的衝刺計劃會話，您是否可以控制在衝刺期間您要完成的用戶故事？如果你沒有足夠的細節，你如何承諾？
這需要你回來有一個良好的追溯和解決提出的問題。
如何最好地打破 不全/不足故事 我們衝刺的循環？
回顧，規劃，積壓梳理。
這是項目團隊 的失敗敲定故事從一開始就充分 ，或者我們（即 開發團隊）應該採取一些 責任？
它是整個團隊的責任。找到責備不會給價值，但大家承擔責任將給大家成功完成項目的機會。
也許在那些星期一早上的計劃會議中，您可能會涉及到誰在編寫用戶故事/線框並一起工作以找出他們缺少哪些細節，哪些細節會使您的估算更容易和更準確。也許可以制定他們應該包括的模板。
+1非常接近我的想法。 – 2010-02-05 01:06:45
很多好的想法已經在你的問題的scrum方面。基於您的評論：
特別是，我們發現，我們正在與包含遠遠超過原來的故事複雜UI線框供給會暗示（例如複製功能的可用性的原因）。
我也擔心你可能需要在開發過程中工作。從UI中的多個位置訪問功能應該是一個簡單的添加，幾乎不會消耗時間。如果您發現這是一個常見問題，那麼您的功能與特定UI元素緊密耦合。你的團隊可能需要提高他們的設計技能（例如：模式使用）。
這很有趣。看起來你正在衝刺中進行衝刺計劃？ Sprint Backlog在Sprint Planning之前已經提交了嗎？如果是這樣，團隊如何在沒有討論故事細節的情況下投入衝刺積壓？
另一種方法可能是讓產品負責人意識到某些故事由於缺乏明確性而無法添加到衝刺待辦事項列表中。特別是驗收標準尚未完全瞭解。這可能會引起與產品負責人進行必要的對話。理想情況下，它不應該來這個。它應該在回顧中討論和解決。
我投票結束這個問題作爲題外話，因爲它不是關於編程。 – 2017-11-01 09:18:16