การวางแผนสปรินต์: แนวปฏิบัติ Agile ดีที่สุด

ประเด็นสำคัญ

พื้นฐานการวางแผน

การวางแผนสปรินต์ที่มีคุณภาพต้องการแนวทางที่มีโครงสร้าง ซึ่งรวมถึงการวิเคราะห์สปรินต์ก่อนหน้านี้ ประเมินความสามารถของทีม และกำหนดวัตถุประสงค์อย่างชัดเจน

1. การเตรียมการสำหรับการวางแผนควรเริ่มต้นล่วงหน้านาน Product Owner ต้องเตรียมและจัดลำดับความสำคัญ backlog อย่างน้อยหนึ่งวันก่อนการประชุม ทีมพัฒนาควรมีโอกาสตรวจสอบ user story ล่วงหน้าและถามคำถามเพื่อความกระจ่าง
2. กฎการจัดสรรแบบคลาสสิก: สองชั่วโมงของการวางแผนต่อสัปดาห์ของสปรินต์ สำหรับสปรินต์สองสัปดาห์ นั่นหมายถึงสี่ชั่วโมง — แม้ว่าการปฏิบัติจะแสดงให้เห็นว่ามักจะมีประสิทธิภาพมากกว่าหากแบ่งเวลานี้ออกเป็นหลายช่วงสั้นๆ แทนการประชุมต่อเนื่องเพียงครั้งเดียว

ช่วงการเตรียมการ

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

• Definition of Ready (DoR) กำหนดเกณฑ์สำหรับความพร้อมของ user story ก่อนนำเข้าสู่สปรินต์ แต่ละเรื่องควรมีเกณฑ์การยอมรับที่ชัดเจน การประเมินความซับซ้อน และการพึ่งพากับงานอื่นๆ ที่ระบุไว้ หากไม่ปฏิบัติตาม DoR การวางแผนจะกลายเป็นความวุ่นวาย โดยทีมใช้เวลาในการอธิบายมากกว่าการวางแผนการดำเนินการ
• Backlog refinement ควรเกิดขึ้นอย่างสม่ำเสมอ ไม่เพียงแค่ก่อนการวางแผนสปรินต์เท่านั้น การจัดสรร 10% ของเวลาสปรินต์สำหรับกระบวนการนี้เป็นการปฏิบัติมาตรฐาน ทีมสามารถจัดเซสชั่นการปรับปรุงสั้นๆ หลายครั้งต่อสัปดาห์ โดยทำงานกับเรื่องสำหรับสปรินต์ในอนาคตอย่างเป็นขั้นเป็นตอน
• การวิเคราะห์ Velocity ให้ภาพที่แม่นยำเกี่ยวกับความสามารถในการส่งมอบที่แท้จริงแก่ทีม สิ่งสำคัญคือต้องพิจารณาไม่เพียง Velocity เฉลี่ยของ 3-5 สปรินต์ล่าสุดเท่านั้น แต่ยังรวมถึงปัจจัยที่อาจส่งผลต่อประสิทธิภาพในสปรินต์ที่จะมาถึง: การลาที่กำหนดไว้ วันหยุด หนี้ทางเทคนิคสะสม หรือการพึ่งพาภายนอก

เซสชั่นการวางแผน

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

1. ทีมร่วมกับ Product Owner กำหนดเป้าหมายสปรินต์ที่รวมเป็นเอกภาพของ user story ที่เลือกทั้งหมด เป้าหมายควรเฉพาะเจาะจง วัดได้ และมีความหมายต่อผู้เข้าร่วมทั้งหมด เป้าหมายที่ไม่มีประสิทธิภาพ: "ปรับปรุงประสบการณ์ผู้ใช้" เป้าหมายที่มีประสิทธิภาพ: "ผู้ใช้จะสามารถลงทะเบียนผ่านโซเชียลมีเดียด้วยการคลิกครั้งเดียว"
2. ทีมพัฒนา แยกเรื่องที่เลือกออกเป็นงานและประเมินเป็นชั่วโมง กระบวนการนี้เผยให้เห็นความซับซ้อนและการพึ่งพาที่ซ่อนอยู่ซึ่งไม่ปรากฏที่ระดับเรื่อง แต่ละงานไม่ควรใช้เวลาเกิน 8 ชั่วโมง — งานที่เกินเกณฑ์นี้ต้องการการแบ่งย่อยเพิ่มเติมเป็นงานย่อย

