แปลเนื้อหามาจาก scrumprimer.org เพื่อให้คนไทยอ่านทำความเข้าใจเรื่อง scrum ที่เป็น framework หนึ่งของ agile ได้ง่าย และเร็วขึ้น

Product Backlog

เมื่อทีมงานจะเริ่มวางแผนที่จะเปลี่ยนเป็น scrum แล้ว ก่อนจะเริ่ม sprint แรกก็จะต้องมี Product Backlog ซะก่อน ซึ่งมันคือ การจัดลำดับความสำคัญ 1, 2, 3 จาก list ความต้องการของลูกค้าเป็นหลัก

Product backlog จะเป็นสิ่งที่มีไปตลอดอายุของ Product ก็ถือได้ว่าเป็น product roadmap นั่นเอง โดย Product Backlog จะเป็นสิ่งที่สามารถอธิบาย อะไรก็ตามที่จะต้องทำให้เสร็จโดยทีมที่เรียงตามความสำคัญมาแล้ว โดยจะมี Product Backlog ได้เพียงชุดเดียวในแต่ละ product เท่านั้น โดย PO จะต้องทำหน้าที่ เรียง priority ทุกอย่างที่เข้ามาทั้งหมด รวมทั้งต้องนำเสนอต่อ stake holder รวมถึง Team ด้วยเช่นกัน

Product backlog นี้จะรวมหลายอย่าง แต่หลักๆจะเป็น feature ใหม่ๆ ที่ลูกค้าต้องการ เช่น ต้องการให้ลูกค้าสามารถหยิบหนังสือใส่ cart ได้ หรืออาจจะเป็น การปรับเปลี่ยนเชิง technical เช่น เปลี่ยนภาษาที่ใช้เขียนจาก C++ เป็น Java หรือ การพัฒนา เช่น เพิ่มความเร็วการ test หรือ การ research เช่น หาแนวทาง เพื่อทำให้ validate credit card ได้เร็วขึ้น หรือ แม้กระทั่ง bug , defect เช่น ค้นหาว่าเพราะอะไรที่ทำให้ script หน้า checkout error รวมถึง หลายๆปัญหาในเรื่องเดียวกัน เช่น “เนื่องจากปัญหาที่เกิดขึ้นมาจากหลายระบบ จึงควรมีระบบ log เพื่อตรวจสอบปัญหาแต่ละเรื่องแยกรายระบบ” เป็นต้น

Product backlog item จะเป็นสิ่งที่อธิบายชัดเจนในตัวมันเอง เพื่อป้องกันการเข้าใจผิด โดย Product backlog จะไม่มี “user stories” ในนั้น แต่จะมีแค่ item เท่านั้น ซึ่ง item เหล่านั้น ก็ค่อยเอามาแตกย่อยเป็น user stories, use cases หรือ requirement อื่นๆ ที่ทำให้ทีมงานเข้าใจได้ แต่อย่างไรก็ดีแนะนำว่า item เหล่านั้น ควรเป็นสิ่งที่มุ่งเน้นที่การสร้าง value ให้กับลูกค้า

องค์ประกอบของ Product backlog ที่ดี

Detail appropriately – อธิบายได้อย่างเหมาะสม
Item ที่มีความสำคัญมากๆ จะต้องมีการใส่รายละเอียดให้มากกว่า item ที่มีความสำคัญน้อยๆ และมักจะเป็นงานที่จะได้ทำในเร็วๆนี้ มากกว่างานที่รอไปทำทีหลังได้ ตัวอย่าง item 10% ที่มีความสำคัญสูงสุด อาจจะแตกมาโดยละเอียดมากแล้ว และผ่านการวิเคราะห์มาอย่างดี มากกว่าอีก 90% ที่เหลือ

