การวางแผนสปรินต์: วิธีจัดประชุมที่ผ่านสปรินต์ได้สำเร็จ

มีเหตุผลที่การพยากรณ์อากาศบอกคุณว่ามีโอกาสฝนตก 70% แทนที่จะสัญญาว่าฝนจะตกตอน 3 โมงเย็นพอดี พวกเขาใช้ข้อมูลที่มีอยู่ คำนึงถึงความไม่แน่นอน และอัปเดตเมื่อมีข้อมูลใหม่เข้ามา คุณยังสามารถวางแผนช่วงบ่ายของคุณตามการพยากรณ์นี้ได้ ตราบใดที่คุณไม่เข้าใจผิดว่าการพยากรณ์นี้เป็นการรับประกัน

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

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

คู่มือนี้ครอบคลุมการเตรียมงานในแบ็กล็อก (backlog), กำหนดการวางแผนที่มีเวลาชัดเจน, การคำนวณความจุที่ใช้งานได้จริง และตัวอย่างที่แสดงวิธีการปรับแผนระหว่างสปรินต์

การวางแผนสปรินต์คืออะไร?

การวางแผนสปรินต์ (Sprint planning) เป็นกิจกรรมใน Scrum ที่จัดขึ้นในช่วงต้นของสปรินต์แต่ละครั้ง เพื่อตกลงกันว่าทีมต้องการบรรลุเป้าหมายอะไร และจะดำเนินการทำงานอย่างไร กิจกรรมนี้รวบรวมทีม Scrum ทั้งหมดมาทำงานร่วมกัน รวมถึง Product Owner, Scrum Master และนักพัฒนา ส่วนผู้เชี่ยวชาญอื่น ๆ เช่น วิศวกรด้านความปลอดภัย หรือผู้นำทีมที่ติดต่อกับลูกค้า ก็สามารถเข้าร่วมได้เมื่อความคิดเห็นของพวกเขาช่วยทีมในการตัดสินใจอย่างมีข้อมูลครบถ้วน

ตามคู่มือScrum (Scrum Guide) ทุกเซสชันการวางแผนควรสร้างผลลัพธ์สามอย่าง ได้แก่ เป้าหมายสปรินต์ที่อธิบายถึงมูลค่าของงาน การเลือกรายการใน product backlog ที่สนับสนุนเป้าหมายดังกล่าว และแผนเบื้องต้นสำหรับการส่งมอบรายการเหล่านั้น เมื่อรวมกันแล้ว สิ่งเหล่านี้จะก่อตัวเป็น sprint backlog ซึ่งนักพัฒนาจะอัปเดตอย่างต่อเนื่องตามความคืบหน้าของสปรินต์

คู่มือ Scrum กำหนดเวลาสูงสุด 8 ชั่วโมงสำหรับสปรินต์หนึ่งเดือน และสปรินต์ที่สั้นกว่ามักต้องการเวลาน้อยกว่า ด้วยแบ็กโลกที่ได้รับการปรับปรุงอย่างดี กำหนดการด้านล่างนี้สามารถเสร็จสิ้นภายใน 2 ชั่วโมง

หากคุณยังไม่คุ้นเคยกับบางคำศัพท์เหล่านี้ คำอธิบายศัพท์ของเราจะอธิบายพื้นฐานของAgile และ Scrum

สามคำถามที่การวางแผนสปรินต์ช่วยตอบ

ทุกเซสชันการวางแผนสปรินต์จะหมุนรอบสามคำถามหลัก:

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

ทำไมสปรินต์จึงสำคัญ

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

อธิบายผลลัพธ์ที่ทุกคนสามารถรับรู้ได้ เช่น “ผู้ใช้ทดลองสามารถเชิญเพื่อนในทีมได้” แทนที่จะตั้งเป้าหมายปริมาณงาน เช่น “เสร็จสิ้น 34 story points” หากเกิดปัญหาที่ไม่คาดคิดขึ้น เป้าหมายนี้จะช่วยให้ทีมตัดสินใจได้ว่าควรปรับงานส่วนใด โดยยังคงรักษาผลลัพธ์ที่ตั้งใจไว้

สิ่งที่ทีมสามารถเสร็จสิ้นในสปรินต์นี้

