Ken Schwaber & Jeff Sutherlandคู่มือ Scrum
The Definitive Guide to Scrum: The Rules of the Gameพฤศจิกายน 2020

Purpose of the Scrum Guideพวกเราได้ทาํ การพัฒนา Scrum ในช่วงต้นทศวรรษ 1990 โดยได้ทาํ การเขียนคูม่ อื Scrum ขึน้ เป็ นครัง้ แรกในปี 2010เพือ่ ช่วยให้คนทัง้ โลกได้เข้าใจ Scrum ตลอดระยะเวลาทีผ่ า่ นมาพวกเราสองคนได้เรียบเรียงและแก้ไขคูม่ อื Scrumให้มกี ารปรับปรุงอยูเ่ สมอและเราทัง้ สองคนก็ยงั คงร่วมมือกันพัฒนาคูม่ อื Scrum ต่อไปคูม่ อื เล่มนี้ประกอบไปด้วยคําอธิบายต่าง ๆ ทีป่ ระกอบเข้าด้วยกันเป็ นการทํางานแบบ Scrumโดยแต่ละส่วนประกอบมีจุดประสงค์เฉพาะทีจ่ าํ เป็ นต่อการสร้างมูลค่าและผลลัพธ์ทจ่ี ะได้จากการทํางานแบบ Scrumถ้าการนําเอา Scrum ไปใช้เพียงบางส่วนโดยไม่ปฏิบตั ติ ามคําแนะนําทีไ่ ด้กาํ หนดไว้ในคูม่ อื เล่มมนี้
อาจจะทําให้เกิดปั ญหาต่าง ๆ ตามมาและไม่ได้รบั ประโยชน์จากการทํางานแบบ Scrum ได้พวกเราพบว่ามีการนําเอา Scrum ไปใช้เพิม่ มากขึน้ พร้อม ๆ กับความซับซ้อนทีเ่ พิม่ มากขึน้ บนโลกใบนี้
พวกเรารูส้ กึ เป็ นเกียรติทไ่ี ด้รวู้ ่าแม้ Scrum จะมีจุดกําเนิดในวงการพัฒนาซอฟต์แวร์แต่มกี ารนําเอา Scrumไปใช้ในธุรกิจและวงการอื่น ๆ อีกมากมาย ในคูม่ อื Scrum เราใช้คาํ ว่า Developer ไว้เรียกคนทีท่ าํ งานหรือผลิตงานไม่วา่ คุณจะเป็ นนักพัฒนา นักวิจยั นักวิเคราะห์ นักวิทยาศาสตร์ หรือทํางานในบทบาทหน้าทีใ่ ดก็ตาม ถ้าคุณทํางานในทีมScrum แล้วสร้างมูลค่า (Value) ขึน้ มาได้ พวกคุณก็คอื Developer นันเอง่รูปแบบ กระบวนการทํางานและความรูอ้ ่นื ๆ ทีส่ ามารถนํามาปรับใช้กบั การทํางานแบบ Scrum มีอยูใ่ นแหล่งความรูอ้ ่นื ๆอีกมากมาย ซึง่ แต่ละรูปแบบ กระบวนกการในการทํางานและความรูเ้ หล่านัน้ มีจุดประสงค์ทแ่ี ตกต่างกันออกไปKen Schwaber และ Jeff Sutherlandพฤศจิกายน 2020

© 2020 Ken Schwaber and Jeff Sutherland
This publication is offered for license under the Attribution Share-Alike license of Creative Commons,accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary
form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share-Alike license of Creative Commons.

1

Purpose of the Scrum Guide ......................................................................................................................... 1
Scrum Definition ........................................................................................................................................... 3
Scrum Theory ................................................................................................................................................ 3
Transparency............................................................................................................................................. 4
Inspection.................................................................................................................................................. 4
Adaptation ................................................................................................................................................ 4
Scrum Values ................................................................................................................................................. 5
Scrum Team .................................................................................................................................................. 5
Developers ................................................................................................................................................ 6
Product Owner .......................................................................................................................................... 6
Scrum Master ............................................................................................................................................ 7
Scrum Events ................................................................................................................................................. 8
The Sprint .................................................................................................................................................. 8
Sprint Planning .......................................................................................................................................... 9
Daily Scrum ............................................................................................................................................. 11
Sprint Review .......................................................................................................................................... 11
Sprint Retrospective................................................................................................................................ 12
Scrum Artifacts ............................................................................................................................................ 12
Product Backlog ...................................................................................................................................... 12
Commitment: Product Goal ................................................................................................................ 13
Sprint Backlog ......................................................................................................................................... 13
Commitment: Sprint Goal ................................................................................................................... 13
Increment ................................................................................................................................................ 14
Commitment: Definition of Done ....................................................................................................... 14
End Note ..................................................................................................................................................... 16
Acknowledgements................................................................................................................................. 16People ................................................................................................................................................. 16
Scrum Guide History ........................................................................................................................... 16
Translator and Editors Acknowledgement ......................................................................................... 16
Changes from 2017 Scrum Guide to 2020 Scrum Guide..................................................................... 172

Scrum Definition
Scrum เป็ นรูปแบบหรือกรอบในการทํางานทีเ่ ข้าใจได้งา่ ย ช่วยให้คนทีท่ าํ งานด้วยกัน ทีมทํางานและองค์กรต่าง ๆสามารถสร้างสิง่ ทีม่ คี ุณค่าผ่านการทํางานและการแก้ปัญหาทีซ่ บั ซ้อนด้วยแนวคิดการทํางานทีส่ ามารถปรับเปลีย่ นให้ทนั ต่อสถานการณ์
การทํางานแบบ Scrum จําเป็ นต้องมี Scrum Master มาร่วมสร้างสภาพแวดล้อมในการทํางานทีม่ ลี กั ษณะดังนี้
1. มี Product Owner เป็นผูเ้ รียงลําดับความสําคัญของงานหรือความต้องการของลูกค้าใน Product Backlog(ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม)2. สมาชิกของทีมผลิตสินค้าหรือบริการทีส่ ร้างมูลค่า (Value) ให้กบั ตัวสินค้าหรือบริการในรอบการทํางานทีก่ าํ หนด
3. สมาชิกของทีมและผูม้ สี ว่ นเกีย่ วข้องในสินค้าหรือบริการร่วมกันตรวจสอบผลลัพธ์และทําการปรับปรุงแก้ไขในรอบการทํางานถัดไป
4. ทําซํ้าข้อ 1-3 ไปเรือ่ ย ๆ
Scrum เป็ นเรือ่ งทีเ่ ข้าใจได้งา่ ย เราขอแนะนําให้ลองเอา Scrum ไปใช้ดตู ามแบบทีเ่ ราได้แนะนําแล้วลองพิจารณาดูวา่
แนวคิด ทฤษฏีและโครงสร้างของ Scrumช่วยทําให้คุณทํางานให้สาํ เร็จตามเป้ าหมายทีต่ อ้ งการและสร้างมูลค่าให้กบั สิง่ ทีค่ ุณทําอยูห่ รือไม่ รูปแบบการทํางานแบบScrum มีความไม่สมบูรณ์ในตัวของมันเอง ซึง่ ต้องอาศัยการสร้างทฤษฎีตามแนวคิดของ Scrum ให้เกิดขึน้ Scrumจะเกิดขึน้ ได้เมือ่ Scrumถูกนําไปใช้โดยคนทีม่ คี วามเฉลียวฉลาดซึง่ จะดีกว่าคนทีต่ อ้ งการทําตามขัน้ ตอนหรือกฏกติกาทีล่ งรายละเอียดชัดเจนกระบวนการทํางาน เทคนิคต่าง ๆ และวิธกี ารทํางานทีห่ ลากหลายในรูปแบบอื่น ๆ สามารถถูกนํามาใช้ในการทํางานแบบScrum ได้ Scrum ยังทําให้เห็นภาพปั จจุบนั ของการบริหารจัดการธุรกิจ สภาพแวดล้อมในการทํางานและความรูท้ างเทคนิคทีจ่ ะได้รบั การปรับปรุงแก้ไขให้ดขี น้ึ เรือ่ ย ๆ ในเวลาต่อมา