Estimated – การประเมิน
Item ที่เรากำลังจะหยิบเอาไปทำนั้น ต้องผ่านการ estimate มาก่อน นอกจากนี้ ควรจะมีการพิจารณาซ้ำอีกครั้ง เมื่อผ่านแต่ละ sprint เพราะว่ามักจะมีข้อมูลใหม่ หรือเรื่องใหม่เข้ามากระทบอยู่เสมอๆ The Team จะต้องมีความสามารถในการประเมิน resource ที่ต้องใช้สำหรับแต่ละ item ของ product backlog ได้ และหมายรวมถึง technical risk ที่อาจจะเกิดขึ้นด้วย ส่วน Product Owner และ stakeholder จะต้องอธิบาย value ของสิ่งที่ต้องการได้ ไม่ว่าจะเป็น การเพิ่มยอดขาย, ลดต้นทุน, ความเสี่ยงทางธุรกิจ, ความสำคัญต่อ stakeholder และอื่นๆ

Emergent – ความเร่งด่วน
เพื่อให้ตอบสนองได้ต่อความต้องการ ที่เปลี่ยนไปในแต่ละช่วงเวลา Product Backlog จะต้องมีการตรวจสอบอยู่เสมอๆ ในแต่ละ sprint เพื่อ เพิ่ม ลด แก้ไข ตัดแบ่ง หรือเปลี่ยน priority โดยปกติ Product backlog จะต้องถูกปรับปรุงอย่างต่อเนื่องโดย Product Owner เพื่อให้ตอบสนองต่อความต้องการในการเปลี่ยนไปเปลี่ยนมาของ customer , idea ใหม่ หรือ ข้อมูลใหม่, ปรับให้ทันกับคู่แข่ง, การปรับในเชิง technical และอื่นๆ

Prioritized – ความสำคัญ
Item ที่อยู่ด้านบนสุดของ Product backlog จะถูกเรียงตามลำดับ และ เรียงคิวเอาไว้ โดยปกติแล้ว ความสำคัญที่สูงที่สุด ควรจะเป็น สิ่งที่ได้ประโยชน์มากที่สุดโดยออกแรงน้อยที่สุด (bang for your buck) หรือแนวคิดอื่นๆ ก็อาจจะเป็น เข้าชนกับความเสี่ยงก่อน ก่อนที่ความเสี่ยงจะเข้ามาชนคุณ

Traditional development ไม่ได้เน้นที่การทำเสนอสิ่งที่ให้ประโยชน์สูงสุด โดยใช้แรงน้อยที่สุดเหมือนอย่างที่ scum ทำ ซึ่งนี่แหล่ะเป็นแนวคิดของ scrum เลย ดังนั้น Product Owner จำเป็นที่จะต้องเรียนรู้วิธีการตรวจเช็ค “business value” ให้ได้ Scrummaster ก็จะมีหน้าที่ช่วยเหลือ Product Owner ในการเรียนรู้ด้วย

Business value มันคืออะไร? บางคน อาจจะสร้างตัวเลขขึ้นมา เพื่อใช้ประเมิน Product backlog แต่ละ item โดยสร้างขึ้นมาจาก “guesstimate” ก็คือ ประเมินจากส่วนผสมของการคำนวนและการเดา โดยประกอบมาจาก เพิ่มยอดขาย, ลด cost, สิ่งที่ stakeholder อยากได้, ความแตกต่างในตลาด, และอื่นๆ บางครั้ง อาจจะกำหนดโดยราคาที่ลูกค้าจ่ายเพื่อจ้างทำ item นั้นๆ ดังนั้น ค่าจ้างก็คือ สิ่งที่เป็นตัวบอกว่า value มากหรือน้อย หรืออาจใช้การดูสิ่งที่จะตอบโจทย์ทาง business เป็นหลัก เช่น เพิ่มยอด subscription อีก 10% ในเดือน กรกฏาคม แบบนี้การจะทำให้ได้ value ก็จะต้องประกอบมาจาก item หลายๆอันมารวมกัน เพื่อทำให้ได้ตามเป้าหมายที่ตั้งเอาไว้ ในกรณีนี้ Product Owner จำเป็นที่จะต้องกำหนด Minimum Viable Product สำหรับการก้าว step ต่อไปให้ได้

การประเมินแรงงานที่ต้องใช้

