【Scrum規劃會議】(二)如何產出好的待辦清單
更好、更完整地說明Story，將有助於規劃會議的進行與日後執行。
為什麼要寫這篇文章?即便有 User Story 描繪想要完成的產品、短期的目標，但仍會不清楚一些細節，這篇文章，會幫助大家產出好的 User Story ，以便團隊成員能更容易安排工作。讀完這篇文章後，你可以獲得什麼？1.更了解描繪 User Story 的方式
2.能判斷 User Story 的好壞
短期目標的描述方法－User Story
我們需要先理解 User Story 的本質，它是一種描述工作項目（item）、專案（Project）的方法，讓我們更有畫面感、有頭有尾地理解一項任務。
一般項目描述，你可能會用這樣的方式：
「設備找場地網站」
而User Story式的描述則類似：
身為一個活動人員，
我希望更快找到好的活動場地，
所以我要有一個「設備找場地的網站」。
這個描述句由三個部分組成，讓我們能更透徹的理解任務的本質。
「身為一個」：闡明人物視角
代表的是問題的起源，是一種看待事情的角度，可以幫助我們設身處地，以人為本地打造人需要的產品，不論此人是客戶、部門同仁、合作廠商。都會影響到我們對產品的感受與態度，進而影響到產品的樣貌。
例如，需要「設備找場地的網站」，但描述句的身分不同，就會有所差異
A：身為一個「活動新手」，我希望更快找到活動場地，所以我要有一個設備找場地的網站。
B：身為一個「活動老手」，我希望更快找到活動場地，所以我要有一個設備找場地的網站。
即便同樣是設備找場地的網站，新手喜歡的是簡單的辭彙、生動的圖片；老手則要求詳細的規格、多層次的篩選。
因此，當有了人物視角，會幫助我們在更容易製作出符合需求的產品。
「我希望」：描繪抵達目標的畫面感
如果我們打造的是給用戶的產品，最好知道他們到底為何而買，也就是當他們獲得產品之後，到底想要的效果是什麼。此效果是產品使用後的效果，而不是產品本身的功能性。
例如：
期待使用產品後的效果：「從台北快速到高雄」
產品功能：「幫助人們快速移動」
產品：「馬車、腳踏車、汽車、高鐵、計程車」
我們需效果的畫面感，是為了避免做出沒有效用的產品，因為消費者最終買的是產品替他們帶來的價值，而非產品本身。
「所以我要」：提供成品的確定性
客戶使用後希望達到的效果是難以替代的，而產品本身卻是可以不斷變化的。但我們仍需要對產品有個最終的決議。因此，「所以我要」後面接續的項目將代表產品本身，也是最後衝刺期結束後，我們會拿到手的東西。
前面提到的長期目標、身分描述……等，都是為了避免我們短視近利，忽略了事情的方向性，但我們最仍需要提供一個確定的東西，來幫助我們具體呈現想法。
當你能把角色身分、價值目標、確定性成果這三者，用清楚、簡短的語句描繪後，就達到了 User Story 的基本品質。
User Story 的輔助內容
在規劃會議中，除了有 User Story 的標題，來讓人快速長握會完成的東西，我們也經常提供輔助文件來說明 User Story 的內涵，用以理解更細節的東西。
例如：
室內裝潢，會提供水電圖、平面圖、家具配置圖。
銷售網站，提供Wireframe、畫面草稿。
平板電腦，則是外觀樣品、效能規格清單。
輔助文件沒有任何限制，可以是產品規格表、示意圖、草稿、流程圖、樣品，大多行業中都會有習慣的做法，只要能清楚表達即將完成的項目即可。
六個面向，判斷 User Story 的好壞
規劃會議的最後，我們需要有一個行動計畫，來完成各種項目，為了有利於執行與完成，可以用六個面向，來判斷目前的 User Story 的內容是否能讓團隊更容易產出行動計畫。
1.獨立（Independent）：
是「可被獨立完成的」，不會受到其他項目影響。
例如，要裝潢一間房子，如果將Story分成「看房、簽約、裝潢」並存在同一個Sprint中，由於三者存在順序性就會出問題，因為根據房間、合約內容不同，就會影響到裝潢的行動程度。
同一個 Sprint 中，有多個缺乏獨立性的項目，除了不符合的迭代（iterative）的Scrum方法，也會造成團隊成員很難承諾能在此次Sprint中完成。
2. 可協商（Negotiable）
需要有足夠的修改空間，以更好地完成、達到目標。
談判空間包含許多，例如品質、技術性、產品規格。
例如，
當我們設定房間的吊燈都只能放在正中央，且沒有談判餘地時。如果遇梁柱、電線、水管等阻礙，導致無法裝燈具時，可能選擇把梁柱拆掉這種不符合效益的解決辦法。
所以，即便我們在規劃會議中定義好了 User Story ，仍要知道它在最終被完成以前，只要它的修改有利於達成目標，都該保有協商的彈性。
3. 有價值（Valuable）
必須實際為顧客、使用者或利害關係人提供價值。
聽起來像是廢話，但核心在於我們認可這個產出必須真實有價值的。 並不是一個純虛構的、無邏輯的需求與人物，也不是「為了做而做」。
例如「房間中的吊燈放在正中央」，如果並不具備任何價值，那它就不該被定義。
4. 可估計（Estimable）
必須能被理解、估算時間、成本、技術等各面向。
在規劃會議結束後，團隊需要「承諾」達成目標、完成 User Story ，所以 User Story 本身就需要可以被推估，才能讓人有承諾的可能性。
5. 規模小（Small）
盡可能小，且易於規劃、執行，能在一個衝刺期內完成。
除了跟可估計類似，並且同樣有利於團隊成員「承諾」以外，強調「小」會更符合精實思維（lean thinking），我們盡量避免做一個過大、過完整的項目，只為了提供一個目前還沒辦法很肯定的客戶需求。
所以反向要求盡可能縮小規模，提供基本的價值，才更為適宜。
6. 可測試（Testable）
必須能被測試、驗證，以證明這個項目完成。
為了讓 User Story 有一個終點，並在衝刺結束時，能真正地被確認是否完成，最好包含一些測試項目與方法。
例如，被裝潢的燈，應該要能開關、亮度達到要求、能持續超過1小時不閃爍等。
這六個面向並「必須」，而是給我們一些提醒，需要思考的是：
- 當一個User Story不獨立會發生什麼？
- 規模太大會如何？
- 難以協商會怎樣？
每個檢測背後都包含了經驗法則，可以說「如果可以往這個方向，大多會更利於達到目標」，但如果你們團隊能接受一些指標達不到，或是具備克服困難的能力，當然也不必 100% 符合這些檢核項目。
下一回，我們將會評估已經備受認可的User Story的工作量，並快速聚焦產生共識。
如果你喜歡我的文章，請幫我拍拍手~「1下」拍手：到此一遊，留個記錄吧。
「5下」拍手：表示喜歡這篇文章。
「15下」拍手：表示你想要知道更多相關的內容！
「30下」拍手：手應該會有點痛，但還是歡迎繼續拍。按下「Follow」，追蹤我或我的專欄，將能定期收到優質的文章！