เมื่อได้ตกลงกันเกี่ยวกับเป้าหมายแล้ว ก็ถึงเวลาที่จะกำหนดว่าทีมสามารถส่งมอบงานได้เท่าใดอย่างเป็นจริงเป็นจัง

นักพัฒนาจะเลือกรายการในแบ็กล็อกผ่านการหารือกับเจ้าของผลิตภัณฑ์ (Product Owner) โดยพิจารณาถึงกำลังงานที่มีอยู่ ประสิทธิภาพในอดีต และนิยามการเสร็จสิ้น (Definition of Done) นอกจากนี้ ยังเป็นช่วงเวลาที่เหมาะสมในการทบทวนข้อผูกพันที่มีอยู่ ซึ่งอาจส่งผลต่อเวลาที่ทีมมีไว้สำหรับงานในสปรินต์

ทีมหลายทีมใช้story pointsเพื่อเปรียบเทียบความยากและความซับซ้อนของรายการใน backlog แบบสัมพัทธ์มาตรวัดแบบฟีโบนัชชีสามารถช่วยจัดโครงสร้างการอภิปรายเหล่านั้นได้ โดยเฉพาะอย่างยิ่งเมื่อความยากของงานยังไม่ชัดเจน

วิธีที่ทีมจะดำเนินการงาน

เมื่อเลือกงานในแบ็กล็อกแล้ว นักพัฒนาจะวางแผนว่าจะเปลี่ยนงานเหล่านั้นให้เป็นส่วนเพิ่มของผลิตภัณฑ์ที่เสร็จสมบูรณ์ ซึ่งตรงกับนิยามของ "เสร็จสมบูรณ์" (Definition of Done) คู่มือ Scrum แนะนำให้แบ่งงานขนาดใหญ่เป็นงานย่อยๆ ซึ่งมักมีขนาดที่สามารถทำเสร็จภายในหนึ่งวันหรือน้อยกว่า

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

ดังที่Dave West, CEO ของ Scrum.org, ได้อธิบายไว้ว่า:

การคาดการณ์ที่ใช้เพื่อปกป้องกำหนดเวลาจะก่อให้เกิดพฤติกรรมที่ทำลายความเชื่อมั่น เช่น การเพิ่มตัวเลขการประมาณการให้สูงเกินจริง การซ่อนความเสี่ยง หรือการปรับนิยามคำว่า ‘เสร็จ’ อย่างเงียบๆ เพื่อให้บรรลุตัวเลขที่กำหนด

ความแตกต่างระหว่างการวางแผนสปรินต์และการปรับปรุงแบ็กโลกคืออะไร?

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

กิจกรรมทั้งสองมีวัตถุประสงค์ที่แตกต่างกันภายใน Scrum:

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

วิธีเตรียมตัวสำหรับการวางแผนสปรินต์

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

นี่คือรายการตรวจสอบที่ควรทำก่อนสปรินต์ครั้งต่อไป:

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

แผนงานการวางแผนสปรินต์: ตัวอย่างที่มีกำหนดเวลาสำหรับสปรินต์ 2 สัปดาห์

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

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

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

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

วิธีดำเนินการวางแผนสปรินต์ใน 6 ขั้นตอน

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

ขั้นตอน 1: ทบทวนงานที่ผ่านมาและตกลงกันเกี่ยวกับเป้าหมายของสปรินต์

เริ่มด้วยการทบทวนสั้นๆ ว่างานใดได้เสร็จสิ้นแล้ว งานใดยังค้างอยู่ และว่ามาตรการจากเซสชันทบทวนย้อนหลัง (retrospective) ใดควรมีผลต่อสปรินต์ถัดไป ให้เน้นไปที่เรื่องที่อาจเปลี่ยนแปลงลำดับความสำคัญหรือวิธีการทำงานของทีม แทนที่จะทบทวนเซสชันทบทวนสปรินต์ทั้งหมดอีกครั้ง

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

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

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

ขั้นตอนที่ 2: คำนวณความสามารถในการทำงานที่มีอยู่ของทีม

ก่อนที่จะเลือกงาน ให้กำหนดก่อนว่านักพัฒนาของคุณสามารถจัดสรรเวลาให้สปรินต์ได้เท่าใดอย่างเป็นจริงเป็นจัง

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

