Product Backlog ตามตำรา

Get Rid of Big Requirement Upfront with Product Backlog

Product Backlog คือ?

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

อีกมุมมองหนึ่ง Product Backlog จะอายุยืนกว่า Requirement Specification มาก (อย่างที่รู้กันว่าไม่ค่อยมีใครอ่านเอกสารหนาเตอะแบบนี้หรอก) เพราะ Scrum Team จะทำงานโดยอ้างอิงกับ Product Backlog โดยตลอดในแทบทุกกิจกรรม เช่น Spring Planning, และ Product Backlog Refinement (Grooming) ทำให้การปรับปรุง เปลี่ยนแปลง และแก้ไข Product Backlog เป็นเรื่องปกติที่จำเป็นต้องทำนั่นเอง

Product Backlog Item

เราต้องทำความเข้าใจเพิ่มเติมอีกนิดว่า Product Backlog เป็นแค่แฟ้มโดยของที่อยู่ในแฟ้มนั้นเราเรียกว่า Product Backlog Item ซึ่งมีอยู่หลากหลายรูปแบบ ดังนี้

1. Features — โดยทั่วไป Features ที่อยู่ใน Product Backlog จะเขียนอยู่ในรูปแบบของ User Story
2. Bugs — ก็ไม่ต่างกับ Features ครับ Bugs เป็นสิ่งที่เกี่ยวข้องโดยตรงกับ Product ในแง่ของคุณภาพ มันเป็นงานที่ทีมต้องทำ ดังนั้นมันจึงอยู่ใน Product Backlog ได้เช่นกัน
3. Technical work — เป็นงานด้านเทคนิคที่จำเป็นต้องทำแต่ไม่เกี่ยวของโดยตรงกับความต้องการของผู้ใช้ เช่น Install VM, Update patch, Create build script และอื่นๆ
4. Research / Knowledge acquisition — เมื่อ Scrum Team อยู่ในสถานการณ์ที่ต้องการความรู้หรือข้อมูลเพิ่มเติมเพื่อตัดสินใจในด้านเทคนิค เราจะเขียนงานประเภทนี้ไว้ใน Product Backlog ในรูปแบบของ Spike ด้วย เช่น Research on AngularJS and jQuery เป็นต้น

Healthy Product Backlog

Product Owner และ Scrum Team ทุกคนมีส่วนรับผิดชอบในการสร้างและดูแล Product Backlog ให้อยู่ในสภาพที่พร้อมใช้งานอยู่เสมอ … คำว่าพร้อมใช้งานคือ

1. Product Backlog Item ได้รับการจัดเรียงลำดับความสำคัญจากมากสุด (บนสุด) ไปน้อย(ล่าง) … ไม่จำเป็นว่า User Story ต้องอยู่บนสุดเสมอไป มันอาจจะเป็น Bugs, หรือ Technical work ก็ได้ เราไม่จำเป็นต้องเรียงลำดับความสำคัญของงานให้ครบทุกชิ้นสิ่งสำคัญคือเราต้องเรียงลำดับงานให้ชัดเจนเผื่อไว้ซัก 1–2 Sprint ส่วนที่เหลือกองๆไว้ก็ได้ … Priority มันเปลี่ยนได้ตลอดเวลา
2. Product Backlog Item ที่อยู่ส่วนบนๆต้องมีข้อมูลเรื่องความหมายและผลลัพธ์ที่ต้องการระบุไว้อย่างชัดเจนในระดับที่ Scrum Team มีความมั่นใจในการทำงานเหล่านั้น ถ้าเป็น User Story ก็ควรต้องได้ตามกฎ INVEST … เวทีที่ Scrum Team ใช้ในการพูดคุยในรายละเอียดของ Product Backlog Item นี้เรียกว่า Product Backlog Refinement (Grooming)
3. Product Backlog Item ที่อยู่ส่วนบนๆควรต้องได้รับการประเมินขนาด (Estimate) โดย Scrum Team แล้ว จะด้วยหลักการ Story Point หรืออะไรก็ตามแต่ สิ่งนี้จะถูกใช้เปรียบเทียบกับ Average Velocity ระหว่างการทำ Sprint Planning

“XXX” Backlog

ถ้าการจัดงานทั้งหมดมารวมกันที่ Product Backlog ที่เดียวมันวุ่นวายและปนเปกันมากเกินไป เรามีทางออก … เพราะคำว่า “Backlog” แปลว่า “งานที่ยังไม่ได้ทำ” ทำให้หลายๆครั้งเราสามารถเลือกใช้คำว่า Backlog กับสิ่งอื่นๆได้เช่นกัน ที่นิยมกันมาก เช่น Bug Backlog, Technical Backlog และ Happiness Backlog (อันนี้ผมคิดเอง ฮ่าๆ)

ในระหว่างการทำ Sprint Planning เราสามารถกำหนดสัดส่วนการทำงานให้เหมาะสมกับทุกๆ Backlog ได้ ประมาณนี้

• Product Backlog = 50%
• Bug Backlog = 20%
• Technical Backlog = 20%
• ว่างๆไว้ = 10% ☺

ป.ล. ที่ผมเขียนมานั้นเป็นไปตามตำราบวกกับความรู้ส่วนตัวที่มี … แต่ … หลังๆมานี้ผมเบื่อคำว่า Product Backlog ตามตำรามากเลย เพราะอะไรไว้เล่าให้ฟังครับ

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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