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

sprint planning

คืออะไร : เป็น meeting เพื่อเตรียม sprint โดยทั่วไป จะแบ่งเป็น 2 part คือ Part one ที่บอกว่า “อะไร” และ Part two ที่บอกว่า “ยังไง”
ผู้ที่เข้าร่วม : Part One Product Owner, Team, ScrumMaster และ Part two : Team, ScrumMaster,Product Owner (เข้าหรือไม่ก็ได้ แต่ว่าต้องสามารถช่วยตอบคำถามได้ในกรณีที่ต้องการ)
เวลาที่ใช้ : แต่ละ part จะใช้ 1 ชั่วโมง ต่ออาทิตย์ของ sprint

ช่วงเริ่มต้น Sprint นั้น Sprint Planning Meeting จะแบ่งเป็นสองกิจกรรมย่อย ก็คือ

Sprint Planning Part One
ใน Sprint Planning Part One ทาง Product Owner และ The Team จะรีวิว High Priority item ที่อยู่ใน Product Backlog ที่ทาง Product Owner เตรียมเอาเข้า Sprint โดยปกติ item เหล่านี้ จะถูก analyzed มาอย่างดีจาก sprint ก่อนหน้าแล้ว (ในกระบวนการทำ Product Backlog Refinement) ดังนั้น ใน meeting นี้ก็เป็นเหมือนการ remind สิ่งที่อาจจะลืมไป หรือ ตอบคำถามข้อสงสัยอะไรที่ไม่หนักหนาสาหัสมากเท่านั้น โดย Product Owner และ Team จะต้องคุยให้เข้าใจตรงกันถึงเป้าหมายของ คำนิยาม item ที่มีความสำคัญสูงๆใน Product Backlog เพื่อให้ Team ได้มองเห็นภาพได้ว่า Product Owner กำลังคิด และต้องการอะไร
Part One นี้เราจะเข้าใจว่า อะไรคือสิ่งที่ Product Owner ต้องการ และ ทำไมถึงต้องการ เมื่อจบ Part One แล้ว Product Owner ก็สามารถแยกตัวออกมาได้เลย ถ้าไม่ว่าง แต่อย่างไรก็จำเป็นต้องสามารถติดต่อได้ ไม่ว่าช่องทางใดช่องทางหนึ่งระหว่างการทำ Part Two meeting
ใน Part One Team และ Product Owner จะต้องสร้าง Sprint Goal ขึ้นมา นี่จะเป็นสิ่งที่บอกความต้องการหลักของ Sprint เลย เพื่อให้ทุกคนสามารถยึดติดอยู่กับ theme หลักของ sprint ได้ โดย Sprint Goal จะบอกถึง Team Scope ที่ยืดหยุ่นในการทำงานมากพอที่จะยังสามารถ deliver งานได้จริงเพราะว่ามันอาจจะเกิดการเอา item ออกกลาง sprint และ team ก็ควรจะ commit ที่จะ deliver งานที่ “done” เพื่อให้ตอบโจทย์ต่อ sprint goal ได้ด้วย

Item ใหญ่ขนาดไหนที่จะเหมาะเอาเข้า sprint ล่ะ? แต่ละ item ควรแตกออกมาให้เล็กพอที่จะ estimate ได้ใหญ่ที่สุดไม่ควรเกิน 1 sprint โดยปกติที่แนะนำก็คือ Item ที่มีขนาดเล็ก ที่จะทำได้เสร็จใน 1 Sprint หรือ เร็วกว่านั้น จากการทำงานของทั้ง Team

