什麼是Scrum？不是工程師也能懂的Scrum入門介紹！
到底什麼是Scrum，這次要用最簡單的方法，告訴大家什麼是Scrum，讓你用最短的時間進入Scrum的工作模式！
為什麼要寫這篇文章？
前陣子，為了替非程式部門的企業夥伴上Scrum的課，又重新整理了Scrum的概念，並轉化成普通人也可以想像的情境，發現這樣效果非常好，花短短2個小時的時間，就能讓每個人使用它來工作，並用Scrum的語言來溝通。
為了讓剛接軌Scrum的團隊與完全不認識它的朋友，都能迅速理解Scrum的整體架構，這次用了一般人(非程式人員)也可以懂的故事情境，來替大家解釋Scrum的基本流程。
讀完這篇，你會得到什麼?
1.了解Scrum的基本架構
2.了解Scrum一般術語
3.判斷自己有沒有機會用到Scrum模式
什麼是Scrum？要理解其實很簡單
因為Scrum源於工程師的工作模式，即便企業主知道它有多種好處，卻因對普通人而言難以理解，總是不願導入一般部門之中。
為了讓大家更容易上手，這次決定用生活上的情境，來解釋到底什麼是Scrum，以加速每個人理解。
這次，就讓我們從一個旅遊故事開始，揭穿Scrum的面紗吧！
Scrum的第一步：職務分派｜澳洲旅遊的責任分配
故事的起頭是這樣的，保羅(PO)和他的朋友們，打算用１周的時間準備，並去澳洲旅遊２周的時間(Sprint)，於是就和西門(SM)、大衛(DV)等人，從行程景點、要準備的東西開始，進行了非常完整的規劃。
在開始前，他們用初步區分了各自的責任：
由於保羅(PO)對澳洲和旅遊都非常熟悉，就全權交給他來決定這次「去哪些景點」、「準備什麼資料物品」；因此，如果旅遊行程不好玩、出了問題，他就要好好對大家交代了！
而西門(SM)則因為擔任過旅行社的員工，對於旅遊從頭到尾的流程都瞭若指掌，就由他來負責監督，確保大家都有好好準備與溝通；在出遊期間，也會確定是否有按照行程走，以免因此讓旅途不順。
大衛(DV)等人，則是這次的旅遊團員，也都是旅遊愛好者，時常查詢資料、到處遊玩，所以實際資料的準備、玩的方法，就由他們來決定了！
※Scrum 名詞介紹：
1.旅遊期間(Sprint)：一段工作期就像2~4周的旅遊一樣，在Scrum中被稱之為「Sprint－衝刺期」
而工作團隊的分工，就像這次澳洲旅遊的分工一樣，也有著各種角色:
2.保羅(PO)： 扮演的就是團隊的總召，也是「產品負責人 — Product Owner，簡稱PO」
3.西門(SM)：扮演的是流程控管、監督的腳色，在Scrum裡面有個特殊名稱「Scrum大師 — Scrum Master，簡稱SM」
4.大衛(DV)等人：則是實際執行任務的團隊成員，在Scrum中被稱為「Development Team — 開發團隊，簡稱DV or Dev Team」
Scrum規劃會議｜準備到執行的規劃
在分配好角色之後，就要來一次正式的行程討論會了。
為了讓討論順利進行，這次還特地租了間辦公室來使用。
西門(SM)在會議開始的時候，先和大家說明了一些事項：
「這次包含行程準備、遊玩的時間，我們有３周的事情要做，而今天，我們就要討論好所有該做的事情，這樣之後大家就可以依照這樣的安排走了！」
接著保羅(PO)從口袋中，拿出一張這次的景點、準備事項清單，把它們都寫在大大的白板上，並跟大家拍胸普保證，去這些地方玩準沒錯！
有了這些項目後，大衛(DV)等人，就開始在白板上清楚地寫下「為了達到清單上的目標，應該要做的細節」：
就這樣，他們花了大概3~4個小時，將所有該做的事情都列了出來，打算從明天就開始執行。
．
清楚地列出待辦事項有很大的好處，因為每個人可以貢獻的時間，在出發前，每天就是3~4小時，而旅遊期間，扣除突發狀況、體力等因素，能玩的時間大概就是8個小時左右。
為了確保在這３周內，可以完成充足的準備、走完該走的行程，在規劃的時候就把時間、項目、誰要負責都列出來，就能在一開始知道時間夠不夠、有沒有什麼事情忘記做了！
※Scrum 名詞介紹：
1.行程規劃：是一次密集的工作規劃，在Scrum中被稱為「Planning Meeting－規劃會議」
2.準備與景點:每段旅行中(Sprint－衝刺期)，都有要跑的景點與準備的事情，就像每段工作期間有目標、執行任務一樣，這些在Scrum中被稱為「Story－故事」或「Item－物件」；而保羅(PO)從口袋拿出來的這張Story清單，則被稱為「Product Backlog－產品待辦清單」
3.執行細節: 每個故事，都有細部的事情要做，這一個個小事大概都會在一天內被搞定，它們與一般的待辦事項很類似，在Scrum中被稱為「Task－工作」。
在規劃會議中，通常會把「Sprint－衝刺期」裡面所有的「Story－故事」、「Task－工作」都安排好，不但會有基本的任務分配，還會標記出完成每個Task所需要的時間。
Scrum每日立會｜進度說明
好不容易把事情規劃好後，隔天大家就紛紛開始執行所列的項目，而為了讓西門(SM)掌握到所有人準備的狀況，他們安排了每天早上10點的時候，大家要聚在一起，花15分鐘說明三件事：
- 談談昨天做的狀況
- 今天要準備哪些項目
- 如果有任何困難，就在此時向大家說明
例如，大衛(DV)就在某一天的會議上說了：
- 昨天我查好了到雪梨歌劇院的交通方式
- 今天打算看看歌劇院裡面有哪些一定要參觀的項目
- 我發現歌劇院將有兩天閉館，我們必須刻意避開這兩天，如果避不開，要再麻煩保羅(PO)決定該怎麼辦
於是，西門(SM)確定了大衛(DV)有按照進度做事，大家也知道目前歌劇院行程的狀況；保羅(PO)則會開始思考，如果歌劇院閉館，應該如何改變行程才最適當。
之後，每天都維持著類似的短暫會議，讓所有人都知道目前狀況，一直到了旅遊結束。
．
Scrum回顧會議｜旅遊回顧與分享會
澳洲旅遊結束的隔兩天，大家再次相聚，分享了準備期間和旅遊期間有趣的事情，也分享了各個景點的照片，大家感謝彼此的幫忙後，也想了一下，哪些部分沒做好，或是忘記安排到，作為下次旅遊的改善方向。
※Scrum 名詞介紹：
Scrum裡面有三種重要的會議，除了前面提到的行程規劃的「Planning Meeting－規劃會議」，還有以下兩個：
1.進度回報：
在執行期間，每天會在固定時間花15分鐘召開「Daily Standing Meeting－每日立會」，為的是讓大家都知道目前準備、執行的狀況，每當碰到困難、任務不順，都可以在這個時候提出，請夥伴們幫忙解決。
2.回顧分享：
衝刺期結束後，會進行的是「Sprint Retrospective－回顧與檢討會議」，如同慶功宴、旅遊回顧一般，用來回顧這次完成的成果，相互鼓勵，並找出可以改善的地方，讓下次的衝刺更為順利。
上面這一連串，如同旅遊的行前規劃、準備與執行、完成後的分享大會，就是Scrum的大致流程。
你可以把Scrum說成一個合作的模式、專案管理的流程，或是另一種說法：
「在一段期間，完成一堆任務的工作方式。」
總而言之，Scrum並沒有想像中那麼難上手，甚至在生活的情境中都能看到類似的做法，只要有一定的概念，想要立刻啟動Scrum模式都沒問題！
所以該如何開始Run Scrum？
因為Scrum可以套用到生活、工作的許多情境上，如果企業或團隊有想要嘗試這種做法，建議是直接開始，用基礎的版本讓團隊習慣，對於日後的加速會非常有幫助。
至於到底為什麼要使用Scrum，在之後的文章都會提到，但我認為有3個非常吸引人的點：
- 從上面的旅遊情境來看，我們在一開始就知道了有哪些事情要準備，連時間、負責人都列上了，也就是在起初規劃時，幾乎就知道最後的結果，這是對掌控團隊進度十分有幫助的方式。
- 每一段衝刺期，團隊都有機會比上一次衝刺成長2倍的效率，我想這也是最吸引企業主管的一點。而原理與方法，也會在之後的文章中介紹。
- 它有著讓規劃更完整、事情接棒更順暢、代辦事項更簡潔精準、解決問題速度更快速…等各種幫助團隊運作的好處。
Scrum的開始確實很容易，但要充分享受到它帶來的好處，還需要注意許多細節。
如果你想更深入瞭解它，建議先從Scrum的基本精神、開會方法開始，相信在不久的將來，你或你的團隊將會有巨大的成長！
【Scrum工作術】3個重要的核心精神！
用Scrum最重要的3個核心精神，來檢測你的團隊是否適合使用Scrum工作術。
這篇文章想說什麼?
這篇文章，主要想傳達Scrum的重要精神，讓身為主管、團隊領導者的你，可以在導入Scrum前先思考目前的團隊習慣，是否能正確地利用Scrum。文中不會討論太多Scrum的細節，而是專注討論「Scrum精神」這件事。
讀完這篇，你會得到什麼?
1.了解scrum替團隊帶來的價值
2.判斷現有團隊適不適合Run scrum
3.開始調整自己或團隊的工作心態
如果用一句話來說它能替團隊帶來的最大價值，我會說：
「它讓團隊能用相同時間，做到更多的事。」
Scrum是什麼？可以做什麼？
Scrum起初被用在程式開發，適合大約6~9人的團隊，若善用Scrum的合作模式，假設團隊第一個月可以開發2個功能，第二個月就能開發3個，第三個月4個...如此不斷循環，團隊合作、開發能力，將可以逐漸被極大化。
這樣的快速的成長，非常適合新創團隊、新部門、新品開發部門的使用。值得一提的是，它不只能用在程式開發，甚至能讓一般的業務團隊、行政團隊、行銷團隊來做使用，這也是它最大的價值。
事實上，我們公司在起初引入Scrum時，就將它用做一般行政庶務、行銷規劃，許多項目可以說是與完全與程式無關。我自己也把這個流程運用到了人生規劃、平日活動安排。
因此，如果你希望自己或團隊能
- 在同樣時間，完成更多的事情
- 有更多良性的溝通、團結一致
- 每天清楚掌握，並精準地預測1個月內的專案執行狀況
就非常有機會運用到Scrum的流程與精神。
Scrum解決了什麼樣的問題？
在專案、團隊管理，或是任何計畫中，多少都會面臨到以下的問題：
「沒有按照時間進行」、「案子之間彼此卡住」、「管理者無法全面掌握狀況」、「過多的討論會議」、「執行冗長的感覺」、「應變能力不足」。
以上的問題，如果以Scrum的模式來執行，這些問題都能被更好地解決。
邏輯不同，所以可以解決許多團隊問題
一定有人會好奇，憑什麼Scrum的工作模式可以解決那麼多問題？
我認為主要關鍵在於：
「做事的邏輯不同。」
．
舉個專案管理的例子來說吧！
傳統上，我們只運用甘特圖來預測與掌控專案的進度。工具本身並沒有問題，但仍常發現預計5天的工作，因為做了8天導致整個專案延宕，而當預期被打亂，甘特圖最後只能用紀錄工具，而無法發揮預測、掌控專案的功用。
但Scrum模式中，會將每天的工作量化到以小時為單位，會議時間、客戶拜訪時間、一張表格製作的時間，全都在掌控之中。另外，整體的狀況也是使用「Story point」來掌控進度，而非具體的天數與小時。
光是這兩個概念，就能讓原本「預計5天」能完成的小型專案，變成「預計30小時」能完成的專案；讓原本「知道我們現在delay 3天」，變成「知道團隊最後將完成原本預期的70%」。
而因為在評估、規劃、討論、執行的邏輯都不同，才讓能讓諸如「無意義的會議」、「PM不斷督促詢問」、「團隊合作效率不彰」、「成員不懂得獨立思考」...等問題，都將在Scrum邏輯下，得到不一樣的結果。
Scrum的重要精神，你的團隊適合Scurm嗎？
因為做事邏輯不同，讓Scrum可以解決許多問題，但要培養不同的邏輯，團隊的想法就得不一樣，要能掌握一些具體的做事精神，在Scrum中，最重要的精神大概有三點：
- 永遠彈性調整，並優先做最重要的事情
- 團隊的所有人都要能「隨時掌握情況，幫助彼此解決問題」
- 要專注在「如何於固定時間內，完成更多的事情」
※備註:
在實際運作SCRUM一陣子，並更深刻了解SCRUM後，才知道完成更多事情並不是SCRUM要求的，但後者的一些解釋分享，仍能提供不錯的想法，因此仍保留此部分。
這三個重點，不但是Scurm的精神指標，還能用來評估一個團隊是否適合Scurm的工作模式，以下就讓我們一一介紹吧！
永遠彈性調整，並優先做最重要的事情
這對於管理階層，聽起來是理所當然，因為本來就應該做最重要的事情，但對於工作執行者而言，在實務上往往是十分抗拒的。
例如，當一個案子被要求大幅度修改時，執行者的心中常會想：
「這樣，之前做的不就都白費了嗎？」
「為什麼當初不先講，現在才在那邊改？」
「為什麼當初不先講，現在才在那邊改？」
光是有這種想法，在Scurm中都是個大忌，因為理論上，我們過去所做的，都是當時最好的決定，只是因為現在情況變了，才做了不一樣的調整。
如果執行人員無法接受這樣的事實，任憑管理者怎麼推廣Scrum流程，都不太可能讓促成團隊緊密合作，更妄論進步這回事了。
．
另外，團隊的總時間是有限的，不可能在舊Case還沒結束時又開始新Case，管理者如果只想著新Case，卻沒有留時間讓執行人員完成舊的，大家就勢必得加班。
相對於執行者要甘願任務被改變，管理者也有責任判斷哪些是重要的事，並且良好地分配時間，而非認為所有事情都重要，要求執行者馬上改善效率、掏出更多私人的時間加班。
．
也就是說，要想良好地與Scrum接軌
開發團隊要問：
「我可以接受主管隨時調整我的任務內容嗎？」
專案管理人則要問：
「我可以讓我的團隊成員完全不加班嗎？」
答案越是肯定，就越能讓整個團隊符合Scrum的首要精神：
「彈性調整，並持續著做最重要的事情。」
．
隨時掌握情況，幫助彼此解決問題
一個團隊績效是否良好，可以從兩個方面來看。一個是前面說的「能不能持續解決最重要的問題」，另一個則是「能不能更快地解決問題」。
以團隊而言，如果我們能互相合作，即便個人能力不變，依然有辦法讓團隊績效提升。
Scrum精神的第二點，就是希望「以團隊為核心來解決問題」。
既然是以團隊為核心，Scrum中的每個執行人員，都該對所有任務負責，不會有個項目應該由誰來做，或東西做錯應該是誰的問題。
．
舉例來說，如果有個任務是與客戶開會，而A被分配到了這項任務，但當天早上卻頂著不適的身體與會，最後使得簡報狀況糟糕、丟了案子，這不該是他一人的責任，而是所有人都得扛起這個結果。
「為什麼A沒有說身體不適？」
「為什麼即便身體不適，主管卻仍派他來簡報？」
「為什麼沒有人能跳出來幫他完成這項任務？」
「為什麼即便身體不適，主管卻仍派他來簡報？」
「為什麼沒有人能跳出來幫他完成這項任務？」
這都是Scrum在問責時，以團隊為核心來檢討的方式。
．
問責的反面則是互助。
只要有人在一個重要任務上碰到困難，每個人都該積極想辦法解決，即便放下手邊的工作也在所不惜。因為只要任務對於整個團隊而言是重要的，就該傾力互助完成。
值得一提的是，這樣互助的前提是「問題必須被反映給所有人」，也就是每個人都得誠實地說出自己碰到的困難，不要怕麻煩夥伴、不要怕被認為實力不足、不要怕被責難。
這對於一般的公司這是非常難達到的，因為受到了許多文化的影響，使得我們不願在會議上公開地說：「我做不到、完成不了、我不會、我做錯了」這些話。
．
所以，要想良好的與Scrum接軌，還得先調整團隊的文化：
開發團隊要問：
「我願意誠實地告訴所有人，我現在碰到的困難嗎？」
「有人碰到問題時，我有沒有思考解法，並展開行動幫助他？」
專案管理人則要問：
「我可以不責怪、輕視任何一位成員，而只想著該如何解決問題嗎？」
答案越是肯定，就越能讓整個團隊符合Scrum的第二個精神：
「隨時掌握情況，幫助彼此解決問題」
．
如何於固定時間內，完成更多的事情
一個運作良好的Scrum團隊，個人能力不需要有任何顯著的提升，就能讓團隊的效率成長非常快速。最主要就是源自於前面兩點。
但當這些到達了極限之後，不論是管理層還是執行者，都得更常問一些問題來幫助團隊加速：
- 有沒有不同的做法，但能更快地完成任務？
- 能不能少做一些事，但仍能達到相同的目的？
- 能不能換個流程，讓事情進展更順利？
- 能不能先完成某些事，讓日後的許多事一勞永逸？
這些問題都是簡單的技巧，但更重要的是，每個人都要有一個想法，就是真心地去想「怎麼讓事情更快被解決」，要真的去思考「原本預計花3天才能完成的報告，應該如何在3小時內完成。」
唯有達到以上的三點，才能讓Scrum團隊一直保持高效高速的狀態
「讓團隊在固定時間內，完成更多的事情
【Scrum規劃會議】(一)先說好目標與Stroy
重新定義Scrum裡的Story，從說一個好目標開始！
為什麼要寫這篇文章?
規劃會議，可說是Scrum中除了精煉會議以外最難的會議，好的規劃會議能讓大家有一致的目標，而且每天都知道自己在做什麼；不好的規劃會議，開完的隔天會沒有人知道事情該怎麼做，於是就開了更多的會議。
規劃會議的好壞，差距就是如此大，所以想透過這一系列關於規劃會議的文章，來說明規劃會議從說明、評分、撰寫Task需要關注的幾個重點。
讀完這篇文章後，你可以獲得什麼?
1.知道規劃會議在評分以前，應該要說明什麼 2.知道目標、Story描述，會如何影響團隊的做事方法
規劃會議，是在精煉會議後、每日立會前的Scrum會議。主要是讓所有人知道接下來的衝刺期，將會進行哪些任務。
Scrum規劃會議的開頭，第一步就是說明會議流程，然後就可以開始會議。
以我的經驗，一開始會花10–20分鐘，說明中、長期目標。然後用1–2小時左右的時間，說明以Story為單位的目標、出發視角、做法。
這篇文章，主要介紹的就是「說明目標」、「說明Story」兩大部分。關於評分、撰寫Task等規劃細節，將會在其他文章中介紹。
1.說明衝刺的長、中、短期目標
首先，我們要知道一件事，目標是有分大小、長短的，在每個規劃會議的開頭，都要說明目標是什麼，為了讓所有成員清楚，我們做的這無數個Story，究竟是為了達到什麼樣的目標。
要能先清楚的說明長、中期目標，該做什麼Story才會顯得有意義。
長期目標
例如，每個月商品銷售數量從1萬個變成1.3萬，提高30%，這應該就是一個長期目標，可能需要3次的衝刺期才能達到。
這個目標可以是模糊的，也可以是具體的，例如：成為市場的領導者，或是市佔率超過15%。
這個目標可以是模糊的，也可以是具體的，例如：成為市場的領導者，或是市佔率超過15%。
為了不是大家要達到這個數字，而是讓大家有一個長遠的眼光與方向感。然後PO可以在一段時間後，回過頭來檢視衝刺的成效。
中期目標
例如，這次衝刺完畢，希望能更精確地掌握3~4個關鍵的商品銷售通路，就是一個稍微中期一點的目標。
以1個Sprint為單位，其實已經算是一個中期目標了，因為Scrum團隊本身就是一個彈性大、反應快的單位，如果中期目標是以一季為單位，就失去了這個合作方式的本質了。
而中期目標，是為了讓大家在每次衝刺期後，能獲得更明確的一些成果。
短期目標
短期目標，也就是每一個Story完成後，可以明顯的預期的事情。
例如，做完這些事情後，希望可以得到10%的曝光增長，這就是比較能預期的事情。
但這個Story的目標，也不能太小，因為Story目標的本質，是為了讓大家在實際做事、規劃時，不要搞錯方向、短視近利。
我認為，Story的目標最好是一個
「幾乎伸手可及，但又稍微達不太到的未來。」
為了是在每天做完事情後，能有一件小到讓人立即有成就感的事情，但又能與長期的目標有所關連，讓大家完成每一個Story後，會有種「我又往這個目標邁了一大步」的感覺。
如果目標是「10%的曝光增長」，做完一個Story可能只有5–8%的增長，但沒關係，至少往目標邁進了一大步。而即便與長期目標的「提高30%銷售量」距離有點遠，但確實曝光越多、造訪網站的數量也會提高。團隊依然會在正確的軌道上。
清楚為什麼，比很多事情都重要
說明這三種目標，為了讓所有的工作者「清楚為什麼要做。」
如果我們只說短期目標，是增加10%曝光，有可能會被認為只是想讓更多人認識產品，而忽略了曝光的品質，以為隨便給一個人看商品都可以。
但如果有一併說明長期目標，是為了在3個月之後，讓這些人來買東西，那我們就會盡量找相關性比較高的客戶。
因為在實際Run Scrum時，在有太多細節管理者無法顧慮到，也不可能監督每個人的執行細節。所以目標最重要的，還是為了給執行者提供方向感，當大家都清楚為什麼要做時，在做事的時候就會有更正確的判斷。
2.說明Story的3個組成
一個Story通常會是這樣寫的：
「身為一個」行銷人員，
「我希望」建立一個關鍵字廣告，
「以便」帶來更多商品曝光。
Story由「身為一個」、「我希望」、「以便」這三個關鍵元素組成。而在規劃會議時，應該有1–2小時的時間，都是在說明Story。以下就分別說明這三個關鍵元素的特色。
「身為一個」：出發點、角度
身為一個…代表的就是問題的起源，是一種看待事情的角度，可以幫助我們設身處地的想。
如果是身為客戶，通常都是希望有一個快速方便的好東西，不然就是解決某種難題。
身為一個「客戶」，我希望廣告能給我「足夠的商品資訊」，以便我「快速選擇商品」。
但如果是身為內部員工，雖然方向可能都是要讓消費者看廣告，但會有全然不同的敘述：
身為一個「行銷人員」，我希望建立一個「關鍵字廣告」，以便帶來更多「商品曝光」。
「我希望」：做法、方式、策略
會和出發、抵達目標的相關性十足，身為不同角色、為了獲得不同的結果，你當然會選擇不同的做事方法。（等等會詳細說明）
．
「以便」：抵達目標
就如同前面說的長、中期目標，Story所說的短期目標，是為了幫助每個執行者更好地聯想到中、長期目標，在執行的時候，就不容易迷失方向。
但究竟為什麼，我們規劃會議要花1~2小時的時間，詳細說明這三點呢？
很大的原因就是，這三個描述，只要有稍微一點的變化，就會完全改變團隊的做法。
「身為一個」的出發點，如何改變我們的做法
因為你會發現，當視角不同，即便目標、做法類似，但整個Story都還是會改寫。例如：
1.身為一個「行銷人員」，我希望建立一個關鍵字廣告，以便帶來更多商品曝光。
2.身為一個「資深的行銷人員」，我希望替3個新來的行銷人員上課，以便們所設定的廣告品質更好，帶來更多商品曝光。
單純身分的不同，即便同樣希望替商品帶來曝光，因為效率、比較利益的關係，做法也可能會有所不同。
更進一步地，如果用全然不同的視角，甚至會改寫整個Story的做法與目標。
1.身為一個「行銷人員」，我希望建立一個關鍵字廣告，以便帶來更多商品銷售。
2.身為一個「產品用戶」，我希望廣告能給我足夠的商品資訊，以便讓我更快選擇商品。
客人期待的是好的廣告資訊，這樣他就能更快選到喜歡的商品。
但身為行銷人員，你一點都不期待快速選到喜歡的商品，只會希望有更高的曝光，而做法就會只是單純的廣告而已。
而且因為從「行銷人員」到「產品用戶」的視角轉換，就能讓廣告變成提供「更多資訊」而非一班的廣告。目標就不只是單純曝光，而是顧客要能「快速選購」的有意義曝光。
．
「以便」的目標，如何改變我們的做法
同樣的，即便我們的身分、做法一樣，當我們改變目標時，做事情的細節也很可能不同。
如果身為一個行銷人員，以曝光為目的，那麼在相同成本下，我會廣發我的廣告，甚至努力找到那些連聽都沒聽過我們的客人。
同樣身為一個行銷人員，但是以銷售為目的，我就更能利用更多的再行銷廣告、更精準地提供廣告給我的客戶。
．
身分+目標→做法
但無論如何，千千萬萬要記住一件事情，我們應該都是由觀察視角或目標，來決定我們的做法才對。
很多團隊都會先以做法為出發點（因為比較直覺好想），再來才說明為什麼想要這樣做。但就像上面關鍵字廣告的做法，就可以有曝光、銷售兩種目的了，幾乎每一個做法，都可以演身成數十種目標。
但我們更該說明與重視的，不是廣告可以怎麼幫我們達到目標，而是說明：
「為什麼要達到這個目標，廣告是最理想的做法。」
由於Scrum是由國外翻譯來的，很多地方其實念起來不太順，我建議大家Story可以換個寫法，會更適合大家凝聚目標、確定行動。
出發視角：「身為一個」行銷人員，
抵達目標：「我希望」商品有更多曝光，
具體行動：「所以我要」建立一個關鍵字廣告。
身分與目標，其實是行動的一個觸發點，重點是要「經過一段思考之後」，才會能有正確反應，才會有「所以我要做…」的具體行動。
建議大家，在所有的具體行動確定前，都要再回頭想一個問題：
「有沒有更好做法，但可以達到一樣的目標？」
講述Story做法，如果只有單純的「建立一個關鍵字廣告」其實遠遠不夠，這樣隨便建立一個廣告也都可以交差。
但團隊成員能不能聽完Story後，就知道怎麼評分、Task要怎麼寫，幾乎都是依賴良好Criteria。說白一點，就算完全不給目標、不給視角，只寫一個很完整的Criteria，團隊其實也可以執行工作。
【Scrum規劃會議】(二)說好Stroy的KPI與Criteria
Scrum規劃會議前，先釐清每個Story的KPI與Criteria吧！
為什麼要寫這篇文章?規劃會議，可說是Scrum裡面除了精煉會議以外最難的會議，其中Criteria和KPI的制定，又時常搞得大家一頭霧水，這次想要分享的是我對於Criteria的細節的一些看法。讀完之後你可以多瞭解什麼?1.Criteria怎麼定會更好 2.KPI與Criteria的差別 3.管理者與執行者之間的模糊地帶關於Story的基本
前一回談到，規劃會議要說明長、中、短期目標，也說了Stroy是由角度、目標、做法三個重要元素組成。而且短短一句Story描述，還隱藏了不少的意涵：身為一個…：正以某角度來思考事情 我希望…：為了某個目標 所以我要…：打算做一個目前覺得最好的做法但其實真正要執行時，單單的一句Story其實還不夠用，所以規劃會議還要注意的是Story一些幾本與Criteria細節。Story的基本標準
在Scrum的基本介紹中，有六項檢核標準，可以幫我們測試看看是不是一個好Story，也只有好的Story，進入到後面的投票、執行才有意義。1.獨立：不能和其他故事同時完成、不能因為其他故事而影響執行的時間。換句話說，每一個Story如果不管重要性、時間限制性，應該都要可以立刻進行。它不能受到當期衝刺的其它的Story影響。例如，如果我要進行的是一個裝潢房子的任務，但如果有另外一個Story是要看房並與房東簽約，這兩個任務就不該同時出現。因為裝潢房子前，一定要先看房簽約，但如果看房時發現房子有問題，就完全無法進行裝潢，這樣第二個Story可說是在第一個沒有如預期完成以前，完全沒有在這次Sprint中存在的意義，因為很可能會進行許多變動。2.可修改：在實際結束前，能保持彈性，可以修改標準、調整task、story目標與分數。Sprint的本質，不單單是為了專注、可預期、提高效率而已，還有一個要點是保持彈性，所以我們可以在執行期間，加入、移出、修改任何經過PO同意的Story。3.有價值：要能夠為目標對象傳遞價值意思就是要站在某個人的角度想，並且能傳遞出一種願景。4.可估算：可估算時間、成本、人力等資源。5.規模小：為了讓故事可以列出task，他應該要讓人看到，就知道該如何列出task。6.可測試：故事在結束時，必須通過檢驗。．1~3的標準，相信大家還可以輕易理解，但可估算、規模小、可測試，其實比想像中更複雜，也就是這篇最主要想解釋的事情。KPI v.s 可測試的Criteria
Story的撰寫，其實是一個管理上的問題，所以我想先聊聊我對於管理者、PO的一些看法。管理者、PO的責任到底是什麼？
我認為，管理者與執行者最大的差別，就在「換句話說」的能力差距而已。更高職位的人，有能力把更大的目標換句話說成小的目標，低階職位的人只能把一些較小的目標說好。舉個例子吧！假設我們公司的目標是「成為產業龍頭」，我相信隨便問一個小職員，一定不知道現在要做什麼。但能成為管理者、CEO的人，就是能跟大家說：1.我們要先把營業額做到100萬 2.然後把顧客滿意度提高到30% 3.接著布置15種的通路管道這樣，我們就能成為產業龍頭。但CEO說的，還是讓小員工一頭霧水，怎麼樣才能把營業額從現在的50萬變100萬呢？這時，可能就需要一個位階居中的業務主管來幫忙換句話說：1.每個月比現在多跑100個客戶 2.調整定價公式，並調價所有產品我們就能把營業額做到100萬。這時候小職員就聽懂了，他現在每個月跑200個業務，要再多跑100個業務的話，他的行程和跑業務的方式就要調整。所以職位的高低、是管理者還是執行者，最大的差別就是「換句話說」的能力高低，越厲害的人、位階越高的人，越有能力把大事變小事，把小事再變成下一秒可以開始做的事。而對於Scrum的PO，或是任何管理人員而言，最重要的責任，就是把一個看起來比較難實現的目標，「換句話說」成讓人可以理解、執行的任務。Story裡的換句話說
一般而言，Story會包含下面三個要素：身為一個…：正以某角度來思考事情 我希望…：為了某個目標 所以我要…：打算做一個目前覺得最好的做法以換句話說的角度來說，其實一個Story，就把長期目標換一句話，說成Story目標(我希望…)；並把Story目標換句話，說成更小的做法(所以我要…)。PO的責任，其實就是要能換句話說現在的目標，直到讓小職員能夠聽得懂、能執行的地步。另外，PO可能還會額外思考一件事情，我換句話說完之後，我的Scrum團隊真的知道Story中的「所以我要…」，要怎麼做才符合標準嗎？這其實全部都暗藏這次的主題裡：Story的Criteria
Criteria的用途
每一個Story，應該都要有一個完成的標準-Criteria，它的用意是說明：這個Story要「做哪些事」，才可以算完成。 而且這些事情，應該要是「幾乎可以完全預期的。先說說什麼叫作「完成」
如果我們的Story是這樣寫的Story:身為一個行銷人員，我希望帶來更多商品曝光，所以我要建立一個關鍵字廣告。Criteria:1.如果我的Criteria設定到 2.建立一個廣告活動，只要跟商品相關即可 3.預算3萬 4.無須投放當團隊最把這個Story評為5分，那什麼時候才可以拿到這個分數呢？就是當Criteria全都被滿足的時候，也就是Story中的「可測試」原則。因為有了Criteria，一方面可以更清楚應該要做哪些事，寫task的時候可以更容易。另一方面也是告訴我們，當通過檢驗後，就可以不用再浪費時間做相關的事情，而省下時間，也就等於加速了整個Scrum的運行．另外，前面有提到說，PO會擔心執行人員不知道怎麼做才符合標準。以剛剛的廣告例子來說，大可以直接拿以前做過的，然後改好預算就好了但如果Criteria改成1.建立一個廣告 2.包含新的3組關鍵字 3.每組可預期帶來1000的曝光 4.預算3萬、投放7天。如果是這樣，就還需要再額外做許多事情，也就是說，Criteria，其實就包含了PO對於這個Story完成後的所有想像。這些更細緻的說明，其實也是對於「做法的換句話說」，它不但需要管理者的能力，也會被用來評估執行是否完成的標準。Criteria與KPI的差別
前面有提到，「把目標的換句話說」，就是一個主管的責任，而KPI其實就是對於「目標的換句話說」，往往需要十分具體的數字，為的就是幫助我們衡量距離目標還有多遠。Criteria則一種對於「做法的換句話說」，這些說詞不必是具體數字，但要能精準的預期完成。你可以把Criteria想成，只要我做了1.2.3.4…件事情，我可以達到這個Story的KPI。大家容易搞混Criteria和KPI的差別，其實就是對於「做法的換句話說」和「目標的換句話說」不理解，而兩者之間存在主要差異就是：是否可以預期。舉例來說，如果前面廣告的Criteria設定為：獲得1000次曝光其實就這就代表著，沒有達到1000人看以前，這個Story永遠不會完成。令員工困惑、加班的原因，往往都是主管只說「我希望有1000人來看我們的產品」，但這幾乎不是員工可以控制的。員工們可以下廣告、可以上街推銷，但如果人家就是不看，那我怎麼樣也做不完。就變成說這個Criteria不是我能預估的。既然前面有提到，Story要「可預期」，那當有了這個Criteria，Story就有問題了反過來說，當一個Criteria如果不可預期，它就是一個對於目標的換句話說，它應該存在的不是Story的Criteria中，而是接在Story本身的「我希望...」後面。．但有一點十分有趣，如果同樣的「獲得1000次曝光」是由一個廣告投放高手來做，他有能力每次預期廣告會有多少人看，只要給他足夠的時間與金錢，他就可以很精準地說，在3天後，將會有1000點擊廣告。此時，這件事情又變成可以預估的了！．目前為止，你可能會發現一件事情，Criteria的制定者，其實應該是實際執行人才對，因為只有執行的人，有權利說，這件事情我有辦法預估。PO雖然有責任把長遠的目標，換句話說成短期的Story目標，甚至精細到做法的初步說明，但對於做法的細節要達到怎樣的程度才算完成Story，一定得跟執行的人討論才行。否則當Story無法預估，基本上都是白搭。
規劃會議與精煉的界線
規劃會議，除了目標，說明Criteria也是一大工程，大部分的時間應該也是在講Criteria，就如同前面看到的，就算Criteria只增加一個項目，需要做的事情也可能會暴增。我們團隊在執行時，也很常發現規劃會議時難以確定Story，往往是因為邏輯策略、換句話說的方式、可預期、可檢測上出了問題。但這些，本都應該在規劃會議之前的精鍊會議完成，規劃會議當天應該著重在重複說明與確認，並且進行接下來的評分、撰寫Task。．另外，PO最苦惱也最常思考的，就是怎樣的Story才能讓執行者朝著正確的方向走、才不會做錯。也因此花了大量的時間撰寫Story。但其實，Criteria到底要定義到多細節，取決於管理者平日的溝通，以及對於執行人員的信任感。溝通力與信任感越強，就越能省去需多執行與目標細節的定義。我自己認為，不要過於拘泥這些執行的小瑕疵，只要做的方向是正確，這些問題很容易在1~2次Sprint就被修正完成。與其執著於完美的Story，不如讓Story可以被執行。畢竟，在Scrum之中最重要的不是完美，而是持續的進步。
花了這麼大的篇幅講規劃會議，就是因為Story實在太重要了，他就像是所有人的指南針一樣，為了讓在執行人員能時常確認自己的方向，也讓管理者釐清策略。反過來說，如果能持續與團隊一同精進Story的撰寫，相信成長的速度將會出乎預料。之後將介紹的是關於評分、撰寫Task的一些細節。另外，我自己覺得Story的撰寫與說明，就如同管理一樣是一門藝術，有千百萬種方式與見解，也很歡迎大家留言與我交流！
發表文章
沒有留言:
張貼留言