การคำนวณที่ง่ายคือ: ความจุที่มีอยู่ = จำนวนชั่วโมงทำงานทั้งหมด − ภาระงานที่ทราบ

ตัวอย่างเช่น ผู้พัฒนาที่มีเวลาทำงาน 80 ชั่วโมงในสองสัปดาห์ อาจมีเวลาหยุด 8 ชั่วโมง เวลาประชุม 10 ชั่วโมง และเวลาปฏิบัติหน้าที่สนับสนุน 12 ชั่วโมง ซึ่งเหลือเวลาทำงาน 50 ชั่วโมง ก่อนที่จะพิจารณาปัจจัยความไม่แน่นอนเพิ่มเติม

เปรียบเทียบตัวเลขนี้กับผลการปฏิบัติงานในอดีตของทีม Velocity แสดงปริมาณงานที่ทีมได้เสร็จสิ้นในสปรินต์ที่ผ่านมา ส่วน Capacity สะท้อนถึงเวลาที่มีอยู่สำหรับสปรินต์นี้

ขั้นตอนที่ 3: ประเมินใหม่งานที่ยังไม่เสร็จจากสปรินต์ก่อนหน้า

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

ตรวจสอบแต่ละข้อกับ Product Owner และพิจารณา:

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

ขั้นตอนที่ 4: เลือกงานในแบ็กล็อกที่สนับสนุนเป้าหมาย

เมื่อเข้าใจความสามารถในการทำงานและงานที่ยังค้างอยู่ นักพัฒนาสามารถเลือกรายการใน Product Backlog ที่พวกเขาเชื่อว่าจะสามารถทำให้เสร็จได้

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

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

คุณควรสำรองความจุไว้เท่าใด?

การวางแผนเพียง 80% ของความจุที่มีอยู่ อาจเป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับทีมที่ต้องจัดการงานสนับสนุนที่ไม่คาดคิดเป็นประจำ แต่ Scrum ไม่ได้กำหนดเปอร์เซ็นต์ที่ตายตัว

หากทีมของคุณเคยประสบกับการขัดจังหวะบ่อยครั้ง คุณสามารถสำรอง 10–20% ของความจุที่ปรับแล้ว และเปรียบเทียบส่วนสำรองนั้นกับสิ่งที่จำเป็นในสปรินต์ก่อนหน้า ทีมที่มีงานที่มั่นคงและมีการขัดจังหวะน้อยอาจต้องการส่วนสำรองน้อยกว่า ส่วนทีมที่สนับสนุนบริการที่ใช้งานจริงและเกิดเหตุการณ์ขัดจังหวะบ่อยครั้งอาจต้องการส่วนสำรองมากกว่า

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

ขั้นตอนที่ 5: แบ่งงานออกเป็นส่วนย่อยและตรวจสอบความขึ้นอยู่กับกัน

เมื่อเลือกงานในแบ็กโลกแล้ว ผู้พัฒนาสามารถวางแผนวิธีการส่งมอบงานเหล่านั้นได้ ซึ่งอาจรวมถึงการแบ่งงานขนาดใหญ่เป็นงานพัฒนา การทดสอบ การบูรณาการ และงานตรวจสอบ

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

วางแผนงานในระยะสั้นอย่างละเอียดมากขึ้น โดยทิ้งงานในระยะต่อไปไว้เพื่อหารือเพิ่มเติม คู่มือ Scrum แนะนำให้แบ่งงานที่เลือกไว้เป็นงานย่อยๆ ซึ่งโดยทั่วไปมีขนาดไม่เกินหนึ่งวัน แต่ผู้พัฒนาจะเป็นผู้ตัดสินใจว่าจะจัดระเบียบและแบ่งงานอย่างไร

ตรวจสอบให้แน่ใจว่าแผนดังกล่าวได้พิจารณาถึง "Definition of Done" (DOD) รวมถึงงานทดสอบและงานบูรณาการที่จำเป็น หากมีความพึ่งพาที่อาจขัดขวางการส่งมอบ ให้ทบทวนรายการที่เลือกไว้หรือปรับวิธีการส่งมอบก่อนที่จะสรุปแผน

ขั้นตอนที่ 6: กำหนดและแบ่งปันสปรินต์แบ็กโลก

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

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

