在你撰寫使用者故事或列出待辦事項清單時，有兩個問題很重要：使用者故事夠完整嗎？你如何才能知道自己已經完成了任務？

比如，我們看一看斯托爾寫的使用者故事：“作為特種部隊的醫生，我必須為學生們傳授基本的生理學知識，這樣他們才能瞭解人體。”

關於一則使用者故事是否完整，我經常用一套標準來衡量。這套標準是比爾·韋克（Bill Wake）發明的。他認為，一個好的使用者故事應該滿足 INVEST 標準：

• • 可協商性（Negotiable）——使用者故事的內容要是可以協商的，使用者故事不是合同。一張使用者故事卡片上只是一個簡短的描述，不包括太多的細節。具體的細節在溝通階段提出。如果一張使用者故事卡片帶有太多的細節，實際上會限制和使用者的溝通。
  • 有價值（Valuable）——每個使用者故事必須對客戶具有價值。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個使用者故事，並不是一個契約，而且可以進行協商的時候，他們將非常樂意寫下故事。
  • 可評估（Estimable）——開發團隊需要衡量使用者故事，以便確定優先順序和工作量，並便於安排工作計劃。
  • 規模小（Small）——一個好的故事要儘量維持小規模，至少要確保在一個Sprint週期中能夠完成。使用者故事越大，在安排計劃、工作量評估等方面的風險就會越大。
  • 可測試（Testable）——一個使用者故事要可以測試，以便確定它是可以完成的。如果一個使用者故事不能夠測試，那麼你就無法知道它什麼時候可以完成。

斯托爾的故事是獨立的，因為他的學生們就在寮國，他不必考慮學生們前往寮國所需的直升機燃油費之類的事情，他能夠獨立完成任務。

他的故事是可修改的，因為雖然他一開始打算為學生們傳授基本的生理學知識，但如果他到了那裡之後發現學生們已經具備這樣的知識，或是已經有了一定的瞭解，那麼他有其他的教學方法可以用。他的故事有價值：學生們學到人體知識之後，可以派得上用場。他的故事規模小：他只給學生們傳授基本的解剖學知識，而不是教他們運用這些知識去開展外科手術。他的故事可測試：他很清楚自己想要傳遞的資訊，也可以對學生開展一些小的測試，以便確認他們是否真的吸收了這些資訊。

每個有待落實的使用者故事都應該要有“完整”的定義（比如是否符合INVEST標準），同樣，最後的結果也要符合“完成的定義”（比如必須符合什麼條件、通過什麼測試才能結束等）。在現實中，我們發現，如果使用者故事足夠完整，那麼團隊在落實專案的過程中速度就會加快一倍。此外，如果一個階段的Sprint完成了相應的使用者故事，那麼，這個團隊的速度會再次加快一倍。這就是我們能夠達到事半功倍之效的一個原因。

來源：《敏捷革命：提升個人創造力與企業效率的全新協作模式》  【美】Jeff Sutherland  Scrum之父作品

該書的PDF版本我有上傳，如需要可自行下載。