衝刺規劃會議
大部分短期衝刺規劃都牽涉到產品擁有者和團隊之間的談判，以決定即將短期衝刺中的重點和工作。 對規劃會議進行計時，將會議限製為4小時或更少，這非常有用。
在會議的第一部分中，您的產品負責人會與您的團隊會面，討論可能包含在衝刺周期中的使用者故事。 您的產品擁有者會分享資訊，並回答小組對於這些故事的任何問題。 此交談可能會顯示詳細數據，例如數據源和使用者介面配置。 或者，它可能會顯示回應時間預期，以及安全性和可用性的考慮。 您的小組應該在待辦項目窗體中擷取這些詳細數據。 在會議的這個部分中，您的小組會瞭解其必須建置的內容。
當您計劃短衝時，可能會發現需要將其他需求擷取並添加到待辦事項中。 請確定其已妥善定義且依優先順序排列。
此外，將短期衝刺目標設定為規劃工作的一部分，可協助小組專注於每個短期衝刺最重要的專案。
規劃短期衝刺之後，您可能會想要與重要專案關係人
共享計劃
。
您可以從這些資源深入瞭解：
什麼是 Scrum？
短期衝刺規劃
白皮書
Scrum 指南
建置和管理產品待辦專案
白皮書
設定短期衝刺目標
Scrum 小組會使用短期衝刺目標來集中其短期衝刺活動。 他們通常會在短期衝刺規劃會議期間設定此目標。 目標摘要說明小組要在短期衝刺結束時完成的工作。 藉由明確說明目標，您可以在團隊內建立對核心目的的共同理解。 短期衝刺目標也可協助在優先順序發生衝突時引導小組。
實戰經驗的秘訣：定義衝刺週期目標
短期衝刺目標會定義產品擁有者和小組視為達成該短期衝刺的最終目標。
這不是隨機選取的一組沒有聯繫的待辦事項，而是一段概述小組應該努力完成目標的簡短文本。 通常，產品擁有者會先取得短期衝刺目標，再選取下一個短期衝刺的許多專案。 該短期衝刺的專案應全部符合該通用目標。
短期衝刺目標可以是功能導向，但也可能有大型程式元件，例如部署自動化或測試自動化。
此短期衝刺我們將著重於簡單的用戶劇本。 我們將使用它來證明建議的解決方案可運作。
開發衝刺將專注於實作能有效保護網站管理區段的安全功能。
此開發階段是整合最重要的付款網關，以便我們可以開始接收付款。
設定短期衝刺目標可協助小組保持專注。
它可讓您更輕鬆地在短期衝刺中定義工作的優先順序，而且可能有助於限制涉及項目關係人和終端用戶的數目。
在短期衝刺檢閱期間，您應該問自己最重要的問題是您是否設法達到短期衝刺目標。
你完成的故事數量並不是最重要的。 如果目標完成，短期衝刺就會成功，即使並非所有的故事都已完成。
由 Jesse Houwing
、Visual Studio devops Ranger 和一位為荷蘭 Avanade 荷蘭工作的資深顧問貢獻。
成功分級會議的秘訣
修正 Bug 代表與其他工作的取捨。 使用您的分級會議來判斷修正每個錯誤與符合專案範圍、預算和排程相關的其他優先順序有多重要。
建立團隊的準則，以評估哪些 bug 需要修正，並確定優先順序和嚴重性。 與提供重大價值的功能相關的 Bug（或因延遲而產生的重大機會成本），以及其他可能造成項目風險的 Bug，應被賦予較高的優先級和嚴重性。 使用其他小組檔儲存您的分級準則，並視需要更新。
使用篩選標準來判斷要修正的錯誤，以及如何設定其狀態、優先順序、嚴重性和其他欄位。
根據您的開發週期所在位置調整分級準則。 在早期，您可能會決定修正您篩選的大部分錯誤。 不過，在稍後的階段中，您可能會提高分級準則，以減少需要修正的錯誤數量。
將 Bug 分級之後，請將其指派給開發人員。 然後，開發人員可以調查並判斷如何實作修正程式。
管理您的技術債務
請考慮將管理缺陷列表和技術債務作為您團隊整體持續改進活動的一部分。 您可能會發現這些感興趣的資源：
亨里克·克尼伯格的好壞技術債務（以及TDD如何説明）
技術債務管理
，由 Sven Johann 和 Eberhard Wolff 發佈
從實戰中得來的技巧：錯誤管理
敏捷式 Bug 管理：不是矛盾詞
由 Microsoft 的 Visual Studio 雲端服務首席項目經理 Gregg Boer
解決每個開發週期的任何已知的程式錯誤債務
每次迭代，小組都會查看 Bug 待辦項目中剩餘的所有 Bug，並分配資源，以將已知 Bug 減少至零或接近零。 無論是一天、一周還是整個短衝，他們會先修正漏洞。 稍後在短期衝刺中發現的錯誤不會被視為該初始承諾的一部分。 除非它們是高優先順序，否則會放在下一個短期衝刺的 Bug 待辦專案上。
許多小組在承諾式組織中工作。 通常，管理對於小組履行承諾的能力具有很高的價值。 針對一組已知 Bug 執行容量規劃，可讓短期衝刺規劃更具決定性，以增加其符合承諾的機會。 在衝刺期間發現的任何新錯誤都不屬於初始承諾的一部分，可以在下一個衝刺中處理。
管理整個企業的 Bug 債務
一個轉型為持續消除債務的文化的組織可能會處理下列問題：如何讓小組減少其 Bug 計數，而不需要確切地告訴他們該怎麼做？ 領導階層希望團隊能夠改變，但讓團隊自主性來決定他們如何改變。 其中一個選項是使用錯誤上限。
例如，假設每個工程師有三個 Bug 的 Bug 上限。 因此，10 人的小組在其 Bug 待辦專案中不應該有超過 30 個 Bug。 如果小組超過上限，則預期會停止對新功能進行工作，並低於 Bug 上限。 一個團隊應該永遠處於上限之下，但團隊決定該如何做到這一點。 錯誤限制可確保小組不會累積過多的錯誤負擔。 團隊可以從導致 Bug 注入的錯誤中吸取教訓。
請記住，Bug 上限代表 Bug 待辦專案中的錯誤。 它不包含在開發功能之短期衝刺中找到並修正的錯誤。 這些錯誤被認為是復原的工作，而不是債務。
雖然錯誤會導致技術債務，但它們可能不代表所有債務。
軟體設計不佳、撰寫程序代碼不佳或短期修正都可能導致技術債務。 技術債務反映了所有這些問題帶來的額外發展工作。
追蹤工作，以 PBIs、用戶劇本或 Bug 的形式解決技術債務。 若要追蹤小組在產生和解決技術債務方面的進度，您會想要考慮如何分類工作專案和您想要追蹤的詳細數據。您可以將
標籤新增至任何工作專案，將其分組為您選擇的類別
。
Scrum 主管的角色
Scrum Masters 藉由採用 Scrum 程式來協助建置和維護狀況良好的小組。 他們引導、指導、教導和協助 Scrum 團隊適當地使用 Scrum 方法。 Scrum Masters 也作為變更代理程式，協助小組克服障礙，並推動團隊大幅提高生產力。
Scrum Masters 的核心責任包括：
支援小組採用並遵循 Scrum 程式。
例如，您不應該讓每日 Scrum 會議成為持續 45 分鐘的開放式討論。
防止產品擁有者或小組成員在短衝開始後新增工作。
清除封鎖問題，以防止小組進行向前進度。
這項工作可能需要您完成小型工作，例如核准新組建計算機的採購單，或解決小組內的衝突。
協助小組處理衝突和產生的問題，並從程序中學習。
提問以揭示隱藏問題，並確認所有溝通內容已被整個團隊充分理解。
找出潛在問題並保護小組，避免其發展成重大問題。 就像在發現 Bug 後不久修正 Bug 更便宜一樣，當團隊問題還很小且易於管理時，解決團隊問題也比較容易且較不干擾。
防止小組在
短期衝刺檢閱會議期間
呈現不完整的使用者故事。
向業務項目關係人收集、分析和呈現數據，以示範小組如何改善和成長。 例如，如果您的團隊在產生較少錯誤的情況下增加了所傳遞的價值的數量，請透過定期與業務利害關係人溝通來使此價值可見。
良好的 Scrum 大師有或開發優秀的溝通、談判和衝突解決技能。 他們積極傾聽人們說和寫的話。 他們還聽他們如何傳遞他們的資訊，例如他們的身體語言，面部表情，聲樂節奏和其他非語言溝通。
正如在發現 Bug 後不久修正更便宜一樣，在問題成長為重大問題之前，修正團隊問題也較容易且較不具干擾性。
每日 Scrum 會議
每日 Scrum 會議可協助讓小組專注於第二天需要做什麼。 保持專注可協助小組發揮最大能力，以符合短期衝刺承諾。 您的 Scrum Master 應該維持會議的結構，並確保會議準時開始，且在 15 分鐘內結束。
成功的 Scrum 會議有三個層面：
每個人都站起來。 站起來有助於保持會議專注和簡短。
它們會依時間開始和結束，並每天在同一個位置同時發生
每個人都參與，每個小組成員都會回答三個 Scrum 問題：
自從最近的 Scrum 以來，我已完成哪些工作？
我可以在下一個 Scrum 之前完成哪些工作？
哪些封鎖問題或障礙可能會影響我的工作？
小組成員應努力快速且簡潔地回答問題。 例如：
「昨天，我更新了 類別，以反映我們從資料庫提取的新數據元素，並讓它出現在 介面中。 這項工作已完成。 今天，我確保新的數據元素會正確地使用預存程式和數據表中的其他數據元素進行計算。 我相信我今天能完成這項工作。 我需要有人來檢閱我的計算。 我沒有阻礙或阻塞問題。
此回應會傳達小組成員完成的工作、小組成員計劃完成的工作，以及小組成員想要一些協助查看程序代碼。
與下一個範例形成對比：
昨天，我在準備課程，結果成功了。 今天，我在介面上工作。 沒有封鎖問題。
小組成員無法提供他們所處理之類別的足夠詳細數據，也無法提供其完成之介面元件的相關詳細數據。 事實上，「accomplished」這個詞從未出現過。
重要的是，沒有人在匯報時被打擾。 每個人必須有足夠的時間回答這三個問題。
會議結束後，應進行更深入的討論和跟進，可以在人們回到辦公桌前完成。如果需要進行大量的交流，則應安排後續會議。
許多小組會使用「虛擬停車場」方法來延遲討論。 當團隊成員發現需要進一步討論的主題時，他們可以悄悄地走到白板或翻頁板，然後將該主題列在待議事項清單上。 在會議結束時，小組會決定他們將如何處理列出的專案。
衝刺回顧會議
在短期衝刺的最後一天進行短期衝刺檢閱會議。 您的小組會示範在短期衝刺中完成的每個產品待辦專案。 產品擁有者、客戶和項目關係人接受符合其期望並識別任何新需求的使用者案例。 客戶在看到示範之後，通常會更充分地瞭解其需求，並可能識別想要查看的變更。
根據此會議，某些使用者故事被視為已完成。 不完整的使用者故事會保留在產品待辦清單中。 新的使用者故事會新增至待辦清單。 這兩組故事都會在下一次衝刺規劃會議上進行排名和估算或重新估算。
在此會議和回顧會議之後，您的團隊會規劃下一個衝刺。 由於業務需求會快速變更，因此您可以利用此會議與您的產品擁有者、客戶和項目關係人，再次檢閱產品待辦專案優先順序。
短期衝刺回顧會議
回顧會在妥善執行並定期進行時，能促進持續改善。
短期衝刺回顧會議通常發生在短期衝刺檢閱會議的最後一天。 在此會議中，您的小組會探索其 Scrum 的執行，以及可能需要調整的內容。
根據討論，您的小組可能會變更一或多個程式，以改善自己的效率、生產力、品質和滿意度。 此會議和產生的改進對於自我組織敏捷原則至關重要。
若要支援小組的回顧，請考慮安裝 Marketplace
回顧
延伸模組。 此延伸模組支援收集專案里程碑的意見反應、組織並排定意見反應的優先順序，以及建立和追蹤可採取動作的工作，以協助小組隨著時間改善。
在小組衝刺的回顧會議中，請著手解決這些問題：
-
影響小組一般有效性、生產力和質量的問題。
-
影響小組整體滿意度和專案流程的要素。
-
造成未完成的待辦項目會發生什麼事？ 小組未來可以採取哪些動作來防止這些問題？
例如，假設小組有數個工作，而小組中只有一個人可以執行。 孤立的專業知識創造了一條威脅衝刺成功的重要路徑。 某位隊員加班加點，而其他隊員則感到沮喪，因為他們無法做到更多來説明。 接下來，小組決定練習
eXtreme 程式設計
，以協助在一段時間內修正此問題。
以小組身分，努力判斷是否要調整一或多個程式，以將短期衝刺期間發生的問題降到最低。
您的小組可能需要執行一些工作來實作改進。 例如，發現自己受到太多失敗組建造成負面影響的小組決定實作持續整合。 因為他們不想中斷程式，所以在生產組建中開啟試用組建之前，他們花了幾個小時才設定試用組建。 為了代表這項工作，他們建立了尖峰，並組織了該工作與產品待辦項目的其餘部分。
短期衝刺活動結束
什麼是 Scrum？
敏捷回顧：讓優秀的團隊變得很棒