ระหว่างสปรินต์ การประชุม Daily Scrum ให้โอกาสแก่ผู้พัฒนาในการตรวจสอบความคืบหน้าสู่เป้าหมายและปรับเปลี่ยนสปรินต์แบ็กล็อกแผนภูมิ burndown หรือ burnupสามารถช่วยแสดงความเปลี่ยนแปลงในความคืบหน้าได้ ในขณะที่งานย่อยที่อยู่เบื้องหลังจะให้รายละเอียดเพิ่มเติม หากข้อมูลใหม่ส่งผลต่อขอบเขตงานที่เลือกไว้ ผู้พัฒนาสามารถหารือเกี่ยวกับการปรับเปลี่ยนกับ Product Owner ได้ โดยไม่ทำให้เป้าหมายสปรินต์ตกอยู่ในความเสี่ยง

ตัวอย่างการวางแผนสปรินต์: ทีมที่มีนักพัฒนา 6 คน

มาดูกันว่า การตัดสินใจเหล่านี้ทำงานอย่างไรในปฏิบัติ

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

ก่อนที่จะเลือกรายการในแบ็กล็อก คุณต้องทราบว่าทีมมีเวลาว่างเท่าใด สำหรับตัวอย่างนี้ ให้สมมติว่าผู้พัฒนาแต่ละคนมีเวลาทำงานโครงการอย่างเต็มที่ 6 ชั่วโมงต่อวัน ก่อนที่จะหักเวลาสำหรับกิจกรรม Scrum ที่วางแผนไว้และภาระงานอื่น ๆ

นี่คือวิธีการคำนวณความจุตลอด 10 วันทำงาน:

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

เลือกงานที่สนับสนุนเป้าหมายของสปรินต์

เมื่อกำหนดความจุได้แล้ว ผู้พัฒนาจะตรวจสอบรายการในแบ็กล็อกที่เกี่ยวข้องกับการเช็คเอาต์ร่วมกับ Product Owner

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

การประมาณการเหล่านี้เหลือเวลา 6 ชั่วโมงภายในกรอบเวลาที่จัดสรรไว้สำหรับงานที่วางแผนไว้ พร้อมด้วยเวลาสำรอง 54 ชั่วโมงสำหรับงานที่ไม่คาดคิด ทีมยังมีแผนปรับปรุงแดชบอร์ดรายงานใน Product Backlog ด้วย แม้ว่าจะมีความสำคัญ แต่ไม่ได้มีส่วนช่วยโดยตรงต่อเป้าหมายการส่งมอบ Product Owner และนักพัฒนาจึงตกลงที่จะเลื่อนการปรับปรุงนี้ไปทำในสปรินต์ถัดไป

ปรับแผนเมื่อมีสิ่งใดเปลี่ยนแปลง

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

แทนที่จะดำเนินการตามคำสั่งงานเดิมต่อไป พวกเขาจะหารือเกี่ยวกับผลกระทบกับ Product Owner หากการแก้ไขอยู่ในขอบเขตของกำลังงานที่เหลืออยู่ พวกเขาสามารถจัดลำดับความสำคัญให้กับการแก้ไขนั้น และเลื่อนการจัดรูปแบบใบรับสินค้าที่เป็นตัวเลือก หรืองานอื่นที่มีลำดับความสำคัญต่ำกว่าออกไป การยืนยันการชำระเงินและงานสำคัญอื่น ๆ ยังต้องเป็นไปตามนิยามของ "เสร็จสมบูรณ์" (Definition of Done)

หากการแก้ไขมีขนาดใหญ่กว่าที่คาดไว้ พวกเขาจะต้องประเมินใหม่เกี่ยวกับขอบเขตงานที่เหลืออยู่ และพิจารณาว่าเป้าหมายของสปรินต์ยังสามารถบรรลุได้หรือไม่

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

ตัวอย่างเป้าหมายสปรินต์สำหรับทีมอื่น ๆ

คุณสามารถนำวิธีการวางแผนเดียวกันนี้ไปใช้กับงานนอกเหนือจากการพัฒนาซอฟต์แวร์ได้ แม้ว่า Scrum เองจะเป็นกรอบงานเฉพาะที่มีหน้าที่รับผิดชอบและกิจกรรมที่กำหนดไว้อย่างชัดเจน

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

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

ข้อผิดพลาดทั่วไปในการวางแผนสปรินต์และวิธีแก้ไข