Scrum TheoryScrum ถูกคิดค้นขึน้ มาจากแนวคิด Empiricism และ Lean Thinking ซึง่ แนวคิดแบบ Empiricism
อาศัยความรูท้ ไ่ี ด้จากการลงมือทําจริงและทําการตัดสินใจจากตัวแปรทีไ่ ด้จากการสังเกตและลงมือปฏิบตั จิ ริง ส่วน LeanThinkingเป็ นแนวคิดทีต่ อ้ งการกําจัดของเสียหรือสิง่ ทีไ่ ม่ก่อให้เกิดประโยชน์ในกระบวนการทํางานและให้ความสําคัญกับสิง่ ทีจ่ าํ เป็ นเท่านัน้
3

Scrum เป็ นแนวคิดในการทําให้งานเสร็จเพิม่ มากขึน้ เรือ่ ย ๆ เพือ่ ให้สามารถคาดการณ์สงิ่ ต่าง ๆได้ล่วงหน้าและควบคุมความเสีย่ งทีจ่ ะเกิดขึน้ ได้ Scrumประกอบไปด้วยกลุ่มคนทีม่ ที กั ษะและความชํานาญทีห่ ลากหลายและจําเป็ นต่อการทํางานกลุ่มคนเหล่านี้พร้อมทีจ่ ะเรียนรูแ้ ละแลกเปลีย่ นความรูใ้ ห้กนั และกันใน Sprint (รอบการทํางาน) จะมี 4 ประชุมอย่างเป็ นทางการ (Sprint Planning, Daily Scrum, Sprint Review, SprintRetrospective) เพือ่ เปิ ดโอกาสให้เกิดการตรวจสอบและปรับปรุงแก้ไขการทํางานได้ การประชุมทัง้ 4นี้ก่อให้เกิดประสิทธิภาพและประสิทธิผลเพราะทําให้เกิดการทํางานทีโ่ ปร่งใส (Transparency) การตรวจสอบได้(Inspection) การปรับปรุงแก้ไขได้ (Adaptation)

