本書主要分為5個部分來講，分別是 Scrum Master的角色、待辦項的改進和估算、 Sprint計劃、 每日站會、 回顧會；
以下是盡可能用易理解的語言來看待38個問題。
代辦事項簡要知識點
待辦項的改進和估算
-
背景知識點：
產(chǎn)品經(jīng)理掌控產(chǎn)品待辦事項以交付最大價值，但是他們需要整體團隊的幫助。對于每個Scrum團隊來說，待辦事項的改進和評估都是非常重要的任務(wù)；
把跨職能的Scrum獨立于其他團隊（UX、UI團隊）是非常理想的方式，現(xiàn)實中經(jīng)常依賴于這些團隊；
良好的Scrum團隊表現(xiàn)主要有兩個基本的要素：
整體編寫用戶故事：
產(chǎn)品經(jīng)理需要解釋為什么要做（市場情報、實驗結(jié)果、用戶訪談、統(tǒng)計數(shù)據(jù)等）；整個Scrum團隊一起協(xié)作編寫用戶故事，構(gòu)建主人翁意識（產(chǎn)品：為什么做；Scrum團隊：怎么做；共同定義做什么）。-
達成用戶故事’已就緒‘的定義：確保我們能夠較為完整的完成用戶故事的開發(fā)，在編寫之后，Scrum團隊?wèi)?yīng)該和產(chǎn)品經(jīng)理對用戶故事’已就緒‘的定義達成一致。
’已就緒‘的定義：此定義是關(guān)于需要為用戶故事提供哪些內(nèi)容以使其準(zhǔn)備好進行評估的約定。那么如何定義什么樣的用戶故事已經(jīng)是’就緒‘的？這也是一位PMO負責(zé)人問過我一個問題，什么才是一個好的需求？可以參考：用戶故事該怎么寫
在明確’已就緒‘之后，需要對用戶故事進行評估，沒有評估的用戶故事是一個未知實體，Scrum團隊不應(yīng)該對未知實體進行承諾，只有評估過之后的用戶故事才能當(dāng)做沖刺待辦事項的一部分。
問答：
- 問題11 產(chǎn)品負責(zé)人從利益相關(guān)者那里收到的需求文檔轉(zhuǎn)換為故事卡片，給到你并要求對其進行估算。 你對此程序感覺如何？
問題意圖：產(chǎn)品經(jīng)理是否可以直接把用戶需求轉(zhuǎn)化為故事卡片，而作為Scrum Master是否允許類似行為？
可接受的回答：
- 產(chǎn)品經(jīng)理不可直接把用戶需求轉(zhuǎn)化為故事卡片，Scrum Master決不能接受這種流程，這是用偽敏捷的方式來掩飾瀑布流方法；
- 組織應(yīng)該專注于為客戶提供價值，則必須放棄類似不經(jīng)過Scrum團隊成員共同評估產(chǎn)品需求的過程（對需要構(gòu)建的內(nèi)容達成一致意見），而只是進行開發(fā)階段的做法；
關(guān)鍵點：需求評估需要團隊成員一起評估
- 問題12 您需要產(chǎn)品負責(zé)人提供什么樣的信息，以便為您的團隊提供有關(guān)產(chǎn)品和市場情況的最新信息？
問題意圖：候選人是否有關(guān)注到Scrum做出產(chǎn)品的價值？
可接受的回答：
- 需要密切關(guān)乎到市場or客戶的反饋信息，可以有定性（能更快的幫助用戶）or定量的（用戶滿意度、用戶點擊率等）；
- 通過參與用戶訪談來參與收集相關(guān)信息，或是通過運營團隊獲取到相關(guān)的用戶數(shù)據(jù)；
關(guān)鍵點：客戶反饋信息，客戶反饋渠道
- 問題13 誰應(yīng)當(dāng)編寫用戶故事？
問題意圖：是否所有的用戶故事應(yīng)該由產(chǎn)品經(jīng)理來負責(zé)編寫？
可接受的回答：
- 需要Scrum團隊的共同努力，一起完成用戶故事的編寫；
- 好處：主人翁的歸屬感，如果是分派，可能導(dǎo)致團隊成員減少承諾，動力降低，最終導(dǎo)致產(chǎn)品質(zhì)量下降；
- 遵循用戶故事編寫規(guī)范（問題14）；
關(guān)鍵點：用戶故事編寫，全員完成，主人翁意識
- 問題14 好的用戶故事是什么樣的？它的結(jié)構(gòu)是什么樣的？
問題意圖：候選人是否了解用戶故事的編寫規(guī)范？什么才是一個好的用戶故事？
可接受的回答：好的用戶故事應(yīng)當(dāng)具備以下特征：
- 包含描述;
- 具有可接受標(biāo)準(zhǔn)定義；
- 能夠在單個沖刺中交付；
- 具有所有可用的UI交付物；
- 具有所有（可能的）依賴項確認；
- 具有性能標(biāo)準(zhǔn)的定義（達到什么樣的性能）；
- 具有跟蹤標(biāo)準(zhǔn)的定義（各階段應(yīng)該實現(xiàn)哪些功能）；
- 是整個Scrum團隊估算的；
里面涉及了一些標(biāo)準(zhǔn)的定義，其實可以歸結(jié)于DoD（完成的定義），即整合一下：
- 需求的基本描述，（作為xx，想要xx，為了xxx）；
- 能在一個沖刺中交付；
- 相關(guān)依賴項確認（UI、UX文件、架構(gòu)變更、數(shù)據(jù)準(zhǔn)備）；
- DoD；
- 團隊成員全員估算；
關(guān)鍵點：DoD， 全員估算完成，用戶故事編寫；
- 問題15 就緒的定義應(yīng)包括什么？
問題意圖：什么樣才是一個好的用戶故事？
可接受的回答：
- 同問題14，已經(jīng)告知用戶故事應(yīng)該包含哪些信息；
- 采用用戶故事使用框架(INVEST):
- Independent(獨立的): 自包含，與其他用戶故事沒有依賴；
- Negotiable(可討論到): 在進入沖刺計劃之前，是可以重寫和變更的；
- Valuable to Pruchasers or Users(有價值的): 對客戶是有價值的；
- Estimateable(可評估的): 可以評估用戶故事的大小；
- Small(小的): 不應(yīng)該太大，超過20小時，就應(yīng)該進行分拆；
- Testable(可測試的): 可通過測試的方式來定義完成狀態(tài)；
關(guān)鍵點：用戶故事編寫要點；
- 問題16 為什么不能簡單按工時估算用戶故事？
問題意圖： 如何進行用戶故事的評估；
可接受的回答：
- 人月神話中告訴我們了人力和時間不能簡單的進行轉(zhuǎn)化，人-小時的評估方式也是類似。
- 真正目的是為了讓團隊所有成員之間建立未來任務(wù)的共識，所以，估算只是一個副產(chǎn)品；
- 故事點的估算是一個好方法，可以準(zhǔn)確反映出任務(wù)的復(fù)雜性和完成任務(wù)所需要的精力，可以使用planning Poker；
- 用工時代替故事點來估算是傳統(tǒng)的成本和預(yù)算項目管理，是實施了瀑布式的流程。
關(guān)鍵點： 故事點估算，plannig Poker；
- 問題17 你的Scrum團隊的產(chǎn)品負經(jīng)理傾向于將各種想法添加到產(chǎn)品待辦事項列表中，工作下一個階段工作的提醒，隨著時間的累積，導(dǎo)致在過個階段累積了200多個卡片，你對這種情況有什么想法？一個scrum團隊能夠從事200個故事卡嗎？
問題意圖： 產(chǎn)品經(jīng)理的待辦事項的管理；
可接受的回答：
- 任何一個產(chǎn)品的代辦事項如果超出2-3個沖刺的范圍是很難進行管理的；
- 需要與產(chǎn)品經(jīng)理溝通，支持產(chǎn)品經(jīng)理進行待辦事項的管理，與干系人溝通，重新確認代辦事項的優(yōu)先級排序，重新整理相關(guān)人力；
關(guān)鍵點： 代辦事項管理，干系人的需求輸入。
