產出好的待辦清單

短期目標的描述方法－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的工作量，並快速聚焦產生共識。