บทบาทและความรับผิดชอบ

การวางแผนสปรินต์ที่มีประสิทธิภาพขึ้นอยู่กับผู้เข้าร่วมแต่ละคนเข้าใจและทำงานภายในบทบาทที่กำหนดไว้

• Scrum Master อำนวยความสะดวกในกระบวนการ บังคับใช้กล่องเวลา และช่วยให้ทีมตัดสินใจ Scrum Master ไม่บังคับใช้วิธีแก้ปัญหา แต่ถามคำถามที่ถูกต้องและรักษาการอภิปรายให้มีประสิทธิภาพ
• Product Owner มีหน้าที่รับผิดชอบในการจัดลำดับความสำคัญของ backlog และการตัดสินใจเกี่ยวกับฟีเจอร์ใดที่ควรนำไปใช้ก่อน พวกเขาต้องเตรียมพร้อมที่จะอธิบายมูลค่าทางธุรกิจของแต่ละเรื่องและตอบคำถามของทีมพัฒนาด้วยความเฉพาะเจาะจงเพียงพอที่จะทำให้สามารถประเมินได้
• ทีมพัฒนา ผูกมัดที่จะส่งมอบผลลัพธ์ ข้อผูกพันนี้ต้องมาจากทีมเองมากกว่าการได้รับมอบหมายจากภายนอก — ข้อผูกพันที่สร้างโดยทีมจะสร้างระดับของแรงจูงใจและความรับผิดชอบที่แตกต่างเชิงคุณภาพจากเป้าหมายที่ถูกบังคับ

ข้อผิดพลาดที่พบบ่อย

• การประเมินความสามารถสูงเกินไปเป็นข้อผิดพลาดในการวางแผนสปรินต์ที่พบบ่อยที่สุด ทีมรับงานมากกว่าที่พวกเขาจะทำเสร็จได้อย่างสม่ำเสมอ โดยเฉพาะอย่างยิ่งในตอนต้นของโครงการหรือหลังจากสปรินต์ที่ประสบความสำเร็จ หลักการดำเนินงานคือ: ดีกว่าที่จะให้สัญญาน้อยกว่าและส่งมอบมากกว่า ข้อผูกพันที่ไม่ปฏิบัติตามทำลายความไว้วางใจของผู้มีส่วนได้ส่วนเสียและลดแรงจูงใจของทีมในสปรินต์ต่อๆ มา
• การไม่มีบัฟเฟอร์เวลาเป็นข้อผิดพลาดเชิงโครงสร้างที่สำคัญ แผนสปรินต์ควรรวมเวลาบัฟเฟอร์ 10-20% สำหรับงานที่ไม่คาดคิด บั๊ก และคำขอการสนับสนุนทางเทคนิค ส่วนสำรองนี้ไม่ควรถูกเติมล่วงหน้าด้วยเรื่องเพิ่มเติม — หน้าที่ของมันคือดูดซับงานที่ไม่ได้วางแผนซึ่งมีอยู่ในทุกสปรินต์
• การละเลยการพึ่งพาจะสร้างตัวขัดขวางในกลางสปรินต์ การพึ่งพาภายนอกทั้งหมดต้องถูกระบุและแก้ไขในระหว่างการวางแผน เมื่องานพึ่งพาทีมอื่นหรือผู้ขายภายนอก ต้องมีการตกลงกำหนดเวลาล่วงหน้าและได้รับการยืนยันก่อนเริ่มสปรินต์

การตรวจสอบกระบวนการ

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

ตัวชี้วัดสำหรับการวิเคราะห์:

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

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

การปรับตัวการวางแผน