Transparencyงานและกระบวนการทํางานต้องถูกทําให้มองเห็นอย่างโปร่งใสสําหรับผูท้ จ่ี ะต้องทํางานร่วมกันเพราะการตัดสินใจในการทํางานแบบ Scrum นัน้ เริม่ ต้นจาก Artifacts (ผลลัพธ์ทไ่ี ด้จากการทํางานแบบ Scrum) ทีป่ ระกอบไปด้วย Product Backlog,Sprint Backlog และ Product Increment ถ้า Artifacts เหล่านี้ไม่มคี วามโปร่งใสแล้วจะก่อให้เกิดการตัดสินใจทีล่ ดมูลค่า(Value) ของงานและมีความเสีย่ งเพิม่ มากขึน้การทํางานทีม่ คี วามโปร่งใสจะทําให้เกิดการตรวจสอบขึน้ ได้การตรวจสอบทีป่ ราศจากความโปร่งใสจะทําให้เกิดความเข้าใจผิดในสิง่ ต่าง ๆ และส่งให้เกิดผลเสียตามมาInspectionผลลัพธ์ทไ่ี ด้จากการทํางานแบบ Scrum หรือทีเ่ รียกว่า Artifactsรวมไปถึงความคืบหน้าของงานซึง่ ควรได้รบั การตรวจสอบเพือ่ เทียบกับเป้ าหมายทีไ่ ด้ตกลงกันไว้ก่อนอย่างสมํ่าเสมอเพือ่ ป้องกันปั ญหาทีอ่ าจจะเกิดขึน้ ในการทํางานแบบ Scrum นัน้ มี 4 ประชุมทีร่ วม Sprint หรือการทํางาน (Sprint Planning,Daily Scrum, Sprint Review, Sprint Retrospective, Sprint) ทีเ่ ปิ ดโอกาสให้เกิดการตรวจสอบเกิดขึน้ ได้การตรวจสอบทําให้เกิดการปรับปรุงแก้ไขถ้ามีการตรวจสอบเกิดขึน้ แล้วไม่มกี ารปรับปรุงแก้ไขถือว่าการตรวจสอบทีไ่ ร้ประโยชน์ดังนัน้ การประชุมหรือกิจกรรมทัง้ หมดใน Scrum ต้องนําไปสูก่ ารปรับปรุงแก้ไขทีด่ ขี น้ึAdaptation
4ถ้าพบว่ากระบวนการทํางานใด ๆเกิดการปรับเปลีย่ นมากไปกว่าทีไ่ ด้ตกลงกันไว้หรือผลลัพธ์จากการทํางานไม่ได้ตามผลทีค่ าดการณ์ไว้กระบวนการทํางานรวมไปถึงสิง่ ต่าง ๆทีอ่ ยูใ่ นกระบวนการทํางานนัน้ จะต้องถูกปรับปรุงแก้ไขให้เร็วทีส่ ุดเท่าทีจ่ ะทําได้เพือ่ ลดความเสียหายทีจ่ ะเกิดขึน้ ตามมาScrum Valuesการนําเอา Scrum ไปใช้จะประสบความสําเร็จได้กต็ ่อเมือ่ ผูน้ ําไปใช้ได้นําเอาคุณค่าของ Scrum ทัง้ 5ข้อนี้ไปปฏิบตั อิ ย่างจริงจัง
ความมุ่งมัน่ (Commitment), การทุ่มเท (Focus), การเปิ ดใจ (Openness),ความเคารพ (Respect), และความกล้าหาญ (Courage)
Scrum Team มีความมุง่ มันและให้่การสนับสนุนกันและกันเพือ่ ทํางานให้เสร็จตามเป้ าหมายทีไ่ ด้ตกลงกันไว้ Scrum Teamให้ความสนใจทุ่มเทเวลาและอีกหลายๆ อย่างเพือ่ ให้งานมีความคืบหน้าตามเป้ าหมายให้มากทีส่ ดุ Scrum Teamและผูม้ สี ว่ นเกีย่ วข้องกับงานทัง้ หมดเปิ ดใจรับฟั งเรือ่ งทีเ่ กีย่ วกับงาน ความท้าทายและปั ญหาทีเ่ กิดขึน้สมาชิกของทีมให้ความเคารrต่อกันและกันทีแ่ ต่ละคนมีความสามารถ มีลกั ษณะส่วนบุคคลทีแ่ ตกต่างกัน
สมาชิกของทีมควรได้รบั การเคารพเช่นนี้จากทุกคนทีเ่ กีย่ วข้อง
คุณค่าของ Scrum ช่วยกําหนดทิศทางการทํางานและพฤติกรรมในการทํางานร่วมกันของสมาชิกในทีมไม่วา่ จะเป็ นการตัดสินใจและวิธกี ารดําเนินงานควรสอดคล้องกับคุณค่าของ Scrum และไม่ทาํ ให้คุณค่าของ Scrum ลดลงเมือ่ ทีมได้ทาํ งานร่วมกันผ่านการประชุม กิจกรรมต่าง ๆ จนได้สร้างผลงานร่วมกันก็จะได้คน้ พบและเรียนรูค้ ุณค่าของScrum นี้รว่ มกัน ถ้าสมาชิกในทีมรวมไปถึงผูท้ ม่ี สี ว่ นเกีย่ วข้องทัง้ หมดได้รบั เอาคุณค่าของ Scrumห้าข้อนี้มาใช้อย่างจริงจังจะก่อเกิดความไว้วางใจต่อกันและกันแล้วส่งผลให้เกิดการทํางานทีโ่ ปร่งใสสามารถตรวจสอบและปรับเปลีย่ นแก้ไขได้อย่างแท้จริงScrum TeamScrum Team คือทีมงานเล็ก ๆ ประกอบไปด้วย Scrum Master 1 คน Product Owner 1 คนและ Developer หลายคนในทีม Scrum ไม่มที มี งานย่อยหรือลําดับขัน้ ของตําแหน่งงานในการทํางานร่วมกัน ทีมงาน Scrumเป็ นทีมของคนทีม่ คี วามเป็ นมืออาชีพทีม่ าร่วมกันทํางานให้บรรลุวตั ถุประสงค์เพียงข้อเดียวในการทํางานทีเ่ รียกว่า ProductGoal (เป้ าหมายของการสร้างผลิตภัณฑ์) นันเอง่ทีม Scrum มีลกั ษณะ Cross-Functionalคือสมาชิกในทีมเมือ่ เอาทักษะทีแ่ ต่ละคนมีมารวมกันเพือ่ สร้างผลิตภัณฑ์หรือทํางานให้สาํ เร็จได้ สมาชิกในทีมยังมีลกั ษณะ
Self-Managing ทีส่ มาชิกในทีมสามารถบริหารจัดการในทีมได้เองว่าใครจะทํางานอะไร เมือ่ ไหร่ และอย่างไร5ขนาดของ Scrum Teamมีขนาดไม่เล็กไม่ใหญ่เกินไปเพือ่ ให้ทมี มีความคล่องตัวขณะเดียวกันก็สามารถทํางานให้เสร็จสมบูรณ์ในแต่ละ Sprint ได้ซึง่ ควรมีสมาชิกไม่เกิน 10 คน โดยทัวไปแล้
่วทีมทีม่ สี มาชิกน้อยกว่าจะสามารถสือ่ สารและทํางานมีประสิทธิภาพมากกว่าScrum Teamมีหน้าทีร่ บั ผิดชอบต่อความต้องการทัง้ หมดทีเ่ กีย่ วข้องกับผลิตภัณฑ์ซง่ึ มาจากผูท้ ม่ี สี ว่ นเกีย่ วข้องกับตัวผลิตภัณฑ์นนั ้และรวมถึงข้อเสนอแนะหลังจากการตรวจสอบ กิจกรรมการดูแลรักษาผลิตภัณฑ์ การทดลองและวิจยั เพือ่ พัฒนาผลิตภัณฑ์
และอื่น ๆ ทีเ่ กีย่ วข้อง โดยที่ Scrum Team ได้รบั มอบอํานาจจากองค์กรให้บริหารจัดการตนเอง การทํางานของ Scrum
Team ทีไ่ ม่หกั โหมหรือหย่อนยานมากเกินไปย่อมทําให้เกิดการทํางานทีย่ งยืั่ นทําให้ทมี สามารถมุง่ เน้นทํางานของตนเองได้อย่างต่อเนื่อง
สมาชิกของ Scrum Team ทัง้ หมดมีหน้าทีร่ บั ผิดชอบในการสร้าง Increment (ผลลัพธ์จากการทํางานในแต่ละ Sprint)ทีม่ มี ลู ค่าและใช้งานได้ในทุก Sprint (รอบการทํางาน) โดย Scrum Team จะประกอบไปด้วย Developer หลายคน ProductOwner 1 คน และ Scrum Master 1 คนDevelopersDevelopers คือ สมาชิกของ Scrum Team ทีท่ าํ หน้าทีส่ ร้างผลิตภัณฑ์พวกเขาให้คาํ มันสั่ ญญาในการทีจ่ ะสร้างสิง่ ทีม่ มี ลู ค่าและใช้งานได้ในทุก Sprint (รอบการทํางาน)Developers ควรมีทกั ษะทีห่ ลากหลายในตนเองทีแ่ ตกต่างกันไปตามขอบเขตของงานทีต่ นเองรับผิดชอบพวกเขามีหน้าทีด่ งั นี้••••วางแผนงานทีจ่ ะทําใน Sprint (รอบการทํางาน) นัน้ ๆ ทีเ่ รียกว่า Sprint Backlog
กําหนดมาตรฐานของงานทีเ่ สร็จสมบูรณ์หรือทีเ่ รียกว่า Definition of Doneปรับเปลีย่ นแผนในแต่ละวันให้สอดคล้องกับ Sprint Goal (เป้ าหมายของ Sprint)ทํางานร่วมกันแบบมืออาชีพProduct Owner
Product Owner มีหน้าทีส่ ร้างมูลค่าสูงสุดให้กบั ผลิตภัณฑ์ท่ี Scrum Team ได้สร้างขึน้ มาวิธกี ารทีจ่ ะทําให้ได้ตามนี้ขน้ึ อยูน่ โยบายของแต่ละองค์กร แต่ละ Scrum Teamหรือแม้แต่ความสามารถส่วนบุคคลของสมาชิกในทีม
Product Owner มีหน้าทีบ่ ริหารจัดการ Product Backlog (รายการงานทัง้ หมดทีจ่ ะต้องทําเพื่อสร้างผลิตภัณฑ์)และรวมไปถึงหน้าทีเ่ หล่านี้•กําหนดและปรับปรุง Product Goal (เป้ าหมายของผลิตภัณฑ์) เพือ่ สือ่ สารกับทีมงาน6•••เขียนความต้องการของลูกค้าและรายการงานทีต่ อ้ งทําใน Product Backlog(ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม) เพื่อสือ่ สารกับทีมงานเรียงลําดับ Product Backlog Items (ความต้องการของลูกค้าและรายการงานทีต่ อ้ งทํา)ทําให้ Product Backlog มีความโปร่งใส มองเห็นได้งา่ ย และทุกคนเข้าใจตรงกันProduct Owner อาจจะทํางานดังกล่าวด้านบนด้วยตนเองหรือมอบหมายให้คนอืน่ ทําให้กไ็ ด้ แต่อย่างไรก็ตาม ProductOwner เป็ นเจ้าภาพรับผิดชอบในงานดังกล่าว
คนในองค์กรควรให้การสนับสนุนการทํางานและการตัดสินใจของ Product Owner เพือ่ ให้เกิดผลสําเร็จ การตัดสินใจของProduct Owner ประกอบไปด้วยความต้องการของลูกค้าทีอ่ ยูใ่ น Product Backlog(ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม) ทีม่ คี วามชัดเจนมองเห็นได้งา่ ยและมีการเรียงลําดับเรียบร้อยแล้ว รวมไปถึง Increment (ผลลัพธ์จากการทํางานในแต่ละ Sprint)ทีส่ ามารถตรวจสอบได้ใน Sprint ReviewProduct Owner มีเพียงหนึ่งคนเท่านัน้ ไม่ใช่มหี ลายคนแบบชุดคณะกรรมการ โดยที่ Product Ownerเป็ นตัวแทนจากคนทีเ่ กีย่ วข้องทัง้ หมดทีส่ ามารถเพิม่ หรือเปลีย่ นความต้องการงานทีต่ อ้ งทําโดยการพูดคุยหรือต่อรองกับทา
ง Product Owner

Scrum MasterScrum Master มีหน้าทีท่ าํ ให้เกิดการทํางานแบบ Scrum ตามคูม่ อื นี้ ด้วยการช่วยเหลือให้คนใน Scrum Teamและในองค์กรเข้าใจทัง้ ทฤษฎีและสามารถลงมือปฏิบตั ไิ ด้จริงScrum Master มีหน้าทีร่ บั ผิดชอบต่อประสิทธิผลของ Scrum Teamด้วยการส่งเสริมให้มกี ารปรับปรุงการทํางานอยู่ตลอดเวลา โดยที่ Scrum Master เป็ นผูน้ ําทีช่ ว่ ยเหลือผูอ้ ่นื ก่อนไม่วา่ จะเป็ นคนใน Scrum Team หรือคนอื่น ๆ ในองค์กรScrum Master ให้การช่วยเหลือและสนับสนุน Scrum Team ดังนี้••••ทําการโค้ชสมาชิกของทีมเพื่อสามารถทํางานลักษณะ Self-Managementหรือทีมทีส่ ามารถบริหารจัดการตนเองได้ และ CrossFunctionality หรือการทํางานร่วมกับคนหลายคนทีแ่ ต่ละคนมีความสามารถทีห่ ลากหลายทีส่ ามารถทํางานให้เสร็จสิน้ จากคนกลุ่มนี้โดยไม่อาศัยคนภายนอกทีมเลย
ช่วยทําให้ Scrum Team ได้มงุ่ เน้นกับงานเพือ่ สร้าง Increments (ผลลัพธ์จากการทํางานในแต่ละ Sprint)ทีผ่ า่ นการทดสอบตาม Definition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์) และมีมลู ค่าสูงสุดกําจัดปั ญหาทีท่ าํ ให้ทมี ทํางานช้าลงทําให้การประชุมต่าง ๆ ของการทํางานแบบ Scrum เกิดขึน้ ในทางทีด่ ี มีประสิทธิภาพและอยูใ่ นเวลาทีก่ าํ หนด
7

