1. 在使用者故事中，將開發中的相關人員作為系統使用者角色
比如 as a po/apo/ppo/developer/tester/manager/integration engineer， i want 。。。
必須注意，as a 中的role是執行時實際使用該系統的使用者角色，不是開發時干係人的角色
包括客戶文件相關的使用者故事，也要以實際使用該文件完成某項任務的視角來描述：什麼角色，什麼情況下使用該文件用來做什麼，達到什麼樣的可衡量的目標等，而不是某經理要求該文件。
2. 把系統的發布版本放入使用者故事標題中
如果把系統的發布版本放入使用者故事標題和描述中，這樣當優先順序變化，需要把這個故事移動到下乙個發布時標題就需要改動了，帶來不必要的額外工作。
一種特殊情況：如果是需要發布給客戶的系統補丁包、增強包等軟體構建包的代號，這些交付的軟體構建包屬於乙個大的發布版本中的多次規劃中的交付，而且該使用者故事必須包含進去，該包才能對外交付，此時該軟體構建包代號還是可以寫進故事標題中的。
3. 沒有明確詳細定義的驗收條款（acceptance criteria）
使用者故事中的重要的3c中的confirmation缺失，會造成團隊不清楚做到什麼程度才能算done. 好的做法是用「given，when，then」的格式寫明詳細的驗收場景，詳細到團隊能夠完整準確理解需求的程度。
驗收條款有些地方也稱之為為conditions of satisfaction，是同乙個意思。
4. 使用者故事描述或驗收條款中使用模糊詞語
比如在要求高可用性的使用者故事中，只描述想要高可用性，沒有描述具體的場景下發生什麼事件後系統的行為應當如何才能成為為高可用性，會造成團隊對如何實現和測試不能很快明了。
5. 使用者故事沒有設定明確的完成定義（dod）
dod通常是acceptance criteria再加上一些流程上的質量控制、系統的設計屬性、維護溝通需要的文件等要求而構成。
每乙個使用者故事都應該有其dod， 可以使用統一的dod模版。針對特定的使用者故事，在模版基礎上註明不適用的項，以及必要時的額外要求形成專門針對該故事的dod。
6. 沒有估算故事大小，或給定太隨意，或過大無法放入乙個迭代內，或過小管理不便
使用者故事的估算故事點是用來指導迭代計畫的制定的。如果不使用故事點，那就要做到每個故事粒度大致相同，這樣通過故事的個數也可以做迭代計畫，否則就應該正式使用故事點，只不過要注意不要過度追求估算的準確度，以及不要將完成的故事點過度用於其他目的。
為了清晰地知道哪些故事需要拆分，可以為要開始的迭代的故事設定乙個最大故事點值，比如8，當乙個故事的故事點超過8時預示著要拆分。
值得一提的是，當故事太多時，可以使用兩級故事管理需求，第一級特性（史詩故事)，第二級故事，乙個發布版本中通常包含10-20個特性，每個特性可以平均包含10-20個使用者故事，這樣即能做到巨集觀把控，也能做到快速反饋和適應變化。
7. 明知乙個迭代內該故事完不成，還不拆分，或做計畫時讓該故事跨越多個迭代
使用者故事的粒度要小到放到乙個迭代之內，並且通常乙個使用者故事只占用團隊能力的1/4-1/6，跨越多個迭代的使用者故事違背了迭代計畫的基本原則，無論是什麼原因造成的，都應該拆分它。
8. 不按可交付和達到快速反饋的目標而拆分
使用者故事的拆分以交付和快速反饋為導向，首要是針對外部客戶，其次可針對內部客戶，再次為團隊自身提供反饋搞清楚需求和約束，不要純粹為了「節省」時間而拆分。
9. 盲目追求不現實的完整端到端驗證
當團隊是以元件方式構建，使用者故事的實現也是元件式實現的背景下，盲目要求所有元件的使用者故事必須端到端測試通過才能done，造成迴圈依賴，互相等待，再加上可能沒人負責對整個feature涉及的所有團隊做計畫上的協調，實際上迭代計畫各自為陣，每個團隊都把使用者故事的完成日期設定到最後截止日的迭代，不僅原定目標未達到，反而演變成wate***ll模式。
比較好的做法：如果可能就組建feature team；做不到，則virtual feature team 或設定明確的feature owner角色負責協調所有涉及團隊，或apo/ppo／po定期的sync會議；還做不到，使用內部交付模式，底層向上層交付，中層使用底層的真實系統以及上層的模擬系統驗證；如果以上都做不到，則可以mocking自己團隊外的元件，mocking時寫明具體驗證方式和條款，再留乙個使用者故事條目與真實元件整合，這樣至少可以用來將真實進度和相互阻塞的問題分離並重點暴露出來，便於下一步的改進。
10. 沒有按照團隊能力排定未來幾個迭代的迭代計畫
由於沒有持續排定未來幾個迭代的計畫，也就丟失了計畫的可見性和預見性，不利於快速調整應對變化和聚焦在最有價值的東西上。
應該將團隊的歷史完成故事點利用起來，結合團隊能力，排定在當下看起來相對合理的迭代計畫，隨著情況的變化，不斷調整迭代計畫。
什麼是使用者故事
使用者故事是從系統使用者角度描述使用者能做什麼、需要做什麼，從而完成一定功能的需求描述方法，描述使用的是日常或商業語言，便於使用者理解。它捕獲需求中的「誰」、「什麼」和「為什麼」，往往可以精簡到寫在一張小紙片上。
大的使用者故事，可以稱之為史詩故事（epic story），通常特性（feature）對應於史詩故事。
共同具有某種相關屬性的使用者故事又可以歸為同乙個主題（theme），相當於商業類別或投資類別之類。
使用者故事的3c』s （card，conversation， confirmation）
使用者故事書寫的幾種格式
一般使用第一種，在benefit比較明確的情況下，使用第二種
使用者故事條目的關鍵屬性
好的使用者故事符合invest規則
更多敏捷教練經驗觀點見
CSS開發中的十大錯誤用法
自從接觸前端軟體開發以來，我發現開發猿一直在努力征服著css。理由也很充分，開發人員是用邏輯思考的生物。新增乙個div元素導致所有 都不得不往下移一行，而另乙個div 浮 到左側，感覺沒有任何意義。你也一定聽到過開發人員的抱怨 我們只需要向左邊移動五個畫素，但是 天哪 為什麼整個都向下移動了一行。到...
資料探勘的十大錯誤現象 翻譯
在癌症檢測的專案中，醫生和研究人員在使用神經網路訓練資料時驚奇發現 訓練長時間 幾周或幾天 的訓練對結果的提高是有限的，更多時候會有更糟糕的評估結果。2.依賴於一種技術rely on one technique to a little boy with a hammer,all the world ...
資料庫常見十大錯誤No8 備份出錯
sql server資料庫備份出錯及應對措施 早上看了乙個貼子，是乙個哥們推廣自己乙個智慧型的資料庫備份系統，他總結了資料庫備份過程中所有可能出錯的情況，可以借鑑。如果你做dba時間不長，對資料庫的備份有些擔心，希望能找到一種讓你放心的備份方案，那麼本文絕對適合你。關於資料庫的備份恢復原理，大家多少...