（Photo by Braden Collum on Unsplash）

 

綜合本系列之前的文章，Scrum 其實就是一個小團隊（約5-9人），利用一個個固定短週期的衝刺（Sprint），跟客戶一同逐步漸進地，完成一個產品，而這個產品的功能，就是由一個個，由客戶主導、撰寫的用戶故事（User Story）來呈現需求的（關於用戶故事的簡要陳述，有興趣的朋友可以先參考一下《能讓需求簡化，還能更省時、更省錢，提供更多價值》這篇短文，容日後有空再專文細述之）。
 

既然如此，那麼，每一個衝刺就理所當然，應該要先有一個目標（goal）才對，不然，整個團隊又怎麼可以知道，到底該在這些衝刺期間內，一定得實做出哪些用戶故事，才會讓這些衝刺的最後產出成果有意義？同時，團隊又到底該完成多少的用戶故事量才算合理？

 

要回答這個問題，首先我們就必須要先知道這個產品的大目標為何（產品是要解決什麼樣的用戶問題），接下來才有可能把這個大目標分解為幾個中型目標（類似我們所熟知的里程碑）。

 

我們就以一個像104這樣的「人力仲介網站」產品為例，大目標可能可以定義為「台灣市場上求職者與求才者的最佳媒合平台」。那麼，接下來我們就可以把大目標拆解為兩個中目標，其一是「讓求職者找到心目中理想的工作」，其二是，「讓求才者找到理想的合作夥伴」。

 

有了這兩個中目標，我們接下來就可以來想一想，要達成這兩個中目標，分別應該為它們完成哪些功能？實做的先後順序又該如何安排？
 

例如，要達成「讓求職者找到心目中理想的工作」的中目標，我們可能會需要（也是 PO 決定的優先順序）先完成「求職者可以發布並管理自己的履歷表」這個大用戶故事（有人把這種大故事稱為「史詩 Epic」），以及「求才者可以搜尋到履歷表」這個大用戶故事。而這兩個「大」故事，經過開發團隊（Development Team）進一步拆解細化為小用戶故事，評估所需的時間心力之後，發現可能分別需要一個衝刺的週期才能夠把它們都完成。

 

又因為，要先有履歷表資料，搜尋才會變得有意義、有用，因此，第一個衝刺的目標就可以設定為「求職者可以發布並管理自己的履歷表」，第二個衝刺的目標就可以是「求才者可以搜尋到履歷表」。

 

於是，產品的大目標被拆解成為產品的中目標，中目標可能可以像上述的例子那樣，剛好可以直接變成各個衝刺的目標，也可能中目標還是過大，需要好幾個衝刺的目標完成之後才能夠達得到。

有了衝刺的目標之後，就會很清楚地知道，哪些用戶故事（小故事）必須被納入該衝刺內完成。接著所有用戶故事的優先順序，也就自然而然地被辨識出來了（需要先做的就是優先級高的）！

 

談到這裡，又一個問題來了。那這些衝刺的目標，到底該由誰來制定呢？是 PO（產品負責人）？還是 Scrum Master 呢？