เทมเพลตวาระประชุม Sprint Planning สำหรับทีมวิศวกรรม

ทำไม Sprint ถึงรับงานเกินตัว

Sprint Planning มีความล้มเหลวเชิงโครงสร้างอย่างหนึ่งที่เทมเพลตไม่ป้องกัน คือทีมเลือก Backlog ของ Sprint ก่อนที่ใครจะตรวจสอบกำลัง ผลลัพธ์คือ Sprint ที่ดูทำได้บนไวท์บอร์ดแล้วพังในวันพุธเมื่อวิศวกรสองคนลาครึ่งสัปดาห์ งานหนึ่งขยายขอบเขตเป็นสามเท่า และสามรายการมีการพึ่งพาที่ไม่ได้บอกไว้กับบริการที่ทีมแพลตฟอร์มกำลังเขียนใหม่

การแก้ไขเรียบง่ายและแทบไม่มีใครทำ คือให้คำมั่นกับกำลังก่อนให้คำมั่นกับงาน เทมเพลตด้านล่างเปิดด้วยการทบทวนกำลังทีมด้วยเหตุผลนั้นพอดี

วาระการประชุม (คัดลอกไปใช้ได้เลย)

ระยะเวลา: 2 ชั่วโมงสำหรับ Sprint 2 สัปดาห์ 1 ชั่วโมงสำหรับ Sprint 1 สัปดาห์
รูปแบบ: มีผู้ดำเนินรายการ โดยให้ทั้งทีมมองเห็น Backlog ได้

ส่วนที่ 1 — เป้าหมายของ Sprint (10 นาที)

หนึ่งประโยค: Sprint ที่สำเร็จมองจากภายนอกแล้วหน้าตาเป็นอย่างไร?
เป้าหมายควรเจาะจงพอที่สมาชิกทีมคนใดก็ตามจะประเมินตอนจบ Sprint ได้ว่าทำสำเร็จไหม
ปฏิเสธเป้าหมายที่เป็นแค่ลิสต์งาน ("ทำ auth refactor และหน้า billing ให้เสร็จ") — นั่นคือ Backlog ไม่ใช่เป้าหมาย

ส่วนที่ 2 — การทบทวนกำลังทีม (15 นาที)

ลิสต์สมาชิกทีมทุกคนตามชื่อ
สำหรับแต่ละคน: วันลาที่วางแผนไว้ การเข้าเวร การประชุมประจำ ภาระผูกพันภายนอกที่รู้อยู่
แสดงกำลังเป็น story point หรือจำนวนวันที่ว่าง — ไม่ใช่จำนวนหัว
ตัวเลขนี้คือเพดาน อย่าเลือกงานเกินกว่าที่มันรองรับได้

ส่วนที่ 3 — การเลือกจาก Backlog (45 นาที)

ไล่รายการที่มีลำดับความสำคัญสูงสุดจาก Backlog ที่ผ่านการ refine แล้ว
สำหรับผู้สมัครแต่ละรายการ: ทีมมีข้อมูลพอที่จะเริ่มไหม หรือมีคำถามที่เปิดค้างซึ่งต้องได้คำตอบก่อน Sprint เริ่ม? คำถามที่เปิดค้างอยู่ในคิว refinement ไม่ใช่ใน Sprint
หยุดเลือกเมื่อถึง 80% ของกำลัง อีก 20% ที่เหลือไว้รองรับงานที่ล้นและงานที่ไม่ได้วางแผน

ส่วนที่ 4 — เกณฑ์การยอมรับ (20 นาที)

สำหรับทุกรายการที่เลือก: ระบุเกณฑ์ที่ทำให้มันถือว่าเสร็จ
ถ้าทีมระบุเกณฑ์ไม่ได้ใน 60 วินาที แปลว่างานยังไม่ได้ refine พอ — ย้ายกลับไปที่ Backlog
เขียนลงใน ticket ตอนนี้เลย ในห้องประชุม อย่าพึ่งพา "ไว้เพิ่มทีหลัง"

ส่วนที่ 5 — ความเสี่ยงและการพึ่งพา (15 นาที)

อะไรที่อาจขวางการส่งมอบเป้าหมาย Sprint ที่ทีมควบคุมไม่ได้?
ระบุผู้รับผิดชอบการพึ่งพา นำมันขึ้นมาตอนนี้ในขณะที่ยังมีเวลาแก้ก่อนกลาง Sprint
การพึ่งพาที่ยังแก้ไม่ได้ต้องมีผู้รับผิดชอบที่ระบุชื่อจากทีมที่จะคอยติดตาม

ปิดท้าย (15 นาที)

ยืนยันว่าเป้าหมาย Sprint ยังใช้ได้เมื่อดูจากงานที่เลือกไว้
มอบหมายคนจดบันทึกสรุป Sprint หรือยืนยันการตั้งค่ารายงานอัตโนมัติ
ยืนยันวันวางแผนครั้งถัดไป

อะไรที่เทมเพลต Sprint Planning ส่วนใหญ่พลาดไป