สำหรับการประเมินแรงงานที่ต้องใช้ โดยเทคนิคพื้นฐานจะใช้การประเมินจากหลายอย่างที่เกี่ยวข้อง ก็คือ แรงที่ต้องใช้,ความยุ่งยาก,ความไม่แน่นอน โดยใช้หน่วยเป็น “story point” หรือเรียกว่า “point” หรือ แต้ม

เรื่องหนึ่งที่ต้องรู้ก็คือ scrum ไม่ได้กำหนดเทคนิคการแสดงผลหรือ การวิธีการให้ความสำคัญ item ใน product backlog และไม่กำหนดวิธีการประเมิน หรือ หน่วยที่ใช้อีกด้วย

เทคนิคที่ใช้โดยทั่วไปของ scrum ก็คือการติดตามวัดผลว่า สามารถทำงานได้มากน้อยแค่ไหนในแต่ละ sprint เช่น หลาย sprint ที่ผ่านไป ทำงานได้ประมาณ 26 แต้มโดยเฉลี่ย ด้วยข้อมูลนี้ เราก็สามารถใช้ในการประเมิน เวลาที่จะ release product เราได้ในทุกๆ feature เลย หรือกลับกันคือ ในช่วงเวลาที่เรามีจำกัดนี้เราจะสามารถทำ feature ได้มากน้อยเพียงใด (ถ้าค่าเฉลี่ยนั้นคงตัวและไม่เปลี่ยนไปมา) โดยค่าเฉลี่ยนี้ เราจะเรียกว่า “velocity” โดย Velocity จะใช้หน่วย ที่เหมือนกับเราใช้ประเมิน product backlog item นั่นเอง

Item ใน Product backlog จะมีขนาด และ แรงที่ต้องใช้ได้หลากหลายมาก โดย Item ที่มีขนาดใหญ่มาก จะถูกแตกออกมาเป็นขนาดเล็กๆ ระหว่างการทำ Product Backlog Refinement workshop หรือ Sprint Planning Meeting และเช่นกัน สิ่งที่เล็กๆมากๆ ก็จะถูกรวมกันเข้ามาด้วยเหมือนกัน

Product Backlog Item ที่เตรียมเอาไว้สำหรับ sprint ที่กำลังจะมาถึงนั้น ควรมีขนาดเล็ก และผ่านการปรับจูนให้มากพอ เพื่อให้ The Team เข้าใจได้และพร้อมสำหรับการ forecast ที่ทำร่วมกันใน Sprint Planning meeting โดยจะเรียกว่า “actionable” size

การปรับอะไรบางอย่างในเชิง Technical ที่เข้ามาอยู่ใน product backlog มักจะใช้เงิน และ เวลาค่อนข้างมาก บางครั้งก็อาจจะต้องมีการลงทุนเพิ่มด้วย นี่จะทำให้ Product Owner ลำบากใจ แต่ว่าอย่างหนึ่งก็คือ scrum นั้นยอมให้ The Team มีอำนาจในการตัดสินใจในส่วนของการปรับปรุงเชิง Technical เข้ามาทำใน sprint โดยมีอิสระในการเลือกการปรับปรุงที่ไม่ใหญ่มาก ไม่ใช้เงินเยอะกว่าปกติ และ ต้องเป็นสิ่งที่ปรับปรุงเพื่อให้การทำงานของ developer เป็นไปอย่างถูกต้อง แต่อย่างไรก็คือ เวลาที่ต้องใช้หลักๆของ The Team ก็คือ ทำงานตามเป้าหมายของ Product Owner ไม่ใช่ทำเพื่อ engineer เอง