Scrum Master ให้การช่วยเหลือและสนับสนุน Product Owner ดังนี้••••ช่วยหาเทคนิคในการกําหนด Product Goal (เป้ าหมายของผลิตภัณฑ์)ทีม่ ปี ระสิทธิภาพ และบริหารจัดการProduct Backlog (ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม)ช่วยทําให้ Scrum Team เข้าใจความต้องการของลูกค้าทีอ่ ยูใ่ น Product Backlog ได้อย่างชัดเจนและความกระชับช่วยทําให้เกิดการวางแผนการทํางานทีส่ ามารถเรียนรูไ้ ด้จากหน้างานจริงภายใต้สภาวะการทํางานทีม่ คี วามซับซ้อน
สร้างความร่วมมือให้กบั ทุกคนทีม่ สี ว่ นเกีย่ วข้องกับการทํางาน

Scrum Master ให้การช่วยเหลือและสนับสนุนองค์กรดังนี้••••ทําการอบรม โค้ชและนําพาให้คนในองค์กรสามารถทํางานแบบ Scrum ได้ให้คาํ ปรึกษาและช่วยวางแผนในการนําเอา Scrum ไปใช้ในองค์กรทําให้พนักงานในองค์กรและผูม้ สี ว่ นเกีย่ วข้องเข้าใจวิธกี ารทํางานแบบ Empiricism
หรือการทํางานกับหน้างานจริงภายใต้สภาวะการทํางานทีม่ คี วามซับซ้อนช่วยเชือ่ มความสัมพันธ์ระหว่าง Scrum Teams และผูม้ สี ว่ นเกีย่ วข้องทัง้ หมด

Scrum Eventsในหนึ่งรอบการทํางาน หรือในหนึ่งรอบ Sprint จะประกอบไปด้วยการประชุมต่าง ๆซึง่ ทําให้เกิดโอกาสอย่างเป็ นทางการในการตรวจสอบและปรับเปลีย่ น Scrum Artifacts (ผลลัพธ์ทไ่ี ด้จากการทํางานแบบScrum) และยังทําให้เกิดความโปร่งใสในการทํางานขึน้ อีกด้วยการทีบ่ างประชุมไม่เกิดขึน้ ทําให้เสียโอกาสในการตรวจสอบและปรับปรุงแก้ไข การประชุมต่าง ๆ ใน Scrumจึงควรจัดขึน้ อย่างเป็ นประจํา สิง่ นี้จะไปช่วยลดการประชุมอื่น ๆ ทีไ่ ม่จาํ เป็ นลงได้ การประชุมใน Scrumนัน้ ควรจัดขึน้ ในสถานทีป่ ระจําและเป็ นเวลาเดิมเพือ่ ลดความยุง่ ยากThe SprintSprint เป็ นหัวใจสําคัญของการทํางานแบบ Scrum เพราะคือช่วงเวลาในการทํางานเพือ่ สร้างมูลค่าในตัวผลิตภัณฑ์Sprints หรือรอบระยะเวลาในการทํางานจะมีความยาวไม่เกินหนึ่งเดือนหรือน้อยกว่า ซึง่ Sprintรอบใหม่จะเริม่ ขึน้ ทันทีหลังจากทีจ่ บการสรุป Sprint ทีผ่ า่ นมาแล้ว8งานต่าง ๆ ทีจ่ ะต้องทําให้แล้วเสร็จภายใน Sprint (รอบในการทํางาน) เพือ่ บรรลุเป้ าหมายของผลิตภัณฑ์หรือ Product
Goal รวมไปถึงการประชุมต่าง ๆ ทีป่ ระกอบไปด้วย Sprint Planning, Daily Scrum, Sprint Review และ Sprint
Retrospective จะต้องทําให้แล้วเสร็จภายใน Sprintในระหว่าง Sprint นัน้••••ไม่ควรทําให้เกิดการเปลีย่ นแปลงใด ๆ ทีจ่ ะทําให้เกิดผลกระทบต่อ Sprint Goal (เป้ าหมายของการทํางานในSprint)คุณภาพของงานไม่ลดลงProduct Backlog (ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม)ได้รบั การบริหารจัดการอย่างสมํ่าเสมอมีการพูดคุยหรือต่อรองกับ Product Ownerในเรือ่ งขอบข่ายของงานทีจ่ ะต้องทําซึง่ สามารถเกิดขึน้ ได้เมือ่ ทํางานและเรียนรูง้ านไปได้ระยะหนึ่งSprints (การทํางานผ่านไปหลาย ๆ รอบ Sprint)ทําให้คาดการณ์ล่วงหน้าได้โดยการตรวจสอบและปรับเปลีย่ นการทํางานให้สอดคล้องกับ Product Goal(เป้ าหมายในการสร้างผลิตภัณฑ์) ถ้า Sprint (รอบการทํางาน) มีระยะนานเกินไปก็อาจจะทําให้ Sprint Goal(เป้ าหมายของการทํางานในรอบนัน้ ) ใช้ไม่ได้ ทําให้งานมีความซับซ้อนและมีความเสีย่ งเกิดขึน้ทางทีด่ คี วรทํางานใน Sprint (รอบการทํางาน) ทีม่ รี อบการทํางานทีส่ นั ้ เพือ่ ให้เกิดการเรียนรูท้ เ่ี ร็วขึน้ลดความเสีย่ งในเรือ่ งของเงินลงทุนและการเสียแรงเปล่าจากการทํางาน
การตรวจสอบความคืบหน้าของงานในแต่ละ Sprint (รอบการทํางาน) สามารถนําเอาเครือ่ งมือเช่น Burn-Downs, BurnUps หรือ Cumulative Flows มาใช้ได้ ซึง่ เครือ่ งมือต่าง ๆ ทีน่ ํามาใช้จะต้องไม่ไปลดความสําคัญของการทํางานแบบ
Empiricism เนื่องจากในการทํางานภายใต้สภาวะทีซ่ บั ซ้อน (Complexity)การทํางานในลักษณะนี้ไม่มใี ครทราบว่าจะมีอะไรเกิดขึน้การตัดสินใจในการทํางานจึงเกิดจากประสบการณ์เคยเกิดขึน้ ก่อนนันเอง่
ถ้าพบว่า Sprint Goal (เป้ าหมายของการทํางานในรอบนัน้ ) ใช้ไม่ได้แล้ว Product Ownerจะเป็ นบุคคลเดียวเท่านัน้ ทีส่ ามารถยกเลิกการทํางานใน Sprint นัน้ ๆ ได้Sprint Planning
Sprint Planning ทําให้รวู้ า่ เราต้องทํางานอะไรใน Sprint (รอบการทํางาน) บ้างโดยต้องอาศัยความร่วมมือของคนทัง้ ทีมในการทํา Sprint Planningก่อนทีจ่ ะมีการประชุมนี้ Product Owner มีหน้าทีท่ าํ ให้ทุกคนมีความเข้าใจใน Product Backlog Items(ความต้องการของลูกค้าและรายการงานทีต่ อ้ งทํา) เพือ่ ให้เกิดความสอดคล้องกับ Product Goal
9(เป้ าหมายของการทําผลิตภัณฑ์) Scrum Team สามารถเชิญบุคคลอื่น ๆทีเ่ กีย่ วข้องกับการทํางานเข้ามาร่วมประชุมด้วยเพือ่ ให้คาํ ปรึกษาหรือคําแนะนําได้
ในการประชุม Sprint Planning มีการพูดคุยกันในประเด็นดังนี้หัวข้อทีห่ นึ่ง: ทําไมการทํางานใน Sprint รอบนี้จงึ มีความสําคัญและจะสร้างมูลค่าProduct Owner เสนอต่อทีมว่าจะต้องทําอะไร ทํางานอะไรเพิม่ เพือ่ ทีจ่ ะทําให้มลู ค่าและประโยชน์ของผลิตภัณฑ์มมี ากยิง่ ขึน้หลังจากนัน้ Scrum Team ช่วยกันกําหนด Sprint Goal (เป้ าหมายของการทํางานใน Sprint นัน้ )เพือ่ สือ่ สารให้กบั ทุกคนทีเ่ กีย่ วข้องได้รบั ทราบ ตัว Sprint Goal ตัองได้รบั การอนุมตั กิ ่อนทีก่ ารประชุม Sprint Planningจะจบลง