Sprint Planning Part Two
มุ่งเป้าที่จะ implement ขึ้นมาได้อย่างไร โดย Team จะเป็นคนตัดสินใจกันเอง The Team ต้องประเมินปริมาณ item ที่สามารถทำสำเร็จได้เมื่อจบ sprint เริ่มต้นจาก Priority ที่สูงที่สุด ของ Product Backlog ก่อน หรืออีกนัยหนึ่งก็คือ เริ่มต้นที่ item ที่มี Priority สูงสุดสำหรับ Product Owner ก่อน และ ค่อยๆทำไล่ลงไปเรื่อยๆ นี่เป็นสิ่งที่ควรปฏิบัติตามใน Scrum เลยก็คือ The Team จะต้องตัดสินใจว่าสามารถทำงานได้เสร็จมากน้อยแค่ไหน มากกว่า ที่ Product Owner จะเป็นคนยัดให้ นี่จะทำให้สามารถประมาณการณ์ได้ดีกว่า เพราะว่าประเมินมาจากสิ่งที่ทีมได้วิเคราะห์ และวางแผนกันมาเอง ในขณะเดียวกัน Product Owner ก็ไม่ควรเข้าไปกำกับว่าต้องทำอะไรได้มากน้อยแค่ไหน เพราะว่ามีหน้าที่แค่เรียงความสำคัญให้ทีมจากบนลงล่างใน Product Backlog เท่านั้น หรือ อีกนัยหนึ่ง ก็คือ item ที่ Product Owner ได้ให้ความสำคัญมาเป็นที่เรียบร้อยแล้ว แต่ The Team ก็สามารถปรับลดความสำคัญลงได้ ในกรณีที่ได้คุยกันแล้ว ระหว่าง The Team กับ Product Owner และตกลงกันได้ว่า นี้เป็นสิ่งที่ไม่มีความสำคัญเมื่อเทียบกับงานอื่น รวมทั้งเลือกงานที่มีความสำคัญอย่างเหมาะสมได้อีกครั้ง

Sprint Planning Meeting อาจจะใช้เวลาหลายชั่วโมง แต่ไม่ควรมากเกิน 4 ชั่วโมง ต่อ 2 สัปดาห์ ของ sprint
Team จะต้องจริงจังกับการประมาณการณ์งานที่จะต้องทำให้เสร็จ นี่เป็นสิ่งสำคัญที่ต้องทำเพื่อจะให้เกิดความสำเร็จ โดย Part One และ Part Two จะใช้เวลาเท่าๆกัน สำหรับ 2 สัปดาห์ของ sprint ควรใช้ไม่เกิน 2 ชั่วโมงในแต่ละ Part

Scrum ไม่ได้กำหนดไว้ว่าจะต้องมี Sprint Planning Part Two มากน้อยแค่ไหน บาง Team อาจจะใช้ velocity จาก sprint ก่อนหน้ามาตั้งต้นก็ได้ บ้าง Team อาจจะใช้การลงรายละเอียด จากการคำนวนค่าต่างๆเพื่อให้บอกได้ถึง capacity ที่มีอยู่

ถ้าใช้การบอกถึง Capacity ที่มีอยู่ ในการทำ Sprint Planning Part Two นั้น The Team จะต้องคำนวนว่าเวลาที่ใช้มากน้อยแค่ไหนของแต่ละ Team ที่จะทำงานเหล่านั้นใน sprint ได้ Team ส่วนใหญ่จะ focus งานที่เกี่ยวข้องกับ Sprint อยู่แค่ 4 – 6 ชั่วโมงต่อวัน เพราะที่เหลือก็จะใช้ไปกับ email , กินข้าว, facebook, meeting และ กินกาแฟ โดยเมื่อเรากำหนด capacity ออกมาได้เลย Team ก็จะต้องบอกได้ว่า จะสามารถทำ Item ใน Product backlog ได้เสร็จมากน้อยแค่ไหน ในกรอบเวลาที่จำกัด เพื่อทำให้ sprint นั้นสำเร็จให้ได้ โดยปกติ ก็มักจะเริ่มจาก การวาดๆ และตกลงกันบน white board ก่อน จากนั้น เมื่อทุกคนเข้าใจ design ที่ตรงกันหมดแล้ว ก็จะแบ่ง Product Backlog item ออกมาเป็นงานที่เหมาะสมที่ต้องทำจริงๆ ก่อนที่จะเริ่มทำ Product Backlog item นั้น The Team อาจจะให้ความสำคัญในการสร้าง task เพื่อปรับปรุงเป้าหมาย ที่ได้มาจากการทำ Sprint’s Retrospective ในรอบก่อน จากนั้น the Team ก็เริ่มต้นทำงานที่มีความสำคัญที่สุดใน product backlog ก่อน และไล่เรียงลงมาเรื่อยๆ จนกระทั่งสามารถทำได้ครบทั้งหมด แต่ละ item ที่ได้ สร้างย่อยลงมา ก็จะต้องสัมพันธ์กับ Product backlog item ด้วย หรือ เมื่อ product backlog item ถ้ามีขนาดที่เล็กมากพอที่จะสามารถทำได้เสร็จใน 2 ชั่วโมงก็เอา product backlog มาใช้เลยก็ได้โดย list เหล่านี้ใน sprint เราจะเรียกว่า Sprint Backlog

