在本章我們將關注故事編寫，為了更好的構造故事，我們關注六個特性，乙個好的故事應該具有如下6個方面的特點
故事的6個特徵
1、獨立的
避免故事之間的相互依賴，在對故事排列優先順序時，或者使用故事做計畫時，故事間的相互依賴會導致一些問題
2、可討論的
故事是可討論的，他們不是簽署好的合同或者軟體中必須實現的需求，敏捷故事是功能的簡短描述，細節將在客戶團隊和開發團隊中討論中產生，故事是提醒客戶團隊和開發團隊以後要進行關於需求的對話，它並不是具體的需求本身，因而它不需要包含具體的細節。這些細節可以在後期例如：scrum計畫會議上面進行討論
3、對使用者或者客戶是有價值的
「每個故事必須對使用者有價值」，這句話不是正確的，許多專案包含著對使用者沒有意義的故事，要記住使用者（軟體實際的使用人）和客戶（軟體的購買者）之間的區別。
例如現在的很多公司做的 電信專案來說：客戶就是電信提供商，但使用者確實廣大人們群眾，像「5臺伺服器集群」這樣的故事，對使用者來說沒有任何意義，群眾只關心服務，但是對於客戶來說，這個故事就非常有意義了。
之所以介紹上面的故事是想說，故事一定是對使用者或者客戶有價值才行，不要出現只對開發人員有價值的故事
例如：1、所有的資料庫連線要從連線池中獲取
2、 配置程式的log4j日誌輸出，並且配置好日誌級別。
像這些故事關注的是技術和實現細節，這些故事的背後想法是好的，但是故事的編寫沒有能夠體現對客戶或使用者的價值。
上面的故事可以換成如下的形式：
1、這個軟體，最多50位使用者能使用5使用者的資料庫許可
2、所有的錯誤應該以統一的方式展現給使用者並做記錄
4、可估計的
故事是可以估算大小、即把故事轉變成**的工作量是可以估算的。
如下3個方面可能導致故事無法正常估算
1、開發人員缺少領域知識
2、開發人員缺少技術知識
3、故事太大了
5、小的
故事的大小很關鍵，故事太大或者太小都無助於定製計畫。如果故事太大 比如「乙個使用者可以計畫一次度假」，計畫一次度假包含著一系列的任務，women把這種大故事成為「史詩故事」，對與這種故事我們要拆分成更小的故事，
合適故事的大小最終取決於團隊、它的容量和使用的技術
故事太大就要分割故事
故事太小就要合併故事
6、可測試的
故事必須是可測試的,成功通過測試證明開發人員正確的實現可故事。
不可測試的故事發生在非功能性需求上面，這些需求和軟體有關但是沒有直接關係
1、使用者必須覺得軟體很好用
2、使用者覺不需要花很長時間等待視窗出現
這個2個故事都是不可測試的，無論什麼時候，只要有可能，就要把測試自動化，要正確99%的故事都是可測試的。當產品增量開發時，很多東西變化的很快，昨天能工作的**，今天就會出現問題，這時候就需要通過自動化測試來盡早的發現這些問題。
故事特徵的總結
立項情況下，故事之間獨立的，有時候很難做到這一點，但是我們要盡力去實現。故事之間的交付順序應該是無關的，可以任意拿乙個故事來實現
故事細節由使用者和開發人員討論得出
故事應該很清晰的體現出來對使用者活客戶的價值，最好的做好事讓客戶編寫故事
故事可以注釋一些細節，但是過多的細節會使故事難以理解，也可能給人一種這個故事很詳細可不需要再和客戶溝通了
給故事假山注釋最好的方式是編寫測試用例
如果格式太大，符合故事和複雜故事可以分成幾個小故事
如果故事太小，幾個小故事可以合併成乙個大故事
故事應該是可測試的
開發人員職責
負責幫助客戶編寫故事，這些故事要能提醒你們同客戶交談，而不是記錄詳細的需求定義，故事應該是對使用者或客戶有價值的，他們是獨立的，可測試的、大小合適的
如果被問及實現故事所用的技術或者基礎架構資訊，應該使用對使用者或客戶有價值的術語來描述。
客戶團隊職責
負責編寫故事，這些故事要能提醒你們同開發人員交談，而不是記錄詳細的需求定義，他們對使用者或者你們自己是有價值的，他們是獨立的、可測試的、大小合適的
如何編寫敏捷的使用者故事 7條準則
從根本上講，敏捷的使用者故事是簡短，簡單的工具，用於記錄目標使用者為實現目標所需的單個動作或意圖。最簡單的使用者故事的格式為 作為使用者型別或角色 我要採取行動或意圖，以便獲得理由或受益 該答案至少回答了三個簡單問題，即故事在誰，什麼以及為何積壓在佇列中。隨著團隊的成熟和組織在多個團隊和計畫中使用敏...
敏捷開發中故事點和估算的秘密
高質量的估算能夠幫產品負責人優化效率和衝突。因此，精準估算的重要性毋庸置疑。估算並非易事。對軟體開發人員來說，估算堪稱是最難的工作之一。估算必須考慮所有能幫助產品負責人做出影響整個團隊和業務決策的因素。因此，從開發到高管都為它焦頭爛額也不足為奇，但這種做法是錯誤的。敏捷估算並不是什麼性命攸關的大事，...
敏捷開發的使用者故事怎麼寫？
以下是近期對敏捷開發中由以往 調研 文件 討論 文件 開發 文件 向新的開發方式的學習一些總結，和大家分享，有任何好的想法歡迎和我溝通。如何編寫使用者故事？1 使用者故事不要用技術語言來描述，要使用使用者可以理解的業務語言來描述 不要提及任何有關語言邏輯，資料庫，軟體，欄位的客戶無關描述。2 格式 ...