หัวข้อทีส่ อง: จะต้องทํางานอะไรให้แล้วเสร็จใน Sprint นี้บา้ งDevelopers พูดคุยกับ Product Owner เพือ่ เลือกความต้องการของลูกค้าจาก Product Backlog(ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม) เข้ามาทําใน Sprint (รอบการทํางาน) นัน้ Scrum
Team และ Product Owner ต้องทําความเข้าใจในงานทีจ่ ะทําเพือ่ เพิม่ ความมันใจว่่ าจะทํางานสําเร็จการเลือกปริมาณงานหรือปริมาณความต้องการของลูกค้ามาทําให้เสร็จนัน้ อาจจะมีความท้าทาย Developersต้องรูศ้ กั ยภาพของตนเองจากการทํางานใน Sprint ผ่านมาและศักยภาพทีค่ าดว่าจะทําได้ในการทํารอบ Sprint นี้ รวมไปถึงDefinition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์) ก็จะทําให้เพิม่ ความมันใจในการทํ่างานได้หัวข้อทีส่ าม: แล้วจะทํางานทีเ่ ลือกมาให้เสร็จได้อย่างไรในแต่ละชิน้ งานหรือแต่ละความต้องการของลูกค้าทีท่ มี เลือกมาทํานัน้ Developerแต่ละคนต้องวางแผนว่าจะทํางานเหล่านัน้ อย่างไรให้เสร็จตาม Definition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์)ทีต่ งั ้ ไว้ โดยเขียนวิธกี ารทํางานออกมาเป็ นขัน้ ตอนย่อย ๆ ทีส่ ามารถทําให้เสร็จได้ภายในหนึ่งวันหรือน้อยกว่าส่วนวิธกี ารทํางาน ว่าจะทํางานอย่างไรนัน้ ให้ขน้ึ อยูก่ บั Developer แต่ละคนเอง ไม่ควรมีคนใดบอกหรือออกคําสังต่่ อDevelopers ว่าจะทํางานอย่างไรเพือ่ ให้งานเหล่านัน้ สร้างมูลค่าได้
ผลลัพธ์ทไ่ี ด้จากการทํา Sprint Planning คือ Sprint Backlog ซึง่ ประกอบไปด้วย Sprint Goal(เป้ าหมายของการทํางานในรอบนัน้ ) และ Product Backlog Items (ความต้องการของลูกค้าและรายการงานทีต่ อ้ งทํา) ที่Scrum Team เลือกมาทํา รวมไปถึงแผนทีเ่ ราจะส่งมอบผลงาน
การทํา Sprint Planning มีเวลาไม่เกิน 8 ชัวโมงสํ่
าหรับ Sprint (รอบการทํางาน) ทีม่ คี วามยาวหนึ่งเดือน ถ้าความยาวของSprint สัน้ กว่านี้ เวลาในการทํา Sprint Planning ก็ควรทีจ่ ะใช้เวลาให้น้อยลง10

Daily Scrum
Daily Scrum หรือการประชุมอัพเดทประจําวันมีวตั ถุประสงค์เพือ่ ตรวจสอบความคืบหน้าของการทํางานเมือ่ เทียบกับSprint Goal (เป้ าหมายของการทํางานในรอบนัน้ ) เพือ่ ปรับ Sprint Backlog และงานทีไ่ ด้วางแผนไว้แล้ว
Daily Scrum ใช้เวลา 15 นาทีสาํ หรับการประชุมของหนึ่ง Scrum Teamการประชุมนี้ควรจัดขึน้ ในสถานทีเ่ ดิมและเวลาเดียวกันทุกวันเพือ่ ลดความยุ่งยากในเรือ่ งต่าง ๆ ทีจ่ ะตามมา ถ้า ProductOwner และ Scrum Master ทํางานในบทบาทของ Developers ก็ตอ้ งเข้าร่วมประชุมนี้ดว้ ยDevelopers ใช้เทคนิคหรือวิธกี ารใด ๆ ก็ได้ในการประชุมนี้
ตราบใดทีย่ งั ทําให้การประชุมมุง่ เน้นไปทีก่ ารทบทวนการทํางานเพือ่ เทียบกับ Sprint Goal(เป้ าหมายของการทํางานในรอบนัน้ ) และมีการกําหนดแผนทีส่ ามารถลงมือทําได้จริงการทําแบบนี้จะทําให้เกิดการทํางานทีโ่ ฟกัสและได้พฒั นาการบริหารจัดการตนเอง (Self-Management) ในทีมขึน้ มาได้
การประชุม Daily Scrum ช่วยทําให้การสือ่ สารดีขน้ึ ช่วยชีใ้ ห้เห็นปั ญหาในการทํางาน ทําให้เกิดการตัดสินใจทีเ่ ร็วขึน้
และลดการประชุมทีไ่ ม่จาํ เป็ นลงในการปรับแผนการทํางานไม่ควรรอทําใน Daily Scrum เท่านัน้สมาชิกของทีมสามารถทีจ่ ะพูดคุยเพือ่ ปรับเปลีย่ นการทํางานหรือแม้แต่วางแผนการทํางานใหม่สาํ หรับงานทีเ่ หลือได้ตลอดเ
วลาทีท่ าํ งานด้วยกัน

Sprint Reviewจุดประสงค์ของการทํา Sprint Review คือให้ทมี ตรวจสอบผลลัพธ์จากการทํางานร่วมกันใน Sprint (รอบการทํางาน)ทีผ่ า่ นมา จากนัน้ กําหนดการปรับปรุงแก้ไขสําหรับการทํางานในอนาคต โดยให้ Scrum Teamได้นําเสนอผลลัพธ์ของงานต่อผูท้ เ่ี กีย่ วข้องทุกคนได้รบั รู้ แล้วมีการพูดคุยถึงความคืบหน้าของการทํางานเมือ่ เทียบกับProduct Goal (เป้ าหมายของการทําผลิตภัณฑ์)ในระหว่างการประชุมนี้ Scrum Team และผูม้ สี ว่ นเกีย่ วข้องทุกคนได้ทาํ การทบทวนว่าทีมได้ทาํ อะไรเสร็จไปแล้วบ้างมีอะไรเปลีย่ นแปลงไปไหมในการทํางานทีผ่ า่ นมา จากนัน้ ทําการพูดคุยว่าจะทําอย่างไรต่อ Product Backlog(ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม)อาจจะต้องมีการปรับเปลีย่ นให้สอดคล้องกับโอกาสทางธุรกิจ การประชุม Sprint Reviewนี้ยงั ถือว่าเป็ นการทํางานอยูด่ งั นัน้ จะไม่ดาํ เนินการประชุมนี้แบบการนําเสนองาน
กิจกรรม Sprint Review ใช้เวลาไม่เกิน 4 ชัวโมงสํ่
าหรับ Sprint (รอบการทํางาน) ทีม่ คี วามยาวหนึ่งเดือน ถ้าความยาวของSprint สัน้ กว่านี้ เวลาในการทํา Sprint Review ก็ควรทีจ่ ะใช้เวลาให้น้อยลง

11

