ทำไม PBL Refinement, Sp. Planning part 2 และ Sp. Review ใน Large Scale Scrum ถึงเป็น workshop style

Photo by Moralis Tsai on Unsplash

ใน Large Scale Scrum (LeSS) ซึ่งเป็นการทำสกรัมในบริบทที่มีทีมตั้งแต่ 2–8 ทีมรุมทำ product เดียวกัน เค้ามีแนะนำไว้ว่ากิจกรรมใดที่ทีมควรทำแยกกัน และกิจกรรมใดที่ควรทำรวมกัน ซึ่งวันนี้ผมจะแบ่งปัน 3 กิจกรรมซึ่งครอบคลุม flow ของ requirement ได้ดี

Product Backlog Refinement (PBL refinement)

PBL refinement เป็นจังหวะที่ทุกทีมจะมา ทำความเข้าใจปัญหาทางธุรกิจที่เรากำลังจะแก้ใน sprint หน้า ๆ ด้วยกัน ในจังหวะนี้เป็นจังหวะแรกที่ทีมอาจจะได้ทำความรู้จักกับ items ใหม่ ๆ Product Owner (PO) จะมาเล่าสถานาการณ์ทางธุรกิจและกลยุทธ์ในการจัดลำดับความสำคัญของ items ให้สมาชิกในทีมฟัง

ref: https://less.works

นอกจากนี้ ทีมจะ estimate item แบบ reletive (ใช้การเปรียบเทียบ) และถ้า item ไหนใหญ่เกินไป ก็จะ split item ออกมาเป็น item ย่อย ๆ

Split item แตกต่างกับการ break down task

การ split item ต้องได้ item ที่เล็กลง หลาย ๆ ใบ product backlog item สำหรับทีมที่มี Definition of Done กว้าง ๆ คือ business problem ซึ่งการแก้ปัญหาเหล่านั้นควรมี value จาก customers/users perspective

สรุปการ split item (แบ่งปัญหา) ควรได้ปัญหาย่อย ๆ ที่ทุกใบยังมี value อยู่ เช่น แบ่ง payment ออกเป็น payment ผ่าน credit card, payment ผ่าน QR code, payment ผ่านการโอน เป็นต้น

break down task เป็นการแตกงานออกมา ว่าการจะทำ item หนึ่ง ๆ ให้เสร็จนั้น ต้องทำ task อะไรบ้าง ที่ level task PO ไม่จำเป็นต้องอ่านออกแล้ว เป็นของที่คนในทีมอ่านกันเองเข้าใจก็พอ ซึ่ง task แต่ละใบไม่จำเป็นต้องมี value จาก user perspective เช่น การแตกงานของ payment ผ่าน credit card ออกมาเป็น

• การเพิ่มปุ่มรูปบัตรเครดิตไปบนหน้าจอ payment
• เขียน code frontend สำหรับ call API จ่ายเงินผ่านบัตรเครดิต
• เขียน unit test สำหรับ code frontend ที่เพิ่มขึ้นมา
• ใส่ feature toggle สำหรับ feature นี้
• ทำ API สำหรับจ่ายเงินผ่านบัตรเครดิต
• เขียน unit test สำหรับ API เส้นใหม่
• ทำ database migration script สำหรับ table ใหม่ใน database
• แก้ pipeline ให้ build image ส่วนของ micro service ที่เพิ่มขึ้นมาด้วย
• เขียน automate E2E สำหรับการจ่ายเงินผ่านบัตรเครดิต
• ….

เป็นต้น

ในบริบทของ PBL refinement ใน LeSS เค้าให้ทุกทีมมาทำร่วมกันในพื้นที่กว้าง ๆ เป็น workshop เพราะเวลาที่ item มีความสัมพันธ์กัน เราจะได้เดินไปคุยกับ ทีมที่เกี่ยวข้องได้เลย หรือบางครั้งเราอยากได้ technical information เพิ่มเติมจาก ทีมอื่น เราสามารถเดินไปถามเค้าได้ทันที ไม่ต้องรอไปถามเค้านอกรอบแล้วค่อยนัดประชุมสรุปกันใหม่ โดยที่เราไม่ต้องกังวลว่าจะไปขัดจังหวะเค้าที่ทำกำลัง focus กับงานใน sprint

นอกจากนี้ หน่วยงานอื่น ๆ ที่อาจจะอยากรู้ว่าพวกเราทำอะไรถึงไหนแล้ว ไม่ว่าจะเป็น marketing ที่ต้องเตรียมออกข่าวสำหรับสื่อสารกับลูกค้าว่าจะมี feature อะไรออกมา หรือ conpliance expert ที่อาจจะอยากเข้ามาแนะนำมุมมองเรื่องความเสี่ยงต่าง ๆ ที่ทีมอาจจะต้องตระหนักก่อนจะไปออกแบบระบบ

Sprint planning part 2 (Sp. planning 2)

ref: https://less.works