ในช่วงท้ายของ Sprint Planning Meeting the Team จะต้องตั้งเป้าหมาย อะไรบ้าง ที่เชื่อว่าจะทำเสร็จ และ อะไรบ้างที่จะ deliver ได้เมื่อจบ sprint โดยปกติเราเรียกสิ่งนี้ว่า Sprint Commitment ซึ่ง The Team ได้ commit ว่าจะทำอย่างดีที่สุด เพื่อให้ไปถึงเป้าหมาย แต่น่าเสียดายว่า ส่วนใหญ่มักจะตีความหมายผิดว่ามันเป็นสัญญาเลือด มากกว่าตีความหมายว่า “มุ่งมั่นไปให้ถึง” แต่เพื่อไม่ให้สับสน เราจะเรียกว่า “การประเมิน” เพื่อใช้สื่อสารกันระหว่าง Product Owner

Scrum จะกระตุ้นให้เกิดการทำงานที่หลากหลายรูปแบบ มากกว่าการทำงานตาม Title หรือตำแหน่งของตัวเอง เช่น tester ก็นั่ง test อย่างเดียวเป็นต้น หรือ อีกความหมายก็คือ ทำอย่างไรก็ได้ ที่สามารถทำให้งานมันสำเร็จออกมาได้มากที่สุด เท่าที่แต่ละคนจะทำได้ ถ้าพบว่ามีงาน test ที่มีเหลือเยอะมาก ทั้งทีม ก็อาจจะต้องช่วยเหลือกันทำให้หมด แต่ก็ไม่ได้มุ่งหมายให้ทุกคนทำได้ทุกๆอย่าง ไม่ได้ต้องการให้ทำงานทับซ้อนกับคนที่มีหน้าที่หลักๆในเรื่องเหล่านั้นอยู่แล้ว แต่ว่าสมาชิกของ Team จะต้องทำงานร่วมกัน และได้เรียนรู้ skill ใหม่ๆไปพร้อมๆกัน ดังนั้นแล้ว ก็ไม่จำเป็นต้องยึดติดว่า ใครคือ volunteer ใน task จากตอนทำ sprint planning แต่มันคือ “ทุกคนต้องทำให้ดีที่สุด” ถึงกระนั้น แต่ละ task ก็ควรมี volunteer เพียงหนึ่งคนเท่านั้น และเมื่อได้เลือก task อะไร ก็ควรเป็น task ที่ทำให้ได้เรียนรู้ในสิ่งใหม่ด้วย ซึ่งก็อาจจะต้องไปนั่ง pair กับ specialist ด้วยในระหว่างการทำงาน

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

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

หลายๆทีมจะมี sprint backlog แปะเอาไว้บนกำแพง (ปกติจะเรียกว่า Scrum Board) โดย task ก็จะเขียนใส่ใน Post-It แปะเอาไว้โดยจะมีการแบ่ง column ออกมาเป็น “To Do”, “Work In Progress” และ “Done”

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

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