• ทีมระยะไกลต้องการการปรับตัวเฉพาะสำหรับการวางแผนสปรินต์ ต้องมีเครื่องมือการทำงานร่วมกันเฉพาะทาง และต้องมีการจัดการการมีส่วนร่วมที่เท่าเทียมกันสำหรับผู้เข้าร่วมระยะไกลทุกคนอย่างแข็งขัน การจัดการวางแผนหลายเซสชั่นที่สั้นกว่าแทนการประชุมต่อเนื่องเดียวจะสร้างการมีส่วนร่วมและคุณภาพผลลัพธ์ที่ดีกว่าอย่างสม่ำเสมอในบริบทแบบกระจาย
• โปรแกรมขนาดใหญ่ที่มีหลายทีมต้องการการประสานงานในระดับโปรแกรม Scrum of Scrums หรือ SAFe (Scaled Agile Framework) ให้กลไกเชิงโครงสร้างสำหรับการซิงโครไนซ์การวางแผนสปรินต์ข้ามทีมที่มีการพึ่งพาร่วมกัน
• โครงการบำรุงรักษา — ที่ส่วนสำคัญของเวลาสปรินต์ใช้สำหรับการสนับสนุนและการแก้ไขบั๊ก — ต้องมีการสำรองความสามารถอย่างชัดเจนสำหรับงานที่ไม่ได้วางแผน การจัดสรรมาตรฐาน 30-50% ของความสามารถสปรินต์สำหรับงานสนับสนุน โดยส่วนที่เหลือสามารถใช้สำหรับการพัฒนาฟีเจอร์ใหม่ ป้องกันความล้มเหลวในการส่งมอบที่เกิดจากการปฏิบัติต่องานสนับสนุนเป็นค่าใช้จ่ายเพิ่มเติมแทนที่จะเป็นความสามารถที่วางแผนไว้

บทความที่เกี่ยวข้อง:

สำหรับกรอบงานการจัดการโครงการและการสร้างสมดุลข้อจำกัด อ่าน สามเหลี่ยมการจัดการโครงการ: สร้างสมดุลขอบเขต เวลา ต้นทุน

สำหรับภาพรวมเชิงปฏิบัติของบอร์ด Kanban และการจัดการเวิร์กโฟลว์เชิงภาพ อ่าน บอร์ด Kanban คืออะไร? คู่มือการจัดการเวิร์กโฟลว์เชิงภาพ

สำหรับวิธีที่ทีม Agile ใช้บุคลิกเพื่อให้สอดคล้องกับความต้องการของผู้ใช้จริง อ่าน บุคลิก Agile: เสริมการพัฒนาที่เน้นผู้ใช้ในโครงการ Agile

บทสรุป

การวางแผนสปรินต์ที่มีประสิทธิภาพต้องการแนวทางที่เป็นระบบและการปรับปรุงอย่างต่อเนื่องเป็นการปฏิบัติโดยเจตนา ไม่ใช่กิจกรรมหลังโครงการ การทบทวนย้อนหลังให้กลไกที่มีโครงสร้างสำหรับการวิเคราะห์ไม่เพียงผลการดำเนินงานสปรินต์เท่านั้น แต่ยังรวมถึงอินพุตการวางแผนที่กำหนดรูปแบบ — ทำให้กระบวนการวางแผนเองอยู่ภายใต้การปรับปรุงแบบวนซ้ำเช่นเดียวกับที่ Agile ใช้กับการพัฒนาผลิตภัณฑ์

การอ่านที่แนะนำ

"Scrum: The Art of Doing Twice the Work in Half the Time"

อธิบายวิธีที่เฟรมเวิร์ก Scrum จัดโครงสร้างงานของทีมเพื่อให้บรรลุปริมาณการส่งมอบที่สูงด้วยข้อผูกพันสปรินต์ที่คาดการณ์ได้

"User Story Mapping: Discover the Whole Story, Build the Right Product"

การทำแผนที่เรื่องเชิงภาพช่วยให้ทีมพัฒนาความเข้าใจร่วมกันเกี่ยวกับเป้าหมายผลิตภัณฑ์และจัดโครงสร้างการวางแผนสปรินต์รอบลำดับความสำคัญที่เน้นผู้ใช้

"Essential Scrum: A Practical Guide to the Most Popular Agile Process"

เอกสารอ้างอิงที่ครอบคลุมเกี่ยวกับโครงสร้าง บทบาท และแนวปฏิบัติของ Scrum สำหรับทีมที่ใช้เฟรมเวิร์กในงานประจำวัน