Sp. planning 2 เป็นจังหวะที่ทีมทำ detail design กันบน item ที่ทีมตั้งใจรับเข้ามาทำใน sprint นี้ ซึ่งถ้างานที่ทีมต่าง ๆ รับเข้ามามี technical dependencies ที่ต้องใช้ร่วมกัน เช่นอาจจะปรับแก้ API เส้นเดียวกัน แต่เพิ่มคนละ field เพื่อใช้ในงานของตัวเอง จะได้เดินไปจับกลุ่ม design ร่วมกันได้เลย ว่า API เส้นนี้ควรจะหน้าตาเป็นอย่างไรตอบจบ sprint นี้เพื่อให้รองรับความต้องการของทั้ง 2 ทีมพอทุกคนที่ต้องตัดสินใจร่วมกันอยู่กันครบ ก็จะได้ make decision ได้เลยโดยไม่ต้องไปนัดนอกรอบและเสี่ยงจะ interruprt ทีมอื่น ตอนที่เค้ากำลัง focus กับงานใน sprint

Sprint Review (Sp. review)

ref: https://less.works

แก่นของ Sp. review คือการให้ PO และทีมได้เรียนรู้เกี่ยวกับสถานะปัจจุบันของ product ของเรา เพราะแม้ทุก ๆ sprint เราจะทำ output ออกมา สิ่งที่ business อยากได้คือ outcome เสมอ Sp. review เป็นการวัดผลว่า output ที่ทำออกมามันเข้าใกล้เป้าหมายมากแค่ไหนแล้ว? และถ้ายังไม่ถึงเป้าหมายที่เราต้องการ เราควรได้เรียนรู้ว่าต้องเติมอะไรลงไปใน product อีกเพื่อให้มันเข้าใกล้เป้าหมายมากขึ้น

practice ที่ได้รับการใช้บ่อย ๆ ใน Sp. review สำหรับการพัฒนา product ในกลุ่มคนเยอะ ๆ คือการทำ review แบบ Bazaar (ตลาดนัด) นั่นคือ แต่ละทีมจะแบ่งคนไว้ 1–2 คนเพื่อเตรียม review และจด feedback ที่ได้จาก review นั้น ๆ (เหมือนคนเฝ้าร้านตัวเอง) ส่วนคนที่เหลือจะกระจายกันไปเยี่ยมชมร้านต่าง ๆ ที่เราสนใจ (เพราะอาจจะเกี่ยวพันกับงานเรา)

การทำแบบนี้จะทำให้หน่วยงานอื่น ๆ ที่อยากรู้ว่า state ปัจจุบันของ product ถึงไหนแล้ว ไม่ว่าจะเป็นผู้บริหารต่าง ๆ หรือ marketing ที่อยากทราบว่า progress ของทีมพัฒนาตรงตามแผนแค่ไหน หรือ feature อะไรบ้างที่พร้อมแล้วสำหรับ release แล้ว จะได้ไปเตรียมทำข่าวต่อไปก็จะเข้ามาเดินดูส่วนงานที่สนใจรวมถึงให้ feedback เพื่อให้ทีมพัฒนาจดเก็บไว้ได้

ช่วยท้ายของ Sp. review (เช่น 30 นาทีสุดท้าย) ร้านรวงต่าง ๆ จะปิด เลิกรับ feedback และเป็นเวลาที่ทุกทีมรวมถึง PO จะกลับมารวมตัวกันเพื่อฟัง feedback ที่คนเฝ้าร้านสะสมได้ พร้อมทั้งให้ PO ตัดสินใจว่า feedback ไหนที่คุ้มค่าจะไปสร้าง item ไว้ใน product backlog บ้าง และ item ไหนที่จะทิ้งไปเพราะยังไม่สำคัญ ณ วินาทีนี้ รอให้ feedback นี้กลับมาบ่อย ๆ ค่อยตัดสินใจอีกที

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

แล้วทุกวันนี้ที่เรา Online กันจะทำยังไง?

ผมทราบดีว่าตอนนี้หลาย ๆ ทีมอาจจะทำงาน online กัน ซึ่งการจะเดินไปมุงตามสไตล์ workshop นั้นเกิดขึ้นได้ยากใน online setup

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

สรุปแล้วผมอยากชวนให้ทุก ทีมกระโจนไปถามคำถามกันเลยทันที อย่ารอไปถามนอกรอบ เพราะนอกจังหวะกิจกรรมนี้ แต่ละทีมอาจจะมี calendar ที่แตกต่างกัน ถ้าปรากฏว่า conversation ที่เรากระโจนไปมันไม่ใช่สิ่งที่ทั้งทีมอยากจะ focus ก็อยากชวนให้ใช้ break out room ใน online meeting แยกวงคุย พอได้คำตอบเสร็จก็แยกย้ายกลับไปเข้ากิจกรรมเดิมของทีมตัวเอง

ภาพในฝันคือ นอกจากช่วงเวลาของกิจกรรม 3 กิจกรรมนี้แล้ว ไม่ควรมีการนัดประชุมนอกรอบอีก เวลาที่เหลือควรเป็นเวลาที่ทีมจะได้ focus กับงานใน sprint ล้วน ๆ

credits

เจน co-author ที่ช่วยทำให้บทความนี้สมบูรณ์ขึ้น :)

อ้างอิง

สำหรับคนที่อยากศึกษาเพิ่มเติม สามารถอ่านจากข้อมูลด้านล่างได้นะครับ

Overview

อย่าทำ Sprint review ถ้า…