ถ้าดำเนินการตามแนวทางปฏิบัตินี้ Product Owner จะได้สองสิ่ง อย่างแรกคือ มั่นใจได้ว่า ทีมจะตั้งใจทำงานอย่างดีที่สุด เพื่อให้ออกมาสำเร็จอย่างที่เราได้ตกลงกันเอาไว้ตั้งแต่แรก เมื่อผ่านไประยะหนึ่ง ทีมจะสามารถส่งมอบงานได้อย่างต่อเนื่อง และเหมือนอย่างที่ประเมินเอาไว้ อย่างที่สอง ไม่ว่าจะเกิดการเปลี่ยนแปลงอะไรก็ตาม Product Owner จะต้องเอาไปใส่ใน Product Backlog เอาไว้ เพื่อรอ next sprint โดยจุดนี้ ไม่ว่าจะเป็นการเพิ่ม การลด การเปลี่ยน ทีมก็ยินดีที่จะทำอย่างแน่นอน ตัว Product Owner เองก็ไม่ควรทำให้เกิดการเปลี่ยนแปลงใดๆระหว่าง sprint ด้วย แม้ว่าอยากจะให้เปลี่ยนมากแค่ไหนก็ตาม โดยการเปลี่ยนนั้น ก็หมายรวมถึง แก้ไขแนวทาง, แก้ไข requirement หรือแม้กระทั่งเปลี่ยนใจ นั่นคือ Product owner จำเป็นที่ต้องปฏิบัติตามแนวทางของ scrum เหมือนทุกๆคนด้วยเหมือนกัน

Daily Scrum

คืออะไร : เป็นการ update และแลกเปลี่ยนข้อมูลกัน ระหว่างคนทำงาน
ผู้ที่เข้าร่วม :  ก็คือ Team จำเป็นต้องเข้า Product Owner จะเข้าหรือไม่ก็ได้ ScrumMaster โดยปกติจะร่วมด้วย
เวลาที่ใช้ : ไม่ควรเกิน 15 นาที

เมื่อเริ่ม sprint แล้ว Team ควรดำเนินการตามหลักอีกอย่างของ Scrum ก็คือ Daily Scrum นี่คือการ meeting สั้นๆ โดยจะมีทุกๆวันทำงาน ตามเวลาที่ตกลงกันเอาไว้ และควรจะให้ทุกๆคนยืนตลอดการ daily scrum นี่เป็นช่วงเวลาที่ให้ทีม ประสานงาน แลกเปลี่ยนข้อมูล และ รายงานซึ่งกันและกัน โดยใน Daily scrum จะมีสามอย่างที่แต่ละคนต้องเล่าให้กับคนอื่นฟัง นั่นคือ จากที่เจอกันครั้งก่อน จนตอนนี้ ทำอะไรเสร็จไปบ้าง , มีอะไรที่ต้องทำให้เสร็จก่อนจะเจอกันครั้งต่อไปบ้าง , พบปัญหาหรือข้อติดขัดอะไรตรงไหนบ้าง สิ่งที่ต้องดูก็คือ Daily Scrum ไม่ใช่ status meeting เพื่อรายงานให้กับหัวหน้า มันคือเวลาที่ team จะแสดงถึงการบริหารตัวเองให้กับเพื่อนๆ เพื่อให้รู้ว่า เกิดอะไรขึ้น จะช่วยเหลืออะไรกันยังไงได้บ้าง อาจจะมีบางคนบันทึกสิ่งทีติดขัดเอาไว้ และ Scrum Master ก็จะต้องทำหน้าที่ในการช่วยเหลือสิ่งเหล่านั้น โดยไม่ควรมี การพูดคุยกันในเรื่อง technical ในระหว่างนี้ หรือ ถ้ามีก็ควรจะน้อยมากๆ เพราะจะต้องเน้นการรายงาน ถึงสามเรื่องตามที่กล่าวไปข้างต้นแล้วเท่านั้น แต่ถ้า มีความจำเป็นต้องคุยกันรายละเอียดก็ให้แยกวงไปคุยหลังจากที่ daily scrum จบแล้ว การประชุมต่อหลังจากที่จบ Daily Scrum ไม่ได้เป็นเรื่องที่จำเป็นตาม style ของ scrum อีกทั้ง สำหรับทีมที่พึ่งเริ่ม scrum นั้นไม่ควรมี หัวหน้า หรือคนที่มีตำแหน่งสูงกว่าเข้าร่วม Daily Scrum เพราะว่าจะทำให้เกิดสิ่งที่เรียกว่า การ “monitor” และภายใต้แรงกดดันนั้นก็จะทำให้เกิดการรายงานความก้าวหน้าที่ไม่ตรงตามความเป็นจริง รวมถึงไม่พูดถึงปัญหา และก็จะทำให้ Team ไม่สามารถเกิดสิ่งที่เรียกว่า self management ได้(หรือ micro management) การเอาตัวออกห่าง อาจจะมีประโยชน์สำหรับ stakeholder มากกว่าการเข้าไปติดตามการทำงาน หรือ พยายามช่วยเหลือปัญหาบางอย่างที่ทีมเจออยู่ ระหว่างการทำงานของทีม