การวางแผนสปรินต์อาจเกิดปัญหาได้เมื่อทีมใช้คะแนนเรื่องราว (story points) เพื่อประเมินประสิทธิภาพของบุคคลแต่ละคน นำรายการงานที่ยังไม่ชัดเจนในแบ็กโลก (backlog) เข้ามาในประชุม จัดสรรงานอย่างเคร่งครัดเกินไป หรือมองข้ามข้อกำหนดการทดสอบและความพึ่งพาจากภายนอก

การปรับเปลี่ยนเล็กน้อยสามารถช่วยคุณตรวจพบปัญหาเหล่านี้ก่อนที่จะส่งผลกระทบต่อกระบวนการส่งมอบ

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

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

วิธีดำเนินการวางแผนสปรินต์ใน ClickUp

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

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

ดาวน์โหลดแม่แบบฟรี

ต่อไปนี้คือวิธีดำเนินการตัดสินใจสำคัญต่างๆ:

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

ราคา ClickUp

คุณควรวางแผนล่วงหน้าก่อนเริ่มสปรินต์เท่าใด?

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

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

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

คำถามที่มักถูกถามเกี่ยวกับการวางแผนสปรินต์

ความแตกต่างระหว่างการวางแผนสปรินต์และการวางแผนการปล่อยเวอร์ชันคืออะไร?

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

คุณต้องการ "Definition of Ready" สำหรับการวางแผนสปรินต์หรือไม่?

ไม่ Scrum ไม่ต้องการ “Definition of Ready” อย่างเป็นทางการ บางทีมใช้เกณฑ์นี้เพื่อกำหนดความคาดหวังร่วมกันสำหรับรายการใน Backlog ก่อนการเลือก เช่น ข้อกำหนดที่ชัดเจน ขอบเขตที่สามารถจัดการได้ และความพึ่งพาที่ทราบไว้ ให้เกณฑ์เหล่านี้มีความเรียบง่ายพอที่จะสนับสนุนการอภิปราย โดยไม่ขัดขวางทีมในการปรับปรุงรายการเมื่อจำเป็น

สามารถยกเลิกสปรินต์ได้หรือไม่หลังจากวางแผนแล้ว?

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

ความแตกต่างระหว่างสปรินต์และอไจล์คืออะไร?

Agile เป็นวิธีการจัดการงานที่กว้างขวางยิ่งขึ้น ซึ่งอิงตามค่านิยมและหลักการของAgile Manifesto สปรินต์ (Sprint) คือช่วงเวลาที่กำหนดไว้ล่วงหน้า ซึ่งมีความยาวไม่เกินหนึ่งเดือนภายในกรอบงาน Scrum โดยในช่วงเวลาดังกล่าว ทีมจะทำงานเพื่อบรรลุเป้าหมายของสปรินต์ และสร้างส่วนเพิ่ม (increment) ที่สามารถใช้งานได้ คุณสามารถปฏิบัติตามหลักการ Agile ได้โดยไม่ต้องใช้สปรินต์ ตัวอย่างเช่น Kanban สนับสนุนการไหลของงานอย่างต่อเนื่อง โดยไม่จำเป็นต้องมีรอบการทำงาน (iteration) ที่มีความยาวคงที่

สปรินต์หนึ่งสามารถมีเป้าหมายสปรินต์หลายข้อได้หรือไม่?

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

ควรประมาณค่าข้อผิดพลาดในสตอรีพอยต์ระหว่างการวางแผนสปรินต์หรือไม่?

คะแนนเรื่องราว (Story points) เป็นตัวเลือกใน Scrum รวมถึงสำหรับข้อผิดพลาดด้วย ทีมที่ประเมินข้อผิดพลาดควรตกลงกันว่าจะทำเมื่อใดและทำไม ข้อผิดพลาดที่ทราบไว้ล่วงหน้าสามารถประเมินได้ระหว่างการวางแผน ส่วนข้อผิดพลาดที่พบระหว่างการพัฒนาอาจอยู่ในงานที่จำเป็นต้องทำอยู่แล้วเพื่อให้ตรงกับนิยามของงานที่เสร็จสมบูรณ์ (Definition of Done) หลีกเลี่ยงการนับความพยายามเดียวกันสองครั้ง