你真的用對使用者故事了嗎？

雖然人人都在使用使用者故事，但很少有團隊能正確地使用它

這裡有五種情況，你應該重新考慮是否使用使用者故事：

1. 你的產品待辦清單上只有使用者故事：

如果你的產品待辦清單（Product Backlog）上所有項目都是使用者故事，那可能意味著你並沒有有效地使用它。除了使用者故事以外還有許多其他可替代的形式，例如：用途故事／工作故事（Job Stories）、改善故事（Improvement Stories）、問題故事（Problem Stories）和功能驅動開發（FDD）。你應該根據不同情況選擇最合適的樣本（Template），或者根本不用樣本。正確的做法是根據具體情況靈活運用不同的樣本或方法。

2. 你沒有與任何用戶交談過：

使用者故事應該基於與用戶的真實交流來創建，如果你沒有與任何用戶交談過，那麼你創建的只是基於你已決定要建造的功能（Features）進行反向工程的故事，這樣做並沒有多大意義。使用者故事應該反映用戶的真實需求和經歷。

3. 你將使用者故事拆分成更多使用者故事：

當你根據需要完成的工作將一個真實的使用者故事拆分成更多使用者故事時，最終你將再次忙於從功能中反向工程使用者故事。保持工作與原始使用者故事的聯繫，分割工作時你不必一定使用使用者故事。這種方法可以幫助保持團隊的工作更緊密地與用户的真實需求相聯繫。

4. 用使用者故事作為標題或摘要：

在看板上提供一個良好概覽時，用使用者故事做為標題（Title）或摘要（Summary）並不理想。使用簡短的標題作為速記是個好方法，否則情況很快就會變得複雜。簡潔的標題有助於快速理解和參考，避免因過長的使用者故事而造成的混亂。

5. 多數使用者故事以＂作為團隊成員＂開頭：

如果大多數使用者故事以＂作為團隊成員＂（As a team member）開頭，這基本上呈現了沒有與用戶交談的跡象。用＂作為產品負責人＂（As a Product Owner）來開始的故事並不是一個有效的使用者故事。真正的使用者故事應該聚焦於實際的用戶的需求和體驗。

提供意圖是我們永遠不應忘記的最重要的事情：我們試圖一起實現什麼，相關的背景是什麼？一旦你提供了這兩樣東西，樣本就變得不那麼重要了。這意味著理解團隊共同努力的目標和背景比遵循任何特定的樣本更加關鍵。

原文作者：Maarten Dalmijn｜敏捷領域專家（E）

作者檔案