การติดตามการทำงานระหว่าง Sprint
การทำงานของ The Team ใน Sprint นั้นเป็นการบริหารจัดการด้วยตัวเอง ดังนั้นการทำเพื่อให้มั่นใจว่า จะดำเนินไปได้อย่างราบลื่น จึงจำเป็นต้องรู้ว่า กำลังทำอะไรกันอยู่ ในทุกๆวัน Team member จะต้อง update estimate ของงานที่ยังเหลืออยู่ เพื่อให้สำเร็จ ตาม Sprint Backlog ที่กำลังทำกันอยู่นี้ ซึ่งก็จะมีคนที่ดำเนินการ plot graph ออกมาเป็น Sprint Burndown Chart ออกมา โดย graph นี้จะบอกได้ว่า ยังมีงานเหลืออีกเท่าไร ที่ยังเหลือจนกว่าทีมจะทำงานได้สำเร็จทั้งหมด โดยทฤษฏีแล้ว กราฟก็จะตกลงมาเรื่อยๆ จนเหลือ 0 เมื่อวันที่ จบ sprint เราเรียกสิ่งนี้ว่า Burndown Chart นี่เป็นสิ่งที่ใช้อธิบายความจริงที่เกิดขึ้นใน product development ความหมายที่ถูกต้องของมันก็คือ ความก้าวหน้าของทีมที่กำลังดำเนินไป โดยไม่ได้สื่อว่า ใช้เวลาไปมากน้อยเท่าไร ในช่วงที่ผ่านไป แต่ว่ามันบอกว่า เหลืองานอีกมากน้อยแค่ไหนใน sprint นี้ และนี่ก็เป็นสิ่งที่แตกต่างจากเป้าหมายของทีมด้วย ถ้า เส้น graph Burndown ลดต่ำลงมาเรื่อยๆ ไม่ track กับสิ่งที่ควรจะเป็นก่อนจะจบ sprint ทีมอาจจะต้องมาคิดร่วมกันว่าจะทำอย่างไร ไม่ว่าจะเป็นการลด scope หรือ หาทางทำงานให้ได้เร็วขึ้น เพื่อให้สามารถทำงานเสร็จได้อย่างเหมาะสมในเวลาที่ยังเหลืออยู่

Sprint burndown chart สามารถใช้ excel ก็ได้ แต่ว่าหลายทีมก็เลือกใช้สิ่งที่ดีกว่า ด้วยการเขียนออกมาเป็น paper บนกำแพง และเขียนด้วยปากกา นี่เป็น “low-tech/high-touch” หรือ เรียบง่ายแต่เข้าถึงได้ เพราะว่า เร็ว, เรียบง่าย และได้เห็นมากกว่าการใช้ Computer chart อีกด้วย

 

ถึงจุดนี้ เราก็ได้รู้จัก 2 กิจกรรมที่ต้องทำเป็นประจำแล้ว เพื่อให้เราได้รู้ถึง progress ของงาน และให้มั่นใจว่าทุกคนกำลังทำงานไปในแนวทางเดียวกัน สำหรับพรุ่งนี้ จะเป็นอีก สามกิจกรรมสุดท้ายที่ต้องทำในแบบฉบับของ scrum หากต้องการอ่านเรื่องอื่นๆ ที่เป็นเนื้อหาแปลมาจาก scrumprimer สามารถกดที่ tag ‘scrumprimer’ ที่ด้านล่างได้เลยครับ