Sprint Retrospectiveจุดประสงค์ของการทํา Sprint Retrospective คือเพิม่ คุณภาพและประสิทธิภาพในการทํางานของทีมScrum Team ทําการตรวจสอบโดยการสอบถามสมาชิกแต่ละคนถึงปฏิสมั พันธ์ภายในทีม กระบวนการและเครือ่ งมือต่าง ๆในการทํางานและ Definition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์) ใน Sprint (รอบการทํางาน) ทีผ่ า่ นมาหัวข้อทีน่ ํามาตรวจสอบหรือพูดคุยก็ขน้ึ อยูก่ บั ลักษณะของงาน
มีการพูดคุยถึงเหตุการณ์ทเ่ี กิดขึน้ และหาสาเหตุของเหตุการณ์เหล่านัน้ ซึง่ Scrum Teamจะพูดคุยกันว่ามีสงิ่ ไหนทีท่ าํ ให้เกิดการทํางานทีด่ บี า้ ง ทางทีมมีปัญหาอะไรบ้างในการทํางาน
แล้วทีมได้ทาํ การแก้หรือไม่แก้ปัญหาเหล่านัน้ อย่างไรScrum Team ช่วยกันกําหนดวิธกี ารแก้ไขปั ญหาเพือ่ ให้เกิดการปรับปรุงและเพิม่ ประสิทธิภาพในการทํางาน Scrum Teamควรระบุถงึ ปั ญหาทีเ่ กิดขึน้ ให้เร็วทีส่ ดุ แล้วนําไปกําหนดวิธกี ารแก้ไข โดยการนําไปใส่ใน Sprint Backlog
เพือ่ ดําเนินการทันทีใน Sprint (รอบการทํางาน) ถัดไปSprint Retrospective ถือเป็ นกิจกรรมหนึ่งใน Sprint (รอบการทํางาน) ใช้เวลาไม่เกิน 3 ชัวโมงสํ่
าหรับ Sprintทีม่ คี วามยาวหนึ่งเดือน ถ้าความยาวของ Sprint สัน้ กว่านี้ เวลาในการทํา Sprint Retrospective ก็ควรทีจ่ ะใช้เวลาให้น้อยลงScrum Artifacts
Artifacts คือผลลัพธ์ทไ่ี ด้จากการทํางานแบบ Scrum แสดงให้เห็นถึงงานหรือมูลค่าของงานทีเ่ กิดขึน้ Artifactsทําให้เกิดความโปร่งใสขัน้ สูงสุดของข้อมูลทีม่ คี วามสําคัญต่อการทํางานดังนัน้ ทุกคนทีม่ หี น้าทีต่ อ้ งตรวจสอบจะอยู่บนพืน้ ฐานข้อมูลเดียวกันเพือ่ นําไปพิจารณาปรับปรุงแก้ไขสิง่ ต่าง ๆในการทํางานArtifact (ผลลัพธ์ทไ่ี ด้จากการทํางานแบบ Scrum)แต่ละประเภทประกอบไปด้วยข้อมูลทีส่ าํ คัญทีเ่ ป็ นข้อมูลทีจ่ าํ เป็ นทีท่ าํ ให้เกิดความโปร่งใสการทุ่มเทในการทํางานเพือ่ ให้การทํางานนัน้ สามารถตรวจสอบได้ Artifact มีอยูส่ ามประเภท แต่ละประเภทมีขอ้ กําหนดดังนี้•••Product Backlog ต้องมีการกําหนด Product Goal หรือเป้ าหมายของผลิตภัณฑ์Sprint Backlog ต้องมีการกําหนด Sprint Goal หรือเป้ าหมายในการทํางานในรอบ Sprint นัน้ ๆIncrement ต้องมีการกําหนด Definition of Done หรือมาตรฐานของงานทีเ่ สร็จสมบูรณ์Product Backlog
Product Backlog คือทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม Product Backlog
เป็ นข้อมูลแหล่งเดียวเท่านัน้ ของการทํางานของ Scrum Team12

Product Backlog Items คือความต้องการของลูกค้าและรายการงานทีต่ อ้ งทําทีมควรทีจ่ ะทําความเข้าใจด้วยการพูดคุยกันในรายละเอียด มีการเรียงลําดับงานชิน้ ไหนทีค่ วรทําก่อนหลังมีการพูดคุยกันถึงเรือ่ งขนาดของงานหรือความยากง่ายของงานโดยขนาดของงานควรมีการย่อยให้มขี นาดเล็กพอประมาณทีจ่ ะทําเสร็จได้ภายในรอบการทํางานใน Sprintถัดไปการพูดคุยกันภายในทีมเกีย่ วกับในเรื่องนี้จะทําได้บ่อยแค่ไหนขึน้ อยูก่ บั ลักษณะของงานDevelopers ในทีมมีหน้าทีก่ าํ หนดขนาดหรือความยากง่ายของงาน ส่วน Product Owner ช่วยทําให้ Developersเข้าใจในเนื้อหาของงานและอาจจะมีการปรับเปลีย่ นเนื้องานได้Commitment: Product Goal

Product Goal คือเป้ าหมายของผลิตภัณฑ์ อธิบายถึงอนาคตของผลิตภัณฑ์หรืองานที่ Scrum Team กําลังทําอยู่
ทีมจะได้รวู้ า่ ควรจะวางแผนงานอย่างไรให้สามารถทํางานได้ตามเป้ าหมายทีว่ างไว้ โดยที่ Product Goal เป็ นส่วนหนึ่งของProduct Backlog (ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม)ทีป่ ระกอบไปด้วยความต้องการของลูกค้าหรืองานทีท่ มี จะต้องทําเพือ่ ให้บรรลุตาม Product Goalตัวผลิตภัณฑ์คอื ตัวแทนของการส่งมอบคุณค่า ตัวผลิตภัณฑ์มขี อบเขตทีช่ ดั เจนรูว้ า่ ใครคือผูท้ เี ่ กีย่ วข้องทัง้ หมดไม่วา่ จะเป็นผูใ้ ช้ หรือลูกค้าของผลิตภัณฑ์ดงั กล่าวตัวผลิตภัณฑ์สามารถเป็นได้ทงั ้ งานบริการ สิง่ ของทีจ่ บั ต้องได้หรือสิง่ ทีเ่ ป็ นนามธรรมก็ได้
Product Goal (เป้ าหมายของผลิตภัณฑ์) เป็ นเป้ าหมายระยะยาวทีม่ เี พียงข้อเดียวที่ Scrum Teamจะต้องทําให้บรรลุหรือแม้แต่ยกเลิก ก่อนทีจ่ ะไปทํางานให้บรรลุเป้ าหมายใหม่