เทมเพลต Sprint Planning ยอดนิยมที่สุดเน้นที่การจัดระเบียบ Backlog และนิยามของคำว่าเสร็จ ทั้งสองอย่างสำคัญ แต่ไม่มีอันไหนจัดการกับความผิดพลาดในการวางแผนที่ก่อให้เกิดความล้มเหลวของ Sprint มากที่สุด นั่นคือการเลือกงานโดยไม่ตรวจสอบความพร้อม

ทีมวิศวกรห้าคนที่กำลังเต็มมี story point ประมาณ 200 พอยต์ต่อ Sprint 2 สัปดาห์ ทีมห้าคนที่มีวิศวกรสองคนลาพัก หนึ่งคนหมุนเข้าเวร และอีกหนึ่งคนไปประชุมนอกสถานที่สามวัน อาจมีแค่ 110 พอยต์ ถ้าคุณเลือก 180 พอยต์ใน Sprint ที่สอง คุณล้มเหลวไปแล้ว ขั้นตอนการเลือกคือจุดที่การรับงานเกินเกิดขึ้น และกำลังต้องมาก่อนหน้ามัน

ช่องว่างที่สองคือเกณฑ์การยอมรับ ทีมมักวางแผนไปอย่างรวดเร็วและตั้งใจจะเขียนเกณฑ์ทีหลัง แต่ทีหลังไม่เกิดขึ้นในระดับความเจาะจงเดียวกัน คนที่จะเขียนเกณฑ์อย่างแม่นยำในห้องประชุมกลับเขียนอะไรกำกวมกว่าจากความทรงจำในวันถัดมา หรือไม่เขียนเลย ข้อขัดแย้งกลาง Sprint เรื่องความหมายของคำว่า "เสร็จ" เกือบทุกครั้งสาวกลับไปได้ถึงเกณฑ์การยอมรับที่ถูกข้ามในการวางแผน

ต้นทุนที่ทบต้นของช่องว่างเหล่านี้ — Sprint ที่รับงานเกิน การค้นพบกลาง Sprint นิยามที่ต้องถกกันใหม่ — ปรากฏชัดเมื่อคุณรวมมันเข้าด้วยกัน: ภาษีการประชุม

ทำไมบันทึก Sprint Planning จึงยากกว่าที่เห็น

Sprint Planning สร้างข้อมูลมากกว่าการประชุมประจำแทบทุกประเภท: เป้าหมาย Sprint ตัวเลขกำลัง เหตุผลการเลือกทีละรายการ เกณฑ์การยอมรับต่อ ticket ผู้รับผิดชอบการพึ่งพา รายการความเสี่ยง การเขียนสรุปที่มีประโยชน์ต้องเก็บทุกอย่างในรูปแบบที่ใช้ได้จริงในอีกสามวันถัดมาเมื่อมีคนถามว่า "ทำไมเราถึงตัดรายการนั้นออก?"

Pavleur สร้างรายงาน Sprint Planning โดยอัตโนมัติเมื่อจบการสนทนา มันเก็บเป้าหมาย Sprint, Backlog ที่เลือกพร้อมเหตุผล, เกณฑ์การยอมรับตามที่ระบุในการประชุม และผู้รับผิดชอบการพึ่งพาตามที่ระบุชื่อ ถ้าใครแชร์หน้าจอ Backlog หรือสเปรดชีตกำลังทีม ภาพนั้นจะถูกรวมไว้ในรายงานเคียงข้างการถกเถียง — บริบทที่เครื่องมือแบบเสียงอย่างเดียวอย่าง Otter หรือ Fireflies จะพลาดไปหมด ใครก็ตามที่เข้ามาช้าหรือต้องตรวจสอบการตัดสินใจกลาง Sprint จะมีบันทึกฉบับเต็ม สำหรับการเปรียบเทียบว่าสิ่งนี้ต่างจากเครื่องมือแบบเสียงอย่างเดียวอย่างไร: Pavleur เทียบกับทางเลือกอื่น

การรับมือกับการเปลี่ยนแผนกลาง Sprint

แผน Sprint เป็นคำมั่น ไม่ใช่สัญญา เมื่อมีอะไรกลาง Sprint ที่ทำให้แผนใช้ไม่ได้จริงๆ — เหตุการณ์บนโปรดักชัน การพึ่งพาสำคัญที่ขวางสาม ticket การเปลี่ยนลำดับความสำคัญจากผู้บริหาร — การตอบสนองที่ถูกต้องคือการนัดวางแผนใหม่อย่างรวดเร็ว ไม่ใช่การลดขอบเขตแบบเงียบๆ การนัดวางแผนใหม่ใช้เวลา 20 นาทีและผลิตเป้าหมาย Sprint ที่ปรับปรุงแล้วซึ่งสะท้อนความเป็นจริง ทางเลือกอื่นคือ Sprint ที่ล้มเหลวบนกระดาษแต่ถูกปรับอย่างไม่เป็นทางการในแบบที่ไม่มีใครจดไว้ ทำให้ Retrospective ยากขึ้นและตัวเลข velocity ไร้ความหมาย

สร้างนิสัยการวางแผนใหม่อย่างชัดเจน ใช้โครงสร้างเดิม: กำลังที่อัปเดต การเลือกที่ปรับปรุง เป้าหมายที่ระบุใหม่ มันใช้เวลาน้อยกว่าความสับสนที่มันป้องกันได้มาก