แนวคิดหนึ่งของ Scrum คือการป้องกันคุณออกจากการเขียน detail specification แต่ว่าในชีวิตจริง ก็ขึ้นอยู่กับตัว product owner และ The Team ว่าต้องการรายละเอียดมากน้อยแค่ไหน และนี่ก็จะแตกต่างกันไปในแต่ละ item ของ backlog ด้วย โดยขึ้นอยู่กับความสามารถของ Team และปัจจัยอื่นๆที่จะเป็นตัวบอกว่าต้องเขียนมากหรือน้อย และอะไรที่เป็นเนื้อหาที่สำคัญ หรืออีกนัยหนึ่งคือ อย่าเขียนอธิบายทุกรายละเอียของ item เขียนแค่ให้เพียงพอและเข้าใจได้ว่า ต้องการอะไร รวมทั้งต้องทำให้ Team , Product Owner , Stakeholder เข้าใจได้ product backlog ที่ไม่ค่อยสำคัญ เราก็ใส่รายละเอียดเอาไว้หยาบๆก็พอ (คลุมเครือ มี detail น้อย) แต่ว่า item ที่มีความสำคัญ จำต้องพิจารณาโดยและมีเนื้อหาที่สำคัญครบถ้วนเพราะว่าจะถูกนำไป implement แล้ว

Definition of Done

สิ่งที่เราจะได้ออกมาจากทุกๆ sprint นั่นคือ Potentially Shippable Product increment ก่อนที่เราจะเริ่ม sprint แรก Product Owner, Team, ScrumMaster จะต้องทำการ review ว่าต้องการอะไรจาก product Backlog item เพื่อให้คาดคะเนได้ถึง protentially shippable กิจกรรมที่ต้องทำในการจัดเรียง ก็คือการกำหนด Potentially Shippable และสิ่งที่ควรทำเสร็จ ในระหว่าง sprint

แต่น่าเสียดาย เมื่อ Team เริ่มใช้งาน scrum แล้ว มักจะพบว่าไม่สามารถไปถึงเป้าหมายของ Potentially Shippable Increment ได้ในทุกๆ Sprint นี่มักจะเกิดขึ้นได้บ่อยเนื่องจาก Team ขาดพวก Automate หรือว่า cross function กันยังไม่มากพอ เช่น ไม่มี technical writer ใน cross function ทีม แต่เมื่อเวลาผ่านไป The Team ก็จะเริ่มเรียนรู้และปรับปรุงตัว จากนั้นก็จะสามารถ deliver Potentially Shippable Product Increment ได้ในทุก sprint แต่ว่า จังหวะที่เริ่ม จำเป็นต้องกำหนด ผลงานที่น้อยที่สุดที่รับได้ของทีมขึ้นมาก่อน นี่เรียกว่า Definition of Done

ก่อนเริ่ม sprint แรก Product Owner และ Team จะต้องตกลงร่วมกันถึง Definition of Done ว่าจะประกอบด้วย กิจกรรมที่จำเป็น ที่ทำให้เกิด Potentially Shippable Product Increment ได้ (ถ้าทีมที่เจ๋งๆ มันจะเหมือนๆกัน) The Team จะทำการ plan งานที่ทำใน Sprint เพื่อให้ตอบโจทย์ของ Definition of Done

Product Owner ที่ดีมักจะต้องการ Definition of Done เพื่อให้เข้าใกล้ Potentially Shipppable ซึ่งนั่นก็คือ การเพิ่ม transparency ในการพัฒนา และ ลดการ delay รวมถึงความเสี่ยง ถ้า Definition of Done ไม่เท่ากับ Potentially Shippable นั่นคืองานก็ delay แล้ว ส่วนที่ delay นี้เราเรียกว่า undone work

Scrum Team ควรจะต้องพัฒนาอย่างต่อเนื่อง เพื่อตอบสนองต่อ Definition of Done เหล่านั้น

เรื่องของ product backlog ก็จะถือได้ว่าเป็นจุดศูนย์กลางที่เป็นจุดร่วมกันระหว่าง PO กับคนทำงานเลย ดังนั้นทุกคนก็ควรใส่ใจให้มาก พรุ่งนี้จะเล่าเรื่องของ กิจกรรมสองอย่างใน scrum คือ sprint planning และ daily scrum สำหรับใครที่ต้องการอ่านเรื่องอื่นๆของ scrum ที่แปลมาจาก scrumprimer ก็กดที่ tag ‘scrumprimer’ ด้านล่างได้เลยครับ