Sprint Backlog
Sprint Backlog ประกอบไปด้วย Sprint Goal (เป้ าหมายในการทํางานในรอบ Sprint นัน้ ๆ) ทีจ่ ะบอกเราว่าทําไม (Why)เราต้องทํางานเหล่านี้ Sprint Backlog ยังประกอบไปด้วยความต้องการของลูกค้าหรืองานทีเ่ ราจะเลือกมาทํา ซึง่ ก็คอื อะไร(What) นันเอง่และยังมีวธิ กี ารทํางานทีจ่ ะทําให้เราสร้างผลิตภัณฑ์ทม่ี มี ลู ค่าขึน้ มาได้ นันก็่ คอื อย่างไร (How)Sprint Backlog คือแผนงานที่ Developers ทําขึน้ มาเพือ่ Developers เอง Sprint Backlog
ทําให้เห็นภาพงานทีจ่ ะต้องทําได้อย่างชัดเจนและอัพเดทตามสถานการณ์จริงเพือ่ ให้ Developersสามารถทีจ่ ะทํางานให้บรรลุตาม Sprint Goal ตลอดระยะเวลาในการทํางานในรอบ Sprint นัน้ Sprint Backlog
ต้องมีการอัพเดทอยูต่ ลอดเวลา และมีรายละเอียดมากพอทีจ่ ะทําให้ทมี สามารถทีจ่ ะตรวจสอบความคืบหน้าผ่านกิจกรรมDaily Scrum ได้Commitment: Sprint Goalใน Sprint หรือการทํางานรอบหนึ่ง ๆ จะมี Sprint Goal (เป้ าหมายในการทํางานในรอบ Sprint นัน้ ๆ) เพียงข้อเดียวเท่านัน้
ถึงแม้วา่ Sprint Goal เป็ นคํามันสั่ ญญาทีถ่ ูกกําหนดขึน้ โดย Developers ตัว Sprint Goal
13เองก็มคี วามยืดหยุน่ พอสมควรทีจ่ ะมีการปรับเปลีย่ นงานทีต่ อ้ งทําเพื่อให้บรรลุเป้ าหมาย Sprint Goalทําให้เกิดภาพความเชือ่ มโยง การมุง่ เน้น ทุ่มเทกับการทํางาน กระตุน้ ให้ Scrum Teamร่วมมือกันทํางานมากกว่าทีจ่ ะทํางานแบบตัวใครตัวมันตอนทีท่ าํ กิจกรรม Sprint Planning จะมีการกําหนด Sprint Goal (เป้ าหมายในการทํางานในรอบ Sprint นัน้ ๆ)ขึน้ แล้วนําไปไว้ใน Sprint Backlog ตอนที่ Developers ร่วมกันทํางานในระหว่าง Sprint (รอบการทํางาน)พวกเขาควรทีจ่ ะคํานึงถึง Sprint Goal อยูต่ ลอดเวลา ถ้าระหว่างทีท่ าํ งานอยูน่ นั ้ พบว่างานทีไ่ ด้ออกมาไม่ได้ตามทีค่ าดหวัง
พวกเขาควรทีจ่ ะพูดคุยกับ Product Owner เพือ่ ปรับงานทีท่ าํ อยูใ่ น Sprint Backlog โดยไม่ทาํ ให้เกิดผลกระทบต่อ Sprint
GoalIncrement
Increment คือผลลัพธ์จากการทํางานในแต่ละ Sprint ทีท่ าํ ให้การทํางานบรรลุตาม Product Goal (เป้ าหมายผลิตภัณฑ์) ได้โดยทีแ่ ต่ละ Increment ทีส่ ะสมมาเรือ่ ย ๆ จาก Sprint ก่อนหน้านี้ได้รบั การทดสอบแล้วว่าสามารถทีจ่ ะทํางานร่วมกันได้นันหมายถึ่
ง Increment จะสร้างมูลค่าในตัวมันเองได้กต็ ่อเมือ่ Increment นัน้ ๆ สามารถถูกนําไปใช้งานได้จริง
ในหนึ่ง Sprint อาจจะเกิด Increment (ผลลัพธ์จากการทํางานในแต่ละ Sprint) ขึน้ ได้หลายชิน้ การรวบรวม Incrementจะทําขึน้ ตอนทํา Sprint Review อย่างไรก็ตาม Increment หนึ่ง ๆสามารถนําไปส่งมอบให้กบั ผูม้ สี ว่ นเกีย่ วข้องได้เลยโดยทีไ่ ม่ตอ้ งรอให้จบ Sprint ก่อน ซึง่ การประชุม Sprint Reviewไม่ได้ถกู ทําให้เกิดขึน้ เพือ่ เป็ นการส่งมอบผลิตภัณฑ์ให้กบั ลูกค้าความต้องการของลูกค้าหรืองานทีย่ งั ทําไม่เสร็จจะไม่ถอื ว่าเป็ น Increment (ผลลัพธ์จากการทํางานในแต่ละ Sprint)ถ้าสิง่ นัน้ ไม่ได้ผา่ น Definition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์)Commitment: Definition of Done

Definition of Done หรือมาตรฐานของงานทีเ่ สร็จสมบูรณ์ คือคําอธิบายว่า Increment (ผลลัพธ์จากการทํางานในแต่ละSprint) ได้ผา่ นมาตรฐานคุณภาพทีจ่ าํ เป็ นสําหรับผลิตภัณฑ์หรือไม่ถ้าชิน้ งานดังกล่าวนัน้ ผ่านมาตรฐานคุณภาพแล้ว เราจึงจะเรียกชิน้ งานนัน้ ว่า Increment (ผลลัพธ์จากการทํางานในแต่ละSprint)
Definition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์)ทําให้ทุกคนได้รบั รูร้ ว่ มกันว่าชิน้ งานแบบไหนถือว่าเสร็จสมบูรณ์สามารถทีจ่ ะกลายเป็ น Increment(ผลลัพธ์จากการทํางานในแต่ละ Sprint) ได้ ถ้า Product Backlog Items (ความต้องการของลูกค้าและรายการงานทีต่ อ้ งทํา)ไม่ผา่ นมาตรฐานคุณภาพตาม Definition of Done จะไม่ถูกนํามาเสนอในกิจกรรม Sprint Reviewแต่จะถูกนํากลับไปรวมและถูกพิจารณาใหม่ใน ProductBacklog (ทีอ่ ยูข่ องความต้องการของลูกค้าและสิง่ ทีจ่ ะต้องปรับปรุงแก้ไขเพิม่ เติม)14ถ้า Definition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์) ของ Increment (ผลลัพธ์จากการทํางานในแต่ละ Sprint)ได้รบั การกําหนดตามมาตรฐานขององค์กร Scrum Team ทัง้ หมดควรทีจ่ ะปฏิบตั ติ ามมาตรฐานเหล่านัน้ เป็ นขัน้ พืน้ ฐานหากองค์กรไม่ได้มมี าตรฐานรองรับทาง Scrum Team จะต้องกําหนด Definition of Doneให้เหมาะสมกับผลิตภัณฑ์ดว้ ยตนเองDevelopers ทุกคนต้องปฏิบตั ติ าม Definition of Done (มาตรฐานของงานทีเ่ สร็จสมบูรณ์) หากมี Scrum Teamหลายทีมทํางานร่วมกันเพือ่ สร้างผลิตภัณฑ์ชน้ิ เดียวกัน ทีมเหล่านัน้ ควรทีจ่ ะกําหนดร่วมกันและปฏิบตั ติ าม Definition ofDone เดียวกัน15End NoteScrum ทีน่ ําเสนอในคูม่ อื เล่มนี้เป็ นของฟรี Scrum เป็ นรูปแบบหรือกรอบในการทํางานทีผ่ นู้ ําไปใช้ไม่พงึ ดัดแปลงใด ๆถ้าการนําเอา Scrum ไปใช้เพียงบางส่วนเท่านัน้ ผลทีไ่ ด้ออกมาไม่ถอื ว่าเป็ นผลลัพธ์ทม่ี าจาก Scrumผลลัพธ์ทน่ี บั ว่าเป็ นผลลัพธ์จากรูปแบบการทํางานแบบ Scrumได้กต็ ่อเมือ่ ได้นําเอาแนวคิดทัง้ หมดทีอ่ ยูใ่ นคูม่ อื เล่มนี้ไปใช้แล้วอาจจะเพิม่ เทคนิค วิธกี ารหรือแนวปฏบัตอิ ่นื ๆมาร่วมด้วยได้

Acknowledgements
Peopleขอขอบคุณผูค้ นมากมายทีไ่ ด้มสี ว่ นร่วมในการทําให้ Scrum เกิดขึน้ ผูท้ ไ่ี ด้รว่ มกันทํางานแบบ Scrum ทํามาตัง้ แต่แรก ๆ
คือ Jeff Sutherland ทีไ่ ด้ทาํ งานร่วมกับ Jeff McKenna และ John Scumniotalesl ส่วน Ken Schwaber ได้รว่ มงานกับMike Smit และ Chris Martin และขอขอบคุณผูค้ นอีกมากมายทีไ่ ด้รว่ มมือกันนําเอา Scrum ไปใช้ ถ้าขาดผูค้ นเหล่านี้Scrum คงไม่ได้รบั การเรียบเรียงและแก้ไขเป็ นฉบับปั จจุบนั นี้ได้Scrum Guide History

