Product backlog ต่างกับ Sprint backlog อย่างไร
บ่อยครั้งผมเจอทีมที่ทำสกรัมแต่แยกไม่ออกว่า product backlog (PBL) ต่างกับ sprint backlog (SBL) อย่างไร บางครั้งเรียกของ 2 สิ่งนี้รวม ๆ ว่า backlog เฉย ๆ ด้วย พอผมถามว่ากำลังพูดถึง PBL หรือ SBL? ก็มักจะได้ยินคำถามกลับมาว่ามันต่างกันด้วยเหรอ แล้วผมก็ค่อยอธิบายให้ฟัง ส่วนใหญ่ทีมที่มีปัญหานี้มักจะเป็นทีมที่ใช้ electronic tool ตัวหนึ่งที่เดิมเคยเป็น bug tracking tool แต่เดี๋ยวนี้พยายามปลอมตัวเป็นอไจล์ tool ถ้าเป็นคนในวงการน่าจะทายถูกว่าผมหมายถึง tool ตัวไหน
Product backlog
คือที่ ๆ เก็บไอเดียของสิ่งที่อาจจะเกิดขึ้นกับ product ในอนาคต สำหรับทีมที่มีความคล่องตัวต่ำ ๆ PBL จะเก็บ list ของ features ที่กำลังจะเพิ่มใน product สำหรับทีมที่คล่องตัวสูง ๆ จะเก็บ list ของปัญหาที่คุ้มจะให้ทีมแก้
list นี้ควรถูกเรียงตามลำดับความสำคัญในมุมมองของ product owner (PO) อยู่เสมอ และควรถูกวางไว้ในที่ ๆ ทุกคนในองค์กรสามารถมองเห็นได้ เรียกว่าใครอยากรู้สถานการณ์ที่จะเกิดขึ้นกับ product นี้ ก็เดินมาดูได้เลย ทุกคนจะรู้ว่า ของที่อยู่บน ๆ คือไอเดียที่ทีมกำลังจะทำในเร็ว ๆ นี้ และของล่าง ๆ คือของที่ยังไม่สำคัญในขณะนี้ในสายตา PO
เนื่องจาก list นี้เป็นของที่จะทำแต่ยังไม่ได้เริ่มทำ ฉะนั้น list นี้ควรรองรับความเปลี่ยนแปลงทุกวินาที ใครมีไอเดียดี ๆ ก็ไปเสนอกับ PO ได้ หรือถ้าสถานการณ์ทางธุรกิจเปลี่ยนแปลง PO ก็ปรับกลยุทธ์บน list นี้ได้ทันที สกรัมรองรับความเปลี่ยนแปลงบน PBL นี่แหละ
สรุปแล้ว แก่นของ product backlog คือช่วยให้ทุกคนเห็นอนาคตที่เป็นไปได้สำหรับ product นี้
Sprint backlog
คือ item ที่ทีมเลือกจากบนสุดของ PBL เข้ามาโฟกัสในกรอบเวลาของสปรินท์นี้ หลังจากจบ Sprint Planning part 2 (อ้างอิงจาก Scrum guide v. 2017) แม้ตำราจะบอกไว้ว่าทีม commite item เข้ามาหลัง part 2 แต่จากประสบการณ์ของผม ทีมที่มีประสบการณ์สัก 2–3 เดือนขึ้นไปมักจะ คาดการณ์ได้แม่นมาก ๆ ตั้งแต่จบ part 1 แล้วแหละว่าสปรินท์นี้จะไหวแค่ไหน ไม่ต้องรอทำ detailed design ใน part 2 เสร็จถึงจะตอบได้
เมื่อทีมรับ items เหล่านั้นเข้ามาในสปรินท์แล้ว items เหล่านั้นก็จะย้ายจากส่วนบนสุดของ PBL มาอยู่ใน SBL ซึ่งส่วนใหญ่จะอยู่ในรูปคอลัมน์ TODO บน task board ของทีม
หลังจากจบ part 2 ทีมก็จะเริ่มโฟกัสบนงานใน SBL ซึ่งงานที่อยู่บนนี้เป็นสัญญาร่วมกันระหว่าง PO กับทีมโดย
- PO สัญญาว่าจะไม่เปลี่ยนแปลงรายละเอียดของปัญหาบน SBL และไม่ interrupt ทีมเพื่อให้เค้ามีโฟกัสที่เค้าคู่ควร
- ทีมสัญญาว่าจะทำทุกวิถีทางเพื่อแก้ปัญหาที่รับมาใน items เหล่านั้นให้สำเร็จ
สรุปแล้ว แก่นของ sprint backlog คือช่วยให้ทุกคนเห็นสถานะปัจจุบันของสิ่งที่ทีมกำลังโฟกัสอยู่ในสปรินท์นี้
ความแตกต่างนี้สำคัญอย่างไร
สิ่งแรกที่สำคัญคือสกรัมรองรับความเปลี่ยนแปลงบน PBL แต่ไม่รองรับความเปลี่ยนแปลงบน SBL
PBL เป็นของ PO ถึงใครจะเขียนไอเท็มไปเสนอ PO ก็ได้ หรือจะช่วยเติมรายละเอียด, แก้คำผิด, เติมเอกสารอ้างอิง แต่สิทธิ์ในการตัดสินใจเรียงลำดับความสำคัญนั้น PO ถือว่ามีสิทธิ์ขาด เพราะถ้าเราริดรอนอำนาจนี้ไปจาก PO มันก็ไม่ยุติธรรมที่จะให้เค้ารับผิดชอบความคุ้มค่าจากการลงทุน หรือ Return Of Investment (ROI)
แก่นของสกรัมคือการที่มีคนหนึ่งคน (PO) ตัดสินใจเลือกปัญหาที่คุ้มที่สุดมาให้ทีมแก้และรับผิดชอบกับการตัดสินใจของตน (ROI) และมีคนอีกกลุ่ม (ทีม) ตัดสินใจเลือกวิธีการแก้ปัญหาและรับผิดชอบกับการตัดสินใจนั้น ถ้าเราทำให้แก่นนี้มันเสียไป เราก็จะรักษาได้แค่ท่วงท่าของสกรัม แต่ไม่สามารถถนอมประโยชน์ของสกรัมไว้ได้
กลับมาทบกวนกับว่าเรื่องนี้เกี่ยวกับสกรัม values 5 ข้ออย่างไร
Focus — PO โฟกัสบน PBL, ทีมโฟกัสบน SBL (ยกเว้นตอน PBL refinement)
Commitment — PO ตั้งมั่นที่จะเรียง PBL ให้ทีมได้แก้ปัญหาที่คุ้มค่าที่สุด, ทีมตั้งมั่นที่จะแก้ปัญหาที่อยู่บน SBL ให้สำเร็จ
Openness — ทั้ง PBL และ SBL ควรโปร่งใสสำหรับทุกคนในองค์กร เพื่อให้ PO และทีมไม่หลุดโฟกัสจากการคอยตอบผู้คนว่าสถานะปัจจุบันถึงไหนแล้ว
Respect — PO และทีมควรรับฟังความคิดเห็นของทุกคน และทุกคนควรเคารพการตัดสินใจของ PO บนปัญหาบน PBL และเคารพการตัดสินใจของทีมบนวิธีแก้ปัญหาของทีมบน SBL
Courage — ไม่รู้เกี่ยวยังไง คิดไม่ออก