Ken Schwaber และ Jeff Sutherland ได้รว่ มกันนําเสนอเรือ่ ง Scrum เป็ นครัง้ แรกในงานประชุม OOPSLA ในปี 1995พวกเขาได้บอกเล่าถึงสิง่ ทีไ่ ด้เรียนรูแ้ ละได้รบั ประโยชน์อะไรบ้างจากการทํางานในรูปแบบ Scrumคูม่ อื Scrum ได้รบั การปรับปรุงเรือ่ ยมาเป็ นระยะกว่า 30 ปี แล้วโดย Jeff Sutherland และ Ken Schwaberความรูจ้ ากแหล่งอื่น ๆ ไม่วา่ จะเป็ น รูปแบบ กระบวนการทํางานและความรูต้ ่าง ๆ มีสว่ นทําให้รปู แบบการทํางานแบบScrum มีความสมบูรณ์มากยิง่ ขึน้ และอาจจะนําไปสูก่ ารเพิม่ ผลผลิต มูลค่า ความคิดสร้างสรรค์และความพึงพอใจของผูท้ ม่ี สี ว่ นเกีย่ วข้องประวัตศิ าสตร์ของ Scrum ฉบับเต็มได้ได้รบั การเขียนไว้ในแหล่งอื่น เพือ่ เป็ นการให้เกียรติกบั องค์กรทีไ่ ด้นําเอา Scrumไปใช้และพิสจู น์ความคิดนี้เป็ นทีแ่ รกคือ Newspage, Fidelity Investments และ IDX (ปั จจุบนั คือ GE Medical)
Translator and Editors Acknowledgementคูม่ อื เล่มนี้ได้รบั การแปลจากต้นฉบับเป็ นภาษาไทย โดยมีผแู้ ปลและร่วมกันแก้ไขดังนี้
- ดามพ์ มงคล หงษ์ชยั (Dahm Mongkol Hongchai)- พิชยา เกษมสันต์ ณ อยุธยา (Pichaya Kashemsanta Na Ayudhya)- ปริญพัชร์ วัตธนเรืองกิตต์ (Prinyaphat Watthanarungkhitt)- ธิดา สัญญปรีดากุล (Tida Sunyapredakul)16-สุทศั น์ พรธีระปกรณ์ (Suthat Porntheerapakorn)ดร.ศิวภากร ธนาธิวฒั น์ (Siwapakorn Dhanadhiwat)

Changes from 2017 Scrum Guide to 2020 Scrum Guideข้อกําหนดตายตัวทีล่ ดลงในหลาย ๆ ปี ทผ่ี า่ นมา เนื้อหาในคูม่ อื Scrum จะมีขอ้ กําหนดต่าง ๆ เพิม่ มากขึน้ เรือ่ ย ๆ แต่ค่มู อื Scrum 2020ผูแ้ ต่งได้พยายามทําให้เนื้อหาเข้าใจง่าย เมือ่ นําไปใช้แล้วทําให้เกิดประสิทธิภาพ มีการถอดเนื้อหาบางส่วนออก เช่นคําถามทีใ่ ช้ใน Daily Scrum การใช้ภาษาสําหรับอธิบายคําจํากัดความของ PBI (Product Backlog Item),ภาษาทีใ่ ช้ในการอธิบาย Sprint Backlog รวมไปถึงทําให้หวั ข้อการยกเลิก Sprint มีความกระชับมากขึน้ และมีอกี หลาย ๆหัวข้อได้รบั การแก้ไขให้ดขี น้ึหนึง่ ทีมทุ่มเทให้กบั หนึง่ ผลิตภัณฑ์วัตถุประสงค์ของข้อนี้คอื เพื่อไม่ให้มที มี เล็กทีมน้อยซ้อนอยูใ่ นทีมใหญ่ทท่ี าํ ให้เกิดพฤติกรรมการแบ่งพรรคแบ่งพวกระหว่าง
Product Owner และทีมของ Developers ดังนัน้ เมือ่ ทํางานสร้างผลิตภัณฑ์เดียวกันทุกคนจะได้มงุ่ มันให้่ กบั วัตถุประสงค์เดียวกัน โดย Scrum Team มีสามบทบาทคือ Product Owner, Scrum Master และDevelopersเพิม่ Product Goal เข้ามาคูม่ อื Scrum 2020 ได้นําเพิม่ Product Goal (เป้ าหมายผลิตภัณฑ์) เข้ามาเพื่อให้ Scrum Team ได้ทุ่มเทให้เวลาเต็มทีก่ บั การทํางานทีจ่ ะนําไปสูก่ ารบรรลุวตั ถุประสงค์การสร้างมูลค่าให้กบั ผลิตภัณฑ์ทเ่ี พิม่ มากขึน้ เรื่อย ๆโดยทีแ่ ต่ละ Sprint (รอบการทํางาน) ทีมทําให้เกิดผลลัพธ์เข้าใกล้กบั เป้ าหมายสุดท้ายของผลิตภัณฑ์ข้อกําหนดเกีย่ วกับ Sprint Goal, Definition of Done และ Product Goalคูม่ อื Scrum ในฉบับทีผ่ า่ นมาอธิบายถึง Sprint Goal (เป้ าหมายของการทํางานในรอบนัน้ ๆ) และ Definition of Done(มาตรฐานของงานทีเ่ สร็จสมบูรณ์) ได้ยงั ไม่ชดั เจน แม้วา่ Sprint Goal และ Definition of Done ไม่ใช่ Artifacts(ผลลัพธ์ทไ่ี ด้จากการทํางานแบบ Scrum) แต่มคี วามเชือ่ มโยงกับ Artifacts เมือ่ คูม่ อื Scrum 2020 เพิม่ Product Goal(เป้ าหมายผลิตภัณฑ์) เข้ามา ทําให้ Artifacts แต่ละตัวมีขอ้ กําหนดเกิดขึน้ มาคือ Product Backlog มี Product Goal, Sprint
Backlog มี Sprint Goal และ Increment มี Definition of Doneสิง่ เหล่านี้ทาํ ให้เกิดความโปร่งใสและการทุม่ เทในการทํางานSelf-Managing เข้ามามีบทบาทเหนือ Self-Organizing

17คูม่ อื Scrum ในฉบับทีผ่ า่ นมาได้พดู ถึงว่า Scrum Team มีลกั ษณะแบบ Self-Organizingทีส่ มาชิกเลือกชิน้ งานทีจ่ ะทําด้วยตนเองและตัดสินใจเองว่าจะทํางานนัน้ อย่างไร แต่ในคูม่ อื Scrum 2020 ได้พดู ถึง SelfManaging ที่ Scrum Team นอกจากเลือกชิน้ งานทีจ่ ะทําด้วยตนเองและตัดสินใจเองว่าจะทํางานนัน้ อย่างไรยังสามารถเลือกได้วา่ จะทํางานอะไรได้ดว้ ยการทํา Sprint Planning มี 3 หัวข้อ
การทํา Sprint Planning ในคูม่ อื เล่มเดิมนัน้ พูดแค่ 2 หัวข้อคือ What (งานอะไรทีต่ อ้ งทํา) และ How (ทํางานนัน้ อย่างไร)ส่วนทีเ่ พิม่ เติมในคูม่ อื Scrum 2020 คือ Why (ทําไมต้องทํางานนัน้ ) ทีอ่ า้ งอิงกับ Sprint Goal นันเอง่ภาษาทีใ่ ช้เข้าใจง่ายภาษาทีใ่ ช้ในคูม่ อื Scrum 2020 เป็ นภาษาทีเ่ ข้าใจง่ายเหมาะกับผูท้ ส่ี นใจทีไ่ ม่ได้มาจากวงการไอทีดังนัน้ บางคําศัพท์ทม่ี คี วามซํ้าซ้อนและซับซ้อนจึงถูกตัดออกไป เช่น Testing (การทําสอบ), System (ระบบ), Design(การออกแบบ), Requirement (ความต้องการของลูกค้า) และ อื่น ๆ ทําให้คมู่ อื เล่มนี้มเี พียง 13 หน้าเท่านัน้18