Scrum ฉบับภาษาไทย

1. คู่มือสกรัม™
คู่มือการทางานแบบสกรัม
กฏแห่งเกม
ตุลาคม 2554
เขียนและปรับปรุงโดย เคน ชวาเบอร์ และ เจฟ ซัทเธอร์แลนด์

2. สารบัญ
©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
summary form at http://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. หน้า | 2
จุดประสงค์ของคู่มือสกรัม....................................................................................................... 3
ภาพรวมของสกรัม ................................................................................................................ 3
แบบแผนการทางานของสกรัม.............................................................................................. 3
หลักการสกรัม...................................................................................................................... 4
สกรัม................................................................................................................................. 6
สกรัมทีม ............................................................................................................................ 6
เจ้าของผลิตภัณฑ์ ............................................................................................................. 6
ทีมพัฒนาซอฟท์แวร์.......................................................................................................... 7
สกรัมมาสเตอร์.................................................................................................................. 8
เหตุการณ์สกรัม.................................................................................................................... 9
สปรินท์..........................................................................................................................10
การยกเลิกสปรินท์ ............................................................................................................10
การประชุมวางแผนสปรินท์ .................................................................................................11
สกรัมประจาวัน.................................................................................................................12
การประเมินสปรินท์...........................................................................................................13
การพิจารณาสปรินท์ที่ผ่านมา ..............................................................................................14
สกรัมอาติแฟก ....................................................................................................................15
โปรดักแบ็กล็อก...............................................................................................................15
สปรินท์แบ็กล็อก ..............................................................................................................17
อินครีเม ้นท์.....................................................................................................................18
นิยามของคาว่า “เสร็จสมบูรณ์” ...............................................................................................19
บทสรุป .............................................................................................................................19
คาขอบคุณ.........................................................................................................................20
บุคคลสาคัญ ...................................................................................................................20
ประวัติ ...........................................................................................................................20

3. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 3
จุดประสงค์ของคู่มือสกรัม
สกรัม คือ แบบแผนการทางาน ที่นามาใช ้เพื่อพัฒนาและสนับสนุนผลิตภัณท์ที่มีความซับซ ้อน คู่มือนี้
อธิบาย ความหมายของคาว่า สกรัม ซึ่งประกอบไปด ้วย บทบาทในสกรัม เหตุการณ์ อาติแฟต และ
กฏข ้อบังคับ โดยกฏข ้อบังคับนี้จะเป็นตัวเชื่อมโยงองค์ประกอบเหล่านี้เข ้าด ้วยกัน ผู้คิดค ้นสกรัม เคน
ชวาเบอร์ และ เจฟ ซัทเธอร์แลนด์ ได ้เขียนและสนับสนุนแนวทางของคู่มือนี้
ภาพรวมของสกรัม
สกรัม (คานาม): แบบแผนการทางานที่สามารถช่วยให ้ผู้ที่เกี่ยวข ้อง
จัดการปัญหาที่ซับซ ้อนในการทางานได ้ โดยที่ยังสามารถส่งมอบงานได ้อย่างมีประสิทธิภาพ และ
สร้างสรรค์ ซึ่งก่อให ้เกิดประโยขน์สูงสุด สกรัม คือ
 กระชับ
 เข ้าใจง่าย
 ยากที่จะเป็นผู้เชี่ยวชาญ
สกรัม เป็น แบบแผนการทางานที่ถูกนามาใช ้ตั้งแต่ต ้นปี 1990 เพื่อบริหารจัดการ การพัฒนาผลิตภัณท์
ที่ซับซ ้อน สกรัมไม่ใช่เป็นกระบวนการทางาน หรือ เทคนิค ในการสร้างผลิตภัณท์
แต่มันเป็นแบบแผนการทางานที่จะช่วยให ้สามารถ นากระบวนการและเทคนิคต่างๆ มาใช ้
สกรัมจะชี้ให ้เห็นอย่างชัดเจนว่าการบริหารจัดการและวิธีปฏิบัติงานมีประสิทธิภาพมากน้อยเพียงใด
เพื่อสามารถปรับปรุงการทางานให ้ดีขึ้นได ้
แบบแผนการทางานของสกรัม
แบบแผนการทางานของสกรัม ประกอบด ้วย คนในทีม, บทบาทของคนในทีม, เหตุการณ์, อาติแฟต, และ
กฏแต่ละองค์ประกอบเหล่านี้ มีวัตถุประสงค์เฉพาะ และ สาคัญต่อความสาเร็จของการนาสกรัมไปใช ้
กลยุทธ์เฉพาะ ของการนาสกรัมไปใช ้มีความหลากหลาย ซึ่งจะอธิบายในหัวข ้อต่อไป
กฏของสกรัม จะเป็นตัวเชื่อมโยง เหตุการณ์ บทบาท และ อาติแฟตทั้งหมดเข ้าด ้วยกัน
เพื่อควบคุมความสัมพันธ์ และ ปฏิสัมพันธ์ของทุกองค์ประกอบไว ้
โดยกฏของสกรัมทั้งหมดถูกอธิบายไว ้ในเนื้อหาของคู่มือนี้

4. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 4
หลักการสกรัม
สกรัมถูกค ้นพบจากประสบการณ์การจัดการ หรือการทดลองนามาประยุกต์ใช ้
จากการทดลองยืนยันว่าความรู้ ความเข ้าใจ มาจากประสบการณ์และการตัดสินใจบนพื้นฐานของสิ่งที่รู้
สกรัมใช ้วิธีการเพิ่มผลิตผลแบบซ้าๆ เพื่อที่จะปรับปรุงการคาดการณ์ล่วงหน้าและจากัดความเสี่ยง
มี 3 หลักการ ที่สนับสนุนการปฏิบัติงาน ที่นามาจากประสบการณ์ในการจัดการ ดังนี้ การเปิดเผย,
การตรวจสอบ และการแก ้ไขปรับปรุง
การเปิดเผย
ลักษณะสาคัญของกระบวนการ ต ้องแสดงให ้เห็นถึงความรับผิดชอบต่อผลลัพธ์อย่างชัดเจน การเปิดเผย
กาหนดให ้ระบุบกระบวนการในด ้านต่างๆ ด ้วยมาตรฐานที่ชัดเจน
ซึ่งผู้สังเกตการณ์สามารถอธิบายด ้วยความเข ้าใจต่อสิ่งที่เห็น
ตัวอย่าง
 มาตรฐานของ คาศัพท์หรือภาษาทั่วไป จะเชื่อมโยงถึงกระบวนการที่ใช ้ร่วมกันทุกคน
 มาตรฐานของ นิยามของคาว่า “เสร็จสมบูรณ์” 1
จะต ้องเข ้าใจตรงกันระหว่างคนทางานกับผู้ตรวจรับงาน
การตรวจสอบ
ผู้ใช ้สกรัมต ้องตรวจสอบ สกรัมอาติแฟกต์ และ สถานะความเข ้าใกล ้ความสาเร็จของเป้าหมาย
อย่างสม่าเสมอ เพื่อที่จะตรวจสอบการเปลี่ยนแปลงที่ไม่พึงปรารถนา
การตรวจสอบเหล่านั้นไม่ควรจะต ้องเกิดขึ้นบ่อย จนทาให ้การตรวจสอบมาเป็นตัวขัดขวางการทางาน
การตรวจสอบจะมีประโยชน์มากที่สุด
เมื่อดาเนินการอย่างขยันขันแข็งโดยผู้ตรวจที่มีความเชี่ยวชาญดาเนินการอย่างใกล ้ชิด
การแก้ไขปรับปรุง
ถ ้าผู้ตรวจสอบระบุ กระบวนการทางานที่คลาดเคลื่อนไม่ตรงตามที่กาหนดไว ้ หนึ่งอย่างหรือมากกว่า
และผลลัพธ์จะไม่เป็นไปตามข ้อกาหนด
กระบวนการหรือส่วนประกอบที่ได ้ดาเนินการไปแล ้วต ้องถูกปรับเปลี่ยน
การปรับเปลี่ยนต ้องรีบดาเนินการทันทีเพื่อลดความคลาดเคลื่อนในอนาคต
สกรัมแนะนา 4 หลักเกณฑ์เพื่อการตรวจสอบและการแก ้ไขปรับปรุง ที่จะถูกอธิบายในหัวข ้อ
เหตุการณ์สกรัม ของคู่มือนี้
 การประชุมการวางแผนสปรินท์
 สกรัมประจาวัน
 การประเมินสปรินท์
1
ดู นิยามของคาว่า “เสร็จสมบูรณ์” หน้า 15

5. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 5
 การพิจารณาสิ่งที่ผ่านมาสปรินท์

6. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 6
สกรัม
สกรัม คือ รูปแบบสาหรับการพัฒนาซอฟท์แวร์ที่ซับซ ้อน สกรัม ซึ่งประกอบไปด ้วย สกรัมทีม และ
ความเกี่ยวข ้องกับ บทบาท เหตุการณ์ อาติแฟต และกฏข ้อบังคับ
แต่ละส่วนประกอบในแบบแผนการทางานตอบโจทย์วัตถุประสงค์ที่เฉพาะเจาะจงและเป็นส่วนสาคัญต่อคว
ามสาเร็จของสกรัมและการใช ้งาน
สกรัมทีม
สกรัมทีม ประกอบด ้วย เจ้าของผลิตภัณฑ์ ทีมพัฒนาซอฟท์แวร์ และ สกรัมมาสเตอร์ สกรัมทีมเป็นทีมที่
ทางานแบบบริหารจัดการด ้วยตัวเอง รวมถึง การทางานแบบหลากหลายหน้าที่
การบริหารจัดการด ้วยตัวเอง
ทีมจะเลือกวิธีที่ดีที่สุดสาหรับการทางานเพื่อให ้สาเร็จตามเป้าหมายมากกว่าที่จะกาหนดจากภายนอก
การทางานหลากหลายหน้าที่
เป็นสิ่งจาเป็นที่จะทางานให ้สาเร็จลุล่วงโดยไม่จาเป็นที่จะต ้องพึ่งพาจากทีมอื่นๆภายนอกสกรัมทีม
รูปแบบของสกรัมทีม ออกแบบเพื่อให ้มีความยืดหยุ่นของการทางาน ความคิดสร้างสรรค์
และผลผลิตสูงสุด
สกรัมทีมจะส่งมอบผลิตภัณฑ์แบบต่อเนื่อง และ เพิ่มมูลค่าของผลิตภัณฑ์
โดยเปิดโอกาสให ้มีการเสนอความคิดเห็นต่อผลิตภัณฑ์ให ้มากที่สุด
การส่งมอบผลิตภัณฑ์ที่สมบูรณ์และอย่างต่อเนื่องจะทาให ้เกิดมูลค่าและความมั่นใจต่อผลิตภัณฑ์
เจ้าของผลิตภัณฑ์
เจ้าของผลิตภัณฑ์ มีหน้าที่รับผิดชอบในการสร้างมูลค่าสูงสุดให ้แก่ผลิตภัณฑ์
และผลงานของทีมพัฒนาซอฟท์แวร์ โดยเกิดจากการทางานร่วมกันภายในองค์กร สกรัมทีม
และแต่ละบุคคล
เจ้าของผลิตภัณฑ์ เป็น ผู้เดียวที่รับผิดชอบในการจัดการโปรดักแบ็กล็อก ซึ่งการจัดการ โปรดักแบ็กล็อก
ประกอบไปด ้วย
 จัดการ โปรดักแบ็กล็อก ให ้มีความชัดเจน
 เรียงลาดับความสาคัญของโปรดักแบ็กล็อกแต่ละรายการ เพื่อตอบสนองต่อเป้าหมายสูงสุด
 ทาให ้มั่นใจว่า คุณค่าผลงานของทีมพัฒนาซอฟท์แวร์
 ทาให ้มั่นใจว่า โปรดักแบ็กล็อก มีความครบถ ้วนสมบูรณ์ โปร่งใส และแสดงให ้สกรัมทีมทราบว่า
รายการใด คือรายการอต่อไปที่จะพัฒนา และ
 ทาให ้มั่นใจว่า ทีมพัฒนาซอฟท์แวร์ มีความเข ้าใจเพียงพอในแต่ละรายการของโปรดักแบ็กล็อก
เจ้าของผลิตภัณฑ์ จะทางานที่กล่าวมาข ้างต ้น ทั้งหมดด ้วยตัวเอง
หรือจะให ้ทีมพัฒนาซอฟท์แวร์จัดการก็ได ้ แต่อย่างไรก็ตาม
ความรับผิดชอบยังคงอยู่กับเจ้าของผลิตภัณฑ์ เท่านั้น

7. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 7
เจ้าของผลิตภัณฑ์ คือ บุคคลใดบุคคลหนึ่งเท่านั้น มิใช่คณะบุคคล
แต่สามารถเป็นตัวแทนของคณะบุคคลในการจัดการโปรดักแบ็กล็อก
ซึ่งการเปลี่ยนแปลงลาดับความสาคัญในโปรดักแบ็กล็อก
จะต ้องได ้รับความเห็นชอบจากเจ้าของผลิตภัณฑ์เท่านั้น
เจ้าของผลิตภัณฑ์ ที่จะประสบความสาเร็จนั้น
ทางองค์กรต ้องเคารพในการตัดสินใจของเจ ้าของผลิตภัณฑ์
ซึ่งการตัดสินใจของเจ้าของผลิตภัณฑ์จะต ้องโปร่งใส ในรายละเอียดของเนื้อหา และ
เป็นไปตามลาดับความสาคัญของโปรดักแบ็กล็อก ทั้งไม่อนุญาติให ้ผู้อื่นบอกให ้ทีมพัฒนาซอฟท์แวร์
พัฒนารายการความต ้องการอื่นนอกเหนือโปรดักแบ็กล็อก และ ไม่อนุญาติให ้ทีมพัฒนาซอฟท์แวร์
ตอบสนองคาขอของผู้อื่นด ้วย
ทีมพัฒนาซอฟท์แวร์
ทีมพัฒนาซอฟท์แวร์ประกอบด ้วยผู้เชี่ยวชาญ ที่พัฒนาผลิตภัณฑ์ ที่จะสามารถส่งมอบอินครีเม ้นท์ของ
ผลิตภันณ์ที่ “เสร็จสมบูรณ์” ในช่วงท ้ายของแต่ละสปรินท์ สมาชิกของทีมพัฒนาซอฟท์แวร์เท่านั้น
ที่สามารถสร้าง อินครีเม ้น
ทีมพัฒนาซอฟท์แวร์ กาหนดโครงสร้าง และ เพิ่มขีดความสามารถด ้วยกันเป็นทีม
เพื่อกาหนดวิธีการทางานของตัวเอง ผลลัพท์ของการทางานร่วมกันเพื่อเพิ่มประสิทธิภาพทาให ้
ภาพโดยรวมของทีมพัฒนาซอฟท์แวร์ มีประสิทธิภาพและประสิทธิ์ผลสูงสุด ซึ่ง ทีมพัฒนาซอฟท์แวร์
จะต ้องมีลักษณะดังนี้
 เป็นทีมที่สามารถบริหารจัดการได ้ด ้วยตัวเอง
โดยที่ไม่มีใครสามารถกาหนดวิธีการพัฒนาโปรดักแบ็กล็อกไปเป็นอินครีเม ้นท์
ที่จะสามารถส่งมอบเป็นผลิตภัณฑ์ได ้
 ทีมพัฒนาซอฟท์แวร์ประกอบไปด ้วยบุคคลที่มีความหลากหลายหน้าที่
และมีความสามารถเพียงพอที่จะสร้างอินครีเม ้นท์
 สกรัม ตระหนักถึงการไม่กาหนดชื่อตาแหน่งงานอื่น นอกจากนักพัฒนาซอฟท์แวร์เท่านั้น
โดยไม่คานึงถึงการดาเนินงานของเฉพาะบุคคล และไม่มีข ้อยกเว ้นใดๆ สาหรับกฏข ้อบังคับนี้
 สมาชิกในทีมพัฒนาซอฟท์แวร์แต่ละคน อาจจะมีความสามารถเฉพาะทาง
และส่วนที่สนใจแตกต่างกัน แต่ทุกคนต่างรับผิดชอบร่วมกันเป็นทีม
 ทีมพัฒนาซอฟท์แวร์ ไม่อนุญาติให ้มีการแบ่งเป็นทีมย่อยๆ เช่น ทีมตรวจสอบ ทีมวิเคราะห์
ขนาดของทีมพัฒนาซอฟท์แวร์
ขนาดที่เหมาะสมที่สุดของทีมพัฒนาซอฟท์แวร์ จะต ้องมีขนาดเล็กเพื่อทางานได ้อย่างคล่องแคล่วว่องไว
แต่ต ้องใหญ่เพียงพอที่จะทางานให ้เสร็จลุล่วง ทีมที่มีจานวนสมาชิกน้อยกว่า 3
คนจะทาให ้ปฎิสัมพันธ์ในทีมน้อยและ ส่งผลให ้พัฒนาได ้แต่ผลิตภัณฑ์เล็กๆ ทีมที่มีขนาดน้อยกว่า 3 คน
อาจจะทาให ้เกิดข ้อจากัดด ้านทัักษะ ในระหว่างสปรินส์ ทาให ้ทีมพัฒนาซอฟท์แวร์
ไม่สามารถที่จะส่งมอบอินครีเม ้นท์ การมีจานวนสมาชิกมากกว่า 9
คนจะทาให ้มีเงื่อนไขในการทางานมากไป ทีมใหญ่กว่า 9 คนทาให ้เกิดความซับซ ้อนอย่างแน่นอน
ทั้งในวิธีการทางานและการจัดการ เจ้าของผลิตภัณฑ์ และ สกรัมมาสเตอร์

8. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 8
ไม่ถือว่าเป็นสมาชิกในทีมพัฒนาซอฟท์แวร์
นอกจากบุคคลนั้นจะสามารถพัฒนางานในสปรินท์แบ็กล็อกได ้เท่านั้น
สกรัมมาสเตอร์
สกรัมมาสเตอร์ มีหน้าที่สร้างความเข ้าใจและรับรองว่าทุกคนที่เกี่ยวข ้อง เข ้าใจการทางานแบบสกรัม โดย
สกรัมมาสเตอร์ จะปฎิบัติตาม ทฤษฎี แบบแผนการปฏิบัติ และ กฏข ้อบังคับ ซึ่งสกรัมมาสเตอร์
คือผู้นาแบบแผนการสกรัมให ้กับสกรัมทีม
นอกจากนั้น ยังช่วยให ้คนที่ไม่ได ้เป็นสมาชิกสกรัมทีม มีความเข ้าใจในการติดต่อสื่อสารกับคนในสกรัมทีม
ว่าการสื่อสารแบบใดทาให ้เกิดประโยชน์ และการสื่อสารแบบใดไม่ก่อให ้เกิดประโยชน์กับสกรัมทีม
สกรัมมาสเตอร์ ช่วยให ้ทุกคนปรับปรุงเปลี่ยนแปลงการสื่อสาร เพื่อก่อให ้เกิดประโยชน์สูงสุดกับสกรัมทีม

9. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 9
หน้าที่ของ สกรัมมาสเตอร์ ต่อเจ้าของผลิตภัณท์
สิ่งที่สกรัมมาสเตอร์ อานวยความสะดวกแก่ เจ้าของผลิตภัณท์ ประกอบไปด ้วย
 ค ้นหาเทคนิคเพื่อให ้การบริหารจัดการโปรดักแบ็กล็อกมีประสิทธิภาพ
 สื่อสารให ้กระจ่างกับทีมพัฒนาซอฟท์แวร์ ทั้งด ้าน วิสัยทัศน์ เป้าหมาย รายการโปรดักแบ็กล็อก
 สอนให ้สกรัมทีม สามารถสร้างรายการโปรดักแบ็กล็อก ที่กระชับและชัดเจน
 สร้างความเข ้าใจของการวางแผนผลิตภัณฑ์ระยะยาว ในสิ่งแว ้ดล ้อมที่ชัดเจน
 สร้างความเข ้าใจและฝึกฝนการนาอไจล์มาใช ้
 อานวยความสะดวกในเหตุการ์ณสกรัม ตามที่ร้องขอหรือจาเป็น
หน้าที่ของ สกรัมมาสเตอร์ ต่อทีมพัฒนาซอฟท์แวร์
สิ่งที่สกรัมมาสเตอร์ อานวยความสะดวกแก่ ทีมพัฒนาซอฟท์แวร์ ประกอบไปด ้วย
 ฝึกสอนทีมพัฒนาซอฟท์แวร์ให ้สามารถบริหารจัดการได ้ด ้วยตัวเอง
รวมถึงสามารถทางานได ้หลากหลายหน้าที่
 สอนและนาทีมพัฒนาซอฟท์แวร์เพื่อที่จะสร้างมูลค่าสูงสุดต่อผลิตภัณฑ์
 ขจัดอุปสรรคที่ขัดขวางการพัฒนาผลิตภัณฑ์ของทีมพัฒนาซอฟท์แวร์
 อานวยความสะดวกในเหตุการ์ณสกรัม ตามที่ร้องขอหรือจาเป็น
 ฝึกสอนทีมพัฒนาซอฟท์แวร์อื่นๆ
ภายในองค์กรที่ยังไม่ได ้ใช ้หลักการทางานและความเข ้าใจแบบสกรัมอย่างสมบูรณ์
หน้าที่ของ สกรัมมาสเตอร์ ต่อองค์กร
สิ่งที่สกรัมมาสเตอร์ อานวยความสะดวกแก่ องค์กร ประกอบไปด ้วย
 เป็นผู้นา และฝึกสอนองค์กรในการนาสกรัมไปใช ้
 วางแผนการนาสกรัมไปใช ้ภายในองค์กร
 ช่วยให ้พนักงานและผู้ที่เกี่ยวข ้องเข ้าใจ
และปฏิบัติตามกฏของสกรัมภายใต ้การพัฒนาอย่างต่อเนื่องของผลิตภัณท์
 ทาให ้เกิดการเปลี่ยนแปลงที่เพิ่มประสิทธิผล
 สิทธิภาพของการนาสกรัมไปใช ้ในองค์กร
เหตุการณ์สกรัม
การกาหนดเหตุการณ์ที่ระบุไว ้ใน เหตุการณ์สกรัม เพื่อสร้างความต่อเนื่องและสม่าเสมอ
เพื่อจะลดการประชุมที่ไม่ได ้ถูกระบุไว ้ในสกรัม สกรัมจะกาหนดช่วงของเวลาของเหตุการณ์ต่างๆ เช่น
กาหนดเหตุการณ์นั้นๆ ห ้ามใช ้เวลาเกินกว่าที่กาหนด เพื่อกาหนดให ้ใช ้เวลาที่สมควรในการวางแผนต่างๆ
โดยไม่อนุญาตให ้เสียเวลาวางแผนมากกว่าที่จาเป็น
นอกเหนือจาก สปรินท์จะเป็นช่วงเวลาที่รวบรวมเอาเหตุการณ์ต่างๆ ของสกรัมไว ้
แต่ละเหตุการณ์ในสกรัมนี้ยังเป็นสิ่งที่ต ้องปฎิบัติ เพื่อตรวจสอบและปรับเปลี่ยนบางอย่าง
เหตุการณ์เหล่านี้ถูกระบุอย่างชัดเจนเพื่อช่วยให ้การตรวจสอบอย่างโปร่งใสและไร้อคติ
ความล ้มเหลวที่เกิดขึ้นเมื่อเราไม่ใช ้เหตุการณ์ต่างๆเหล่านี้

10. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 10
เราจะไม่สามารถตรวจสอบและปรับเปลี่ยนอะไรได ้
สปรินท์
หัวใจของสกรัม คือ สปรินท์ สปรินท์หนึ่งๆจะมีระยะเวลาไม่เกินหนึ่งเดือน ซึ่งรวบรวม สิ่งที่ “เสร็จสมบูรณ์”
สามารถใช ้งานได ้ และสามารถที่จะส่งมอบอินครีเม ้นท์ของผลิตภัณฑ์ สปรินท์
จะมีช่วงระยะเวลาที่สม่าเสมอตลอดช่วงเวลาการพัฒนา
สปรินท์ถัดไปจะเริ่มขึ้นทันทีหลังจากการสรุปของสปรินท์ที่ผ่านมาจบลง
สปรินท์จะประกอบด ้วยการประชุมวางแผนสปรินท์ สกรัมประจาวัน การพัฒนา การประเมินผลสปรินท์
และการพิจารณาสิ่งที่ผ่านมาในสปรินท์ อย่างสม่าเสมอ
ภายในสปรินท์
 ไม่ให ้เปลี่ยนแปลงสิ่งใดๆ ที่จะมีผลต่อเป้าหมายของสปรินท์
 องค์ประกอบของ ทีมพัฒนาซอฟท์แวร์ ไม่มีการเปลี่ยนแปลง
 ระดับคุณภาพทั้งหมดต ้องไม่ลดลง
 ขอบเขตอาจชัดเจนขึ้น
และอาจเกิดเจรจาระหว่างเจ ้าของผลิตภัณฑ์และทีมพัฒนาซอฟท์แวร์กันใหม่
เนืองจากสิ่งที่เรียนรู้เพิ่มขึ้นในสปรินท์
ในแต่ละสปรินท์ อาจถูกเปรียบได ้กับโครงการที่มีช่วงระยะเวลาของโครงการไม่เกิน 1 เดือน
เหมือนโครงการทั่วๆไป สปรินท์ใช ้แสดงการบรรลุเป้าหมาย แต่ละสปรินท์มีข ้อกาหนดชัดเจนว่า จะสร้าง
จะออกแบบ และแบบแผนที่ยืดหยุ่นซึ่งจะช่วยเป็นแนวทางในการสร้าง การทางาน และผลผลิตนั้นเอง
สปรินท์ ถูกจากัดให ้ไม่เกินหนึ่งเดือน เพราะเมื่อระยะเวลาสปรินท์มากกว่านี้ ข ้อกาหนดต่างๆ
ของการสร้างผลิตภัณฑ์ที่เรากาลังจะสร้าง อาจเปลี่ยนแปลง อาจมีความซับซ ้อน
และอาจมีความเสี่ยงสูงมากขึ้น สปรินท์ สามารถช่วยพยากรณ์ด ้วยความมั่นใจ
จากการตรวจสอบและการปรับเปลี่ยนของการพัฒนา เพื่อเข ้าสู่เป้าหมายอย่างน้อย ทุกๆเดือน สปรินท์
ยังสามารถจากัดความเสี่ยงต่อเดือนได ้ด ้วย
การยกเลิกสปรินท์
สปรินท์ สามารถถูกยกเลิกได ้ก่อนที่จะสิ้นสุดระยะเวลาของสปรินท์นั้น
แต่มีเพียงเจ้าของผลิตภัณฑ์เท่านั้นที่สามารถยกเลิกสปรินท์ได ้
แม ้ว่าเจ้าของผลิตภัณฑ์จะต ้องรับฟังผู้ถือผลประโยชน์ร่วม ทีมพัฒนาซอฟท์แวร์ หรือ ผู้ฝึกสอนสกัม
เป้าหมายของสปรินท์จะถูกยกเลิกไปด ้วย ถ ้าสปรินท์นั้นถูกยกเลิก การยกเลิกนี้อาจจะเกิดขึ้นได ้
ถ ้าบริษัทนั้นเปลี่ยนแปลงนโยบาย หรือ มีการเปลี่ยนแปลงแผนการตลาดหรือเทคโนโลยี โดยปกติแล ้ว
สปรินท์ ควรจะถูกยกเลิก
เมื่อเกิดสถานะการณ์ที่ความต ้องการของบริษัทหรือทีมนั้นไม่สมเหตุสมผลอีกต่อไป
แต่เนื่องด ้วยเวลาระยะเวลาที่สั้นของแต่ละสปรินท์ การยกเลิกจึงเกิดขึ้นได ้น้อยมาก
เมื่อไรก็ตามที่ สปรินท์ ถูกยกเลิก ทุกๆงานที่ “เสร็จสมบูรณ์” และถูกตรวจสอบแล ้ว
ถ ้างานนั้นเป็นส่วนหนึ่งของงานที่สามารถจะส่งมอบได ้ และ เจ้าของผลิตภัณฑ์ยอมรับได ้

11. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 11
ส่วนงานที่ยังทาไม่เสร็จสมบูรณ์ ทุกๆงาน
จะต ้องถูกประมวลใหม่อีกครั้งและนากลับไปอยู่ในส่วนของโปรดักแบ็กล็อก
บางชิ้นงานที่เสร็จสมบูรณ์ในส่วนของงานที่ยังทาไม่เสร็จสมบูรณ์จะถูกลดคุณค่าไปโดยปริยาย
และจะต ้องถูกประมวลผลใหม่บ่อยครั้ง
การยกเลิกสปรินท์บ่อยครั้ง ทาให ้สิ้นเปลืองทรัพยากร
ทั้งยังทุกคนต ้องเริ่มทาการประชุมการวางแผนสปรินท์ เพื่อเริ่มต ้นในสปรินท์ถัดไป
การยกเลิกสปรินท์บ่อยครั้งส่งผลเสียต่อสกรัมทีมมาก และ เป็นสิ่งผิดปกติมากๆ
การประชุมวางแผนสปรินท์
งานที่จะทาในสปรินท์จะมีการวางแผนในการประชุมวางแผนสปรินท์
โดยสมาชิกในสกรัมทีมจะร่วมมือกันสร้างแผนงานนี้ขึ้นมา
การประชุมวางแผนสปรินท์ จะถูกจากัดเวลาไม่ให ้เกินแปดชั่วโมงต่อสปรินท์ที่มีระยะเวลาหนึ่งเดือน
และลดหลั่นในอัตราส่วนที่เท่ากัน ในกรณีที่สปรินท์สั้นกว่าหนึ่งเดือน เช่น
สปรินท์ที่มีระยะเวลาสองสัปดาห์ จะกาหนดเวลาสาหรับการประชุมวางแผนไว ้ที่สี่ชั่วโมง
การประชุมวางแผนสปรินท์ ประกอบด ้วยสิ่งสาคัญสองส่วน
แต่ละส่วนจะถูกจากัดเวลาไว ้ครึ่งหนึ่งของเวลาทั้งหมด ทั้งสองส่วนนี้จะตอบคาถาม ดังต่อไปนี้
 เราจะส่งมอบอะไรบ ้างใน อินครีเม ้นท์ ที่เป็นผลลัพธ์จากสปรินท์ที่กาลังจะเริ่ม?
 งานที่จาเป็นเพื่อให ้ส่งมอบ อินครีเม ้นท์ ให ้สาเร็จ จะต ้องทาอย่างไร?
ส่วนที่หนึ่ง: มีอะไรบ้างที่จะทาให้เสร็จในสปรินท์นี้?
ในส่วนนี้ ทีมพัฒนาซอฟต์แวร์ จะร่วมกันคาดคะเนว่า
จะมีฟังก์ชันอะไรบ ้างที่จะทาการพัฒนาในระหว่างสปรินท์นี้
เจ้าของผลิตภัณฑ์มีหน้าที่แสดงโปรดักแบ็กล็อกที่จัดลาดับความสาคัญแล ้วให ้แก่ทีมพัฒนาซอฟท์แวร์รับ
ทราบ แล ้วสกรัมทีมจะร่วมมือกันสร้างความเข ้าใจร่วมกันต่องานในสปรินท์นั้น
ข ้อมูลที่ถูกป้อนเข ้ามาในการพิจารณาคือ โปรดักแบ็กล็อก อินครีเม ้นท์ของผลิตภัณฑ์ครั้งล่าสุด
ปริมาณงานที่รองรับได ้ของทีมพัฒนาซอฟท์แวร์ และขีดความสามารถของทีมพัฒนาซอฟท์แวร์ที่ผ่านมา
จานวนของงานที่จะถูกเลือกมาจากโปรดักแบ็กล็อกเข ้ามาในสปรินท์จะขึ้นอยู่กับทีมพัฒนาซอฟท์แวร์เท่านั้
น หมายความว่า มีเพียงทีมพัฒนาซอฟท์แวร์เท่านั้น
ที่สามารถประเมินได ้ว่าสิ่งใดที่จะทาให ้สาเร็จได ้ในสปรินท์ที่กาลังจะเริ่ม
หลังจากที่ทีมพัฒนาซอฟท์แวร์ได ้คาดคะเนจานวนงานจากโปรดักแบ็กล็อกแล ้วว่า
จะมีสิ่งใดบ ้างที่จะส่งมอบในสปรินท์ สกรัมทีมจะร่วมกันกาหนดเป้าหมายของสปรินท์
เป้าหมายของสปรินท์ก็คือจุดมุ่งหมายที่จะทาให ้สปรินท์สาเร็จลุล่วง
โดยการดาเนินงานตามโปรดักแบ็กล็อก
และเป้าหมายของสปรินท์ยังช่วยเป็นตัวชี้นาแนวทางของทีมพัฒนาซอฟท์แวร์ว่าทาไมเราถึงสร้าง
อินครีเม ้นท์ ครั้งนี้
ส่วนที่สอง: ทาอย่างไรให้ งานที่เลือกไว้เสร็จสมบูรณ์?

12. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 12
การเลือกสิ่งที่จะทาไว ้ในสปรินท์ และทีมพัฒนาซอฟท์แวร์เป็นคนตัดสินใจว่าจะสร้างฟังก์ชันงานอย่างไร
เพื่อเป็น อินครีเม ้นท์ ที่ “เสร็จสมบูรณ์” ในสปรินท์
รายการที่เลือกจากโปรดักแบ็กล็อกไว ้สาหรับสร้างในสปรินท์ รวมกับแผนงานการส่งมอบนี้ เรียกว่า
สปรินท์แบ็กล็อก
โดยปกติแล ้วทีมพัฒนาซอฟท์แวร์จะเริ่มการทางานจากการออกแบบกระบวนการ
และทาการเปลี่ยนชิ้นงานในโปรดักแบ็กล็อกไปเป็น อินครีเม ้นท์ ที่สามารถใช ้งานได ้ของผลิตภัณท์
ขนาดและการประเมินระยะเวลาการทางานของชิ้นงานอาจจะมีความหลากหลาย อย่างไรก็ตาม
การวางแผนในการประชุมวางแผนสปรินท์จะวางแผนให ้เพียงพอกับงานที่จะทาในสปรินท์ที่จะเริ่มขึ้น
โดยทีมพัฒนาซอฟท์แวร์จะแบ่งชิ้นงานที่วางแผนไว ้
ออกเป็นหน่วยย่อยที่มีระยะเวลาการทางานภายในหนึ่งวันหรือน้อยกว่า ในช่วงท ้ายของการประชุมนี้
ทีมพัฒนาซอฟท์แวร์ต ้องบริหารงานที่อยู่ในสปรินท์แบ็กล็อกด ้วยตนเอง
ทั้งในระหว่างการประชุมการวางแผนสปรินท์และในระหว่างสปรินท์
เจ ้าของผลิตภัณฑ์อาจจะนาเสนองานในช่วงที่สองของการประชุมการวางแผนสปรินท์เพื่อขยายความของ
งานที่ได ้ถูกคัดเลือกจากโปรดักแบ็กล็อก และ ช่วยในการตัดสินใจเลือก
หรือสลับสับเปลี่ยนงานภายในสปรินท์
ถ ้าทีมพัฒนาซอฟท์แวร์ตกลงร่วมกันว่าปริมาณงานนั้นมากเกินไปหรือน้อยเกินไป
อาจจะต ้องร่วมกันเจรจากับเจ้าของผลิตภัณฑ์ เพื่อบรรลุข ้อตกลงของสปรินท์แบ็กล็อกร่วมกัน
ทีมพัฒนาซอฟท์แวร์อาจเชิญบุคคลที่เกี่ยวข ้องเข ้าร่วมในการประชุมเพื่อที่ให ้คาแนะนาเฉพาะทาง หรือ
ขอบเขตของงาน
เมื่อการประชุมการวางแผนสปรินท์สิ้นสุดลง
ทีมพัฒนาซอฟท์แวร์จะสามารถอธิบายให ้เจ้าของผลิตภัณฑ์และสกรัมมาสเตอร์เข ้าใจได ้ว่า
ทาอย่างไรงานจะบรรลุเป้าหมายของสปรินท์ และสิ่งที่คาดว่าจะสร้างใน อินครีเม ้นท์
เป้ าหมายของสปรินท์
เป้าหมายของสปรินท์อนุญาตให ้ทีมพัฒนาซอฟท์แวร์มีความยืดหยุ่นในวิธีการพัฒนาในสปรินท์
ขณะที่ทีมงานพัฒนาซอฟท์แวร์ทางาน จะต ้องคานึงถึงเป้าหมายของสปรินท์อยู่เสมอ
เพื่อที่จะบรรลุเป้าหมายของสปรินท์ ทีมพัฒนาซอฟท์แวร์จะพัฒนาฟันก์ชันและเทคโนโลยี
ถ ้างานที่ออกมาไม่เป็นไปตามที่ทีมพัฒนาซอฟท์แวร์คาดไว ้
พวกเขาควรปรึกษากับเจ้าของผลิตภัณฑ์เพื่อเจรจาขอบเขตของสปรินท์แบ็กล็อกภายในสปรินท์
เป้าหมายของสปรินท์อาจเทียบได ้ว่าเป็นเป้าหมายย่อยของเป้าหมายใหญ่ของแนวทางผลิตภัณฑ์
สกรัมประจาวัน
สกรัมประจาวัน คือเหตการณ์ที่มีระยะเวลา 15 นาที ซึ่งกาหนดให ้ทีมพัฒนาซอฟท์แวร์
ทาการประสานงานและสร้างแผนงานสาหรับ 24 ชั่วโมงถัดไป สิ่งที่ทาในสกรัมประจาวันคือ
ตรวจสอบผลงานที่ผ่านมาในช่วงระหว่างสกรัมประจาวันครั้งที่แล ้ว
และคาดคะเนว่าจะมีงานอะไรเสร็จบ ้างก่อนถึงสกรัมประจาวันครั้งถัดไป

13. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 13
สกรัมประจาวันจะถูกจัดขึ้นในเวลาและสถานที่เดิมเพื่อไม่ให ้เกิดความยุ่งยาก ในระหว่างสกรัมประจาวัน
สมาชิกทีมพัฒนาซอฟท์แวร์แต่ละคนจะอธิบายถึงสิ่งต่อไปนี้
 มีอะไรที่ทาเสร็จสมบูรณ์บ ้าง นับตั้งแต่สกรัมประจาวันครั้งที่แล ้ว?
 มีอะไรบ ้างที่คาดว่าจะทาเสร็จสมบูรณ์ก่อนที่จะถึงสกรัมประจาวันครั้งต่อไป?
 มีอุปสรรคอะไรบ ้างที่ขัดขวางไม่ให ้ทางานเสร็จสมบูรณ์?
ทีมพัฒนาซอฟท์แวร์จะใช ้ช่วงเวลาในสกรัมประจาวันเพื่อประเมินความก ้าวหน้าเทียบกับ
เป้าหมายของสปรินท์ และประเมินแนวโน้มของความก ้าวหน้าของงานที่สาเร็จเทียบกับสปรินท์แบ็กล็อก
สกรัมประจาวันช่วยให ้ทีมพัฒนาซอฟท์แวร์เข ้าใกล ้จุดมุ่งหมายของสปรินท์ได ้ง่ายขึ้น
ทีมพัฒนาซอฟท์แวร์มักจะพูดคุยถึงการวางแผนงานใหม่สาหรับงานที่ยังเหลือในสปรินท์ภายหลังสกรัมปร
ะจาวัน
ทีมพัฒนาซอฟท์แวร์จะรายงานความก ้าวหน้าและการทางานร่วมกันในทีมให ้เจ้าของผลิตภัณฑ์และสกรัมม
าสเตอร์รับทราบถึงสิ่งที่คาดว่าจะสร้างใน อินครีเม ้นท์นี้ในระยะเวลาที่เหลือของสปรินท์
สกรัมมาสเตอร์จะต ้องทาให ้มั่นใจได ้ว่าทีมพัฒนาซอฟท์แวร์ทาสกรัมประจาวัน
แต่ทีมพัฒนาซอฟท์แวร์มีหน้าที่ในการดาเนินสกรัมประจาวัน
สกรัมมาสเตอร์จะสอนทีมพัฒนาซอฟท์แวร์ให ้รักษาเวลาสกรัมประจาวันให ้ไม่เกินสิบห ้านาที
สกรัมมาสเตอร์จะใช ้กฏข ้อบังคับกับทีมผู้พัฒนาซอฟท์แวร์ที่เข ้าร่วมในสกรัมประจาวันเท่านั้น
สกรัมประจาวันไม่ใช่การประชุมรายงานสถานะ แต่มีเพื่อให ้ทีมเปลี่ยนจากงานในโปรดักแบ็กล็อกให ้เป็น
อินครีเม ้นท์ ของผลิตภัณฑ์
สกรัมประจาวันช่วยพัฒนาการสื่อสาร ลดจานวนการประชุมอื่นๆ
ช่วยระบุแล ้วกาจัดสิ่งกีดขวางการพัฒนาซอฟท์แวร์ เน้นและสนับสนุนให ้เกิดการตัดสินใจที่รวดเร็ว
ทั้งช่วยพัฒนาความรู้ความเข ้าใจในโครงการที่ทีมพัฒนาซอฟท์แวร์ทาอยู่
การสกรัมประจาวันเคือหัวใจในการตรวจสอบและปรับปรุงเปลี่ยนแปลง
การประเมินสปรินท์
การประเมินสปรินท์จะเริ่มในช่วงท ้ายของสปรินท์
เพื่อตรวจสอบอินครีเม ้นท์และปรับปรุงโปรดักแบ็กล็อกถ ้าจาเป็น ระหว่างการประเมินสปรินท์
สกรัมทีมและผู้ถือผลประโยชน์ร่วมจะพูดคุยว่ามีสิ่งใดเสร็จสมบูรณ์ในสปรินท์บ ้าง
ผู้เข ้าร่วมประเมินจะช่วยกันประเมินงานที่จะทาให ้เสร็จสมบูรณ์ในสปรินท์ต่อไป
โดยคานึงจากการเปลี่ยนแปลงที่เกิดขึ้นในระหว่างสปรินท์
การประเมินสปรินท์เป็นการประชุมที่ไม่เป็นทางการ
ผู้นาเสนออินครีเม ้นท์จะต ้องมีความตั้งใจที่จะขอข ้อเสนอแนะและสนับสนุนให ้เกิดการร่วมมือกัน
การประเมินสปรินท์จะถูกกาหนดให ้มีระยะเวลาไม่เกิน 4 ชั่วโมง ต่อสปรินท์ที่มีระยะเวลาหนึ่งเดือน
ระยะเวลาจะลดหลั่นเป็นอัตราส่วนในกรณีที่สปรินท์สั้นกว่าหนึ่งเดือน ยกตัวอย่างเช่น
สปรินท์ที่มีระยะเวลาสองสัปดาห์จะมีการประเมินสปรินท์ไม่เกิน 2 ชั่วโมง
การประเมินสปรินท์ประกอบด ้วยสิ่งสาคัญ ดังต่อไปนี้

14. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 14
 เจ ้าของผลิตภัณฑ์ระบุสิ่งที่ทาเสร็จสมบูรณ์และสิ่งที่ยังไม่เสร็จสมบูรณ์
 ทีมพัฒนาซอฟท์แวร์แสดงความคิดเห็นถึงสิ่งที่ทาได ้ดีในระหว่างสปรินท์ สิ่งใดเป็นปัญหาที่พบ
และจะแก ้ไขปัญหานั้นอย่างไร
 ทีมพัฒนาซอฟท์แวร์แสดงผลงานที่เสร็จสมบูรณ์ และตอบคาถามเกี่ยวกับอินครีเม ้นท์
 เจ้าของผลิตภัณฑ์ปรึกษาหารือรายการโปรดักแบ็กล็อกที่เหลืออยู่
คาดคะเนวันที่เสร็จสิ้นโดยวัดจากความก ้าวหน้าที่เกิดขึ้น
 ทั้งทีมจะแสดงความคิดเห็นว่าจะทาสิ่งใดต่อไป
ดังนั้นการประเมินสปรินท์จะสร้างข ้อมูลที่เป็นประโยนช์ป้อนไปยังการประชุมวางแผนสปรินท์ต่อไป
ผลของการประเมินสปรินท์ คือโปรดักแบ็กล็อกที่มีการปรับปรุงเปลี่ยนแปลง
ซึ่งจะเป็นตัวกาหนดรายการโปรดักแบ็กล็อกสาหรับสปรินท์ถัดไป โปรดักแบ็กล็อกอาจถูกปรับปรุงให ้เหมา
ะสมกับความต ้องการใหม่
การพิจารณาสปรินท์ที่ผ่านมา
การพิจารณาสปรินท์ที่ผ่านมาเป็นโอกาสสาหรับสกรัมทีมที่จะตรวจสอบตนเอง
และสร้างแผนสาหรับการพัฒนาที่จะมีผลในสปรินท์ถัดไป
การพิจารณาสปรินท์ที่ผ่านมา เกิดขึ้นหลังจากการประเมินสปรินท์
และก่อนการประชุมวางแผนสปรินท์ครั้งถัดไป การพิจารณาสปรินท์ที่ผ่านมาจะใช ้เวลา 3
ชั่วโมงในการประชุมสาหรับ สปรินท์ที่มีระยะเวลา 1 เดือน
และจะลดหลั่นเป็นอัตราส่วนในกรณีที่สปรินท์สั้นกว่า

15. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 15
จุดประสงค์ของการพิจารณาสปรินท์ที่ผ่านมา คือ
 ตรวจสอบว่าสปรินท์ที่ผ่านมามีความเป็นไปอย่างไรบ ้าง ที่เกี่ยวข ้องกับตัวบุคคล ความสัมพันธ์
กระบวนการทางาน และเครื่องมือ
 ระบุและจัดลาดับสิ่งสาคัญที่ทาได ้ดี และ สิ่งที่สามารถปรับปรุงให ้ดีขึ้นได ้
 วางแผนงานสาหรับการปรับปรุงวิธีการทางานของสกรัมทีม
สกรัมมาสเตอร์กระตุ้นสกรัมทีมให ้ปรับปรุงกระบวนการพัฒนาและหลักปฏิบัติเพื่อให ้เกิดประสิทธิภาพและมี
ความสุขมากขึ้นในการทางานสปรินท์ถัดไป ในระหว่างแต่ละการพิจารณาสปรินท์ที่ผ่านมา
สกรัมทีมวางแผนที่จะเพิ่มคุณภาพของผลิตภัณฑ์โดยปรับเปลี่ยนนิยามของคาว่า “เสร็จสมบูรณ์”
ตามความเหมาะสม
ในช่วงสุดท ้ายของการพิจารณาสปรินท์ที่ผ่านมา สกรัมทีมควรระบุสิ่งที่จะปรับปรุงในสปรินท์ถัดไปได ้
การปรับปรุงเหล่านี้ทาให ้เกิดการปรับปรุงที่เกิดจากการตรวจสอบของสกรัมทีมด ้วยตัวเอง
แม ้ว่าการปรับปรุงจะทาในเวลาใดก็ได ้
การพิจาณาสปรินท์ที่ผ่านมาเป็นโอกาสอย่างเป็นทางการที่จะมุ่งเน้นถึงการตรวจสอบและการปรับปรุง
สกรัมอาติแฟก
สกรัมอาติแฟก ใช ้เป็นตัวแทนของการทางานหรือคุณค่าของชิ้นงานที่เป็นประโยนช์ในรูปแบบต่างๆ
ซึ่งมีความโปร่งใสชัดเจนและเปิดโอกาสให ้ตรวจสอบได ้ สกรัมอาติแฟก
ถูกกาหนดตามแบบสกรัมและออกแบบมาโดยเฉพาะเพื่อเพิ่มความโปร่งใสชัดเจนของข ้อมูลหลักที่จาเป็น
ต่อสกรัมทีมเพื่อให ้มั่นใจได ้ว่าทีมสามารถส่งมอบอินครีเม ้นท์ที่ “เสร็จสมบูรณ์” ได ้
โปรดักแบ็กล็อก
โปรดักแบ็กล็อก คือ รายการของชิ้นงานที่จาเป็นในการพัฒนาผลิตภัณฑ์ที่จัดเรียงตามลาดับความสาคัญ
และเป็นแหล่งข ้อมูลเดียว ที่รวมความต ้องการต่าง ๆ ในการพัฒนาผลิตภัณฑ์นั้น
เจ้าของผลิตภัณฑ์เป็นผู้รับผิดชอบโปรดักแบ็กล็อกทั้งหมด ซึ่งรวมถึงความถูกต ้องของเนื้อหา การเข ้าถึง
และการเรียงลาดับความสาคัญใน โปรดักแบ็กล็อก
โปรดักแบ็กล็อก จะถูกใช ้งานและปรับปรุงอยู่ตลอดเวลา
ในช่วงแรกโปรดักแบ็กล็อกเป็นเพียงความเข ้าใจในระดับเบื้องต ้นของความต ้องการของลูกค ้า
รายการที่อยู่โปรดักแบ็กล็อกจะค่อย ๆ ถูกนาไปสร้างเป็นตัวผลิตภัณฑ์และส่วนประกอบอื่น ๆ
โปรดักแบ็กล็อกเป็นรายการที่มีการเปลี่ยนแปลงและมีการปรับปรุงอย่างต่อเนื่อง
เพื่อที่จะรองรับความต ้องการของลูกค ้า เพื่อให ้ตัวผลิตภัณฑ์เองมีประโยชน์สูงสูด
และสามารถแข่งขันกับคู่แข่งได ้ กล่าวคือตราบใดที่ยังมีการพัฒนาผลิตภัณฑ์อยู่
โปรดักแบ็กล็อกจะยังมีการใช ้งานอยู่เช่นกัน
โปรดักแบ็กล็อกนั้นจะประกอบไปด ้วยรายการของ คุณสมบัติ ฟังก์ชั่น และความต ้องการของลูกค ้าต่างๆ
ในการปรับปรุงแก ้ไขหรือพัฒนาตัวผลิตภัณฑ์ที่จะนาไปพัฒนาเป็นชิ้นงานที่จะส่งมอบในรอบถัดไป

16. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 16
รายการโปรดักแบ็กล็อกจะประกอบไปด ้วย รายละเอียด ลาดับความสาคัญ และการคาดคะเน
ความต ้องการของลูกค ้า
โปรดักแบ็กล็อกมักจะเรียงลาดับตามคุณค่า ความเสี่ยง ความสาคัญ และความจาเป็น
โดยเรียงลาดับจากบนไปล่างเพื่อผลักดันให ้เกิดการพัฒนาตามลาดับของโปรดักแบ็กล็อก
ตาแหน่งของรายการโปรดักแบ็กล็อกที่อยู่ด ้านบนจะผ่านการพิจารณาเป็นเอกฉันท์ว่าเป็นรายการที่มีคุณค่า
กว่า
รายการโปรดักแบ็กล็อกที่อยู่ด ้านบนจะมีความชัดเจนและรายละเอียดมากว่ารายการที่อยู่ด ้านล่าง
เพื่อเป็นการเจาะจง การคาดคะเนนี้เกิดขึ้นตามความชัดเจนและรายละเอียดที่เพิ่มขึ้นของรายการนั้น
นั้นเอง รายการที่มีรายละเอียดน้อยกว่าจะอยู่ลาดับล่าง
รายการโปรดักแบ็กล็อกที่ได ้แจกแจงเนื้อหารายละเอียดแล ้วและสามารถที่จะ “เสร็จสมบูรณ์”
ได ้ในระหว่างสปรินท์นั้นจะครอบครองทีมพัฒนาซอฟท์แวร์ในสปรินท์ที่กาลังจะเริ่มขึ้น
รายการโปรดักแบ็กล็อกที่ทีมพัฒนาซอฟท์แวร์สามารถทาให ้ “เสร็จสมบูรณ์” ได ้นั้นถือว่าเป็นรายการที่
“พร้อม” หรือ “สามารถลงมือทาได ้” สาหรับการประชุมวางแผนสปรินท์
เนื่องจากผลิตภัณท์ที่ใช ้งานและมีคุณค่าจะได ้รับการตอบรับจากตลาดการแข่งขัน
โปรดักแบ็กล็อกก็จะขยายใหญ่ขึ้นและเป็นรายการที่ครบถ ้วนมากขึ้น
ความต ้องการของลูกค ้าไม่เคยหยุดนิ่ง ดังนั้น โปรดักแบ็กล็อกจึงเป็นอาติแฟตที่ไม่หยุดนิ่งด ้วย
ความเปลี่ยนแปลงความต ้องการด ้านธุรกิจ เงื่อนไขการตลาด หรือ แม ้การเปลี่ยนแปลงทางเทคโนโลยีเอง
ก็สามารถปรับเปลี่ยนรายการในโปรดักแบ็กล็อกได ้
บ่อยครั้งที่สกรัมทีมหลายๆทีมทางานร่วมกันบนผลิตภัณท์เดียวกัน
แต่มีโปรดักแบ็กล็อกเดียวเท่านั้นที่ใช ้เรียงลาดับชิ้นงานที่จะทาต่อไปของผลิตภัณท์นั้น
และแจกจ่ายรายการโปรดักแบ็กล็อกที่เป็นของทีมนั้นๆ
การจัดแต่งโปรดักแบ็กล็อก คือการเพิ่มเติมรายละเอียด การประเมิน และ
จัดลาดับรายการในโปรดักแบ็กล็อก
การจัดแต่งรายละเอียดของโปรดักแบ็กล็อกเป็นงานที่ต ้องทาอย่างต่อเนื่องซึ่งเกิดจาการร่วมมือกันระหว่าง
เจ้าของผลิตภัณท์และทีมพัฒนาซอฟท์แวร์
ระหว่างการจัดแต่งโปรดักแบ็กล็อกนั้นเราจะทาการประเมิณและแก ้ไขรายการนั้นๆ อย่างไรก็ตาม
โปรดักแบ็กล็อกสามารถปรับปรุงได ้ตลอดเวลาโดยเจ ้าของผลิตภัณท์
หรือตามดุลพินิจของเจ้าของผลิตภัณท์
การจัดแต่งเป็นงานชั่วคราวในสปรินท์ซึ่งเกิดขึ้นระหว่างเจ้าของผลิตภัณท์กับทีมพัฒนาซอฟท์แวร์
บ่อยครั้งที่ทีมพัฒนาซอฟท์แวร์มีความสามารถเฉพาะตัวที่สามารถจัดแต่งโปรดักแบ็กล็อกได ้เอง
วิธีการและเวลาที่ทาการจัดแต่งนั้นขึ้นอยู่กับสกรัมทีมนั้นๆ
การจัดแต่งจะใช ้ความสามารถของทีมพัฒนาซอฟท์แวร์ไม่เกิน 10เปอร์เซ็นต์ของความสามารถทั้งทีม
ทีมพัฒนาซอฟท์แวร์รับผิดชอบในการประเมินทั้งหมด
เจ ้าของผลิตภัณท์อาจช่วยออกความคิดเห็นที่ช่วยให ้เล็งเห็นถึงส่วนได ้ส่วนเสียต่างๆได ้
แต่คนที่ลงมือทาจริงๆเท่านั้นจึงจะมีสิทธิ์ที่จะประเมินเนื้องานได ้

17. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 17
การติดตามความคืบต่อเป้ าหมาย
ณ ช่วงเวลาใดก็ตาม เราสามารถสรุปปริมาณงานที่เหลืออยู่เพื่อให ้บรรลุเป้าหมายได ้
เจ้าของผลิตภัณท์จะติดตามปริมาณงานที่เหลืออยู่อย่างน้อยทุกๆการประเมินสปรินท์
เจ้าของผลิตภัณท์จะเปรียบเทียบปริมาณงานที่เหลืออยู่ของการประเมินสปรินท์ที่ผ่าน
เพื่อวัดความคืบหน้าของการทางานที่จะเสร็จสิ้นได ้ตามเวลาที่ตั้งเป้าไว ้
ข ้อมูลเหล่านี้จะแสดงอย่างชัดเจนต่อผู้ถือผลประโยชน์ร่วม
การวิเคราะห์แนวโน้ม เช่น เบิร์นดาว์น เบิร์นอัพ
และการวิเคราะห์โครงการแบบอื่นๆใช ้สาหรับคาดคะเนความคืบหน้า สิ่งเหล่านี้ล ้วนช่วยในการคาดคะเน
อย่างไรก็ตามสิ่งเหล่านั้นไม่สามารถทดแทนวิธีที่สาคัญอย่าง
ในสิ่งแวดล ้อมที่ซับซ ้อนเราไม่มีทางทราบเลยว่าอะไรจะเกิด
แต่เราจะทราบเพียงแต่สิ่งที่เคยเกิดขึ้นมาก่อน เราจึงใช ้สิ่งนั้นในการมองไปข ้างหน้า และการตัดสินใจ
สปรินท์แบ็กล็อก
สปรินท์แบ็กล็อกเป็นชุดรายการในโปรดักแบกล็อกที่ถูกเลือกมาพัฒนาในสปรินท์
รวมถึงแผนงานในการส่งมอบผลิตภัณฑ์ที่เพิ่มขึ้นนั้นๆ โดยตระหนักถึงเป้าหมายของสปรินท์ด ้วย
สปรินท์แบ็กล็อกคือการคาดการณ์ล่วงหน้าของฟังก์ชันที่จะถูกทาเพิ่มเติมและชิ้นงานที่จาเป็นต ้องส่งมอบ
ชิ้นงานนั้นๆ โดยทีมพัฒนาซอฟท์แวร์
สปรินท์แบ็กล็อก ระบุถึงชิ้นงานที่ทีมพัฒนาซอฟท์แวร์สร้างเพื่อที่จะเปลี่ยนโปรดักแบกล็อกไปเป็น
อินครีเม ้นท์ที่ “เสร็จสมบูรณ์” สปรินท์แบ็กล็อก
แสดงให ้เห็นถึงทุกชิ้นงานที่ทีมพัฒนาซอฟท์แวร์ระบุว่าจาเป็นต่อการบรรลุเป้าหมายของสปรินท์
สปรินท์แบ็กล็อก
คือแผนงานที่มีข ้อมูลเพียงพอที่จะสามารถเริ่มพัฒนาชิ้นงานนั้นและสามารถเข ้าใจได ้ในการทาสกรัมประ
จาวัน
ทีมพัฒนาซอฟท์แวร์สามารถปรับปรุงเปลี่ยนแปลงและเพิ่มเติมสปรินท์แบ็กล็อกได ้ในระหว่างสปรินท์
การเพิ่มเติมสปรินท์แบ็กล็อกนี้สามารถทาได ้โดยทีมพัฒนาซอฟท์แวร์
ที่ทาตามแผนงานที่วางไว ้และเรียนรู้จากการพัฒนาว่าชิ้นงานนี้จาเป็นต ้องเพิ่มเติมเพื่อให ้สามารถบรรลุเป้า
หมายของสปรินท์เท่านั้น
เมื่อมีการเพิ่มเติมชิ้นงาน ทีมพัฒนาซอฟท์แวร์จะเพิ่มชิ้นงานใหม่เข ้าไปในสปรินท์แบ็กล็อก
ตามที่ชิ้นงานจะถูกสร้างขึ้นหรือเสร็จสิ้น การคาดคะเนชิ้นงานที่เหลืออยู่ก็จะถูกปรับปรุงตามไปด ้วย
หากมีชิ้นงานที่ไม่จาเป็น ชิ้นงานนั้นก็จะถูกนาออกจากรายการ
ทีมพัฒนาซอฟท์แวร์เท่านั้นที่จะสามารถเข ้ามาเปลี่ยนแปลงสปรินท์แบ็กล็อกในระหว่างสปรินท์ได ้
สปรินท์แบ็กล็อกเแสดงให ้เห็นถึงผลงานของทีมพัฒนาซอฟท์แวร์ได ้ทาสาเร็จในระหว่างสปรินท์แบบเรียล
ไทม์อย่างชัดเจน และสปรินท์แบ็กล็อกเป็นของทีมพัฒนาซอฟท์แวร์เท่านั้น

18. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 18
การติดตามความคืบหน้าของสปรินท์
ณ ช่วงเวลาใดก็ตามของสปรินท์ เราจะสามารถสรุปปริมาณชิ้นงานที่เหลือทั้งหมดในสปรินท์นั้นๆได ้
โดยที่ทีมพัฒนาซอฟท์แวร์จะสามารถติดตามปริมาณชิ้นงานที่เหลือทั้งหมดได ้จากการสกรัมประจาวันเป็น
อย่างน้อย ทีมพัฒนาซอฟท์แวร์ยังสามารถติดตามผลสรุปประจาวันของโครงการ
และความเป็นไปได ้ของการบรรลุเป้าหมายของสปรินท์
โดยการติดตามปริมาณชิ้นงานที่เหลืออยู่ภายในสปรินท์นี้
ทาให ้ทีมพัฒนาซอฟท์แวร์สามารถรายงานผลความคืบหน้าได ้
สกรัมไม่ได ้ให ้ความสาคัญกับเวลาที่ใช ้ไปกับชิ้นงาน แต่กลับให ้ความสาคัญกับปริมาณงานที่เหลืออยู่ และ
ระยะเวลาที่เหลืออยู่มากกว่า
อินครีเม้นท์
อินครีเม ้นท์
คือชิ้นงานในโปรดักแบ็กล็อกที่เสร็จแล ้วในสปรินท์ปัจจุบันและสปรินท์ที่ผ่านมาก่อนหน้านี้ทั้งหมด
เมื่อสปรินท์จบลงอินครีเม ้นท์ใหม่จะต ้อง “เสร็จสมบูรณ์”
ซึ่งหมายความว่าชิ้นงานต ้องอยู่ในสภาพที่ใช ้งานได ้จริงและสอดคล ้องกับนิยามของคาว่า “เสร็จสมบูรณ์”
ของสกรัมทีม โดยไม่คานึงถึงเจ ้าของผลิตภัณท์จะตัดสินใจส่งมอบชิ้นงานออกไปหรือไม่ก็ตาม

19. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 19
นิยามของคาว่า “เสร็จสมบูรณ์”
เมื่อเราเห็นคาว่า “เสร็จสมบูรณ์” ในโปรดักแบ็กล็อกหรืออินครีเม ้นท์ก็ตาม
ทุกคนในสกรัมทีมจะต ้องเข ้าใจความหมายของ “เสร็จสมบูรณ์” ตรงกัน
อย่างไรก็ตามนิยามของแต่ละสกรัมทีมสามารถไม่เหมือนกันได ้
แต่สมาชิกสกรัมทีมจะต ้องเข ้าใจร่วมกันถึงการเสร็จสิ้นของชิ้นงาน และมั่นใจว่าเข ้าใจตรงกันอย่างชัดเจน
และนี้คือความหมายของ “นิยามของคาว่า เสณ็จสมบูรณ์” ของสกรัมทีม
ซึ่งใช ้สาหรับระบุการเสร็จสิ้นของชิ้นงานในอินครีเม ้นท์ของผลิตภัณท์นั้นเอง
การมีนิยามที่ตรงกันนั้น ยังสามารถเป็นแนวทางให ้ทีมพัฒนาซอร์ฟแวร์สามารถประเมินได ้ว่าจะเลือก
โปรดักแบ็กล็อกอะไรเข ้ามาในการวางแผนสปรินท์ โดยจุดประสงค์ของแต่ละสปรินท์คือ
สร้างอินครีเม ้นท์ที่มีฟังก์ชั่นที่สามารถส่งมอบและเสร็จสิ้นตรงตามกับนิยามของคาว่า “เสร็จสมบูรณ์”
ทีมพัฒนาซอร์ฟแวร์สร้างอินครีเม ้นท์ของผลิตภัณท์ที่เพิ่มขึ้นทุกๆสปรินท์
เป็นอินครีเม ้นท์ที่สามารถใช ้งานได ้จริง และเจ ้าของผลิตภัณท์อาจทาการส่งมอบชิ้นงานนั้นทันที
ในแต่ละอินครีเม ้นท์คือการเพิ่มชิ้นงานลงไปตามลาดับความสาคัญของอินครีเม ้นท์ทั้งหมด
และผ่านการทดสอบอย่างละเอียดแล ้วว่าแต่ละอินครีเม ้นท์สามารถทางานร่วมกันได ้
เมื่อสกรัมทีมมีประสบการณ์มากขึ้น เราคาดหวังว่านิยามของคาว่า “เสร็จสมบูรณ์”
จะมีเงื่อนไขเพิ่มมากขึ้นเพื่อให ้คุณภาพของชิ้นงานมีมากขึ้นตามไปด ้วย
บทสรุป
สกรัม นั้นไม่มีค่าใช ้จ่าย เป็นสิ่งที่นาเสนอในคู่มือนี้ โดยมี บทบาทของกสรัม อาติแฟก เหตุการณ์
และกฎข ้อบังคับซึ่งไม่สามารถปรับเปลี่ยนได ้ และการเลือกนาไปใช ้งานเพียงบางส่วนไม่นับว่าเป็นสกรัม
สกรัมจะเกิดขึ้นเมื่อเรารวบรวมเอาเทคนิค วิธีการ และแบบปฎิบัติทั้งหมดนามาใช ้งานเท่านั้น

20. ©2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://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.
หน้า | 20
คาขอบคุณ
บุคคลสาคัญ
จากคนนับพันที่ร่วมอุทิศในการสร้างวิธีการทางานแบบสกรัม เราควรจะต ้องกล่าวถึงผู้ที่ทาการริเริ่มในช่วง
10 ปีแรก อันได ้แก่ เจฟ ซัทเธอร์แลนด์ ซึ่งทางานร่วมกับ เจฟ แมคแคนนา, เคน ชวาเบอร์, ไมค์ สมิทช์
และ คริส มาร์ติน รวมถึงอีกหลายๆท่านที่ร่วมอุทิศในการทางานนานนับปี
หากปราศจากความช่วยเหลือจากท่านทั้งหลายเหล่านั้นแล ้ว
วิธีการทางานแบบสกรัมจะไม่สามารถเกิดขึ้นและพัฒนาเท่าทุกวันนี้ได ้เดวิด สตาร์
เป็นอีกหนึ่งบุคคลสาคัญในการให ้ข ้อมูลเชิงลึกและเรียบเรียงคู่มือการทางานแบบสกรัมฉบับนี้
ประวัติ
เคน ชวาเบอร์ และ เจฟ ซัทเธอร์แลนด์ ได ้เสนอแนวคิดเรื่องสกรัมด ้วยกันครั้งแรกที่ การประชุม
โอโอพีเอสแอลเอ ในปี พ.ศ. 2538 การนาเสนอครั้งนี้ได ้มีการบันทึกสิ่งที่ เคน และ เจฟ
ได ้เรียนรู้มาในช่วง 2-3 ปี ที่ผ่านมา
สกรัมถือได ้ว่ามีประวัติความเป็นมาที่ยาวนาน เพื่อเป็นการให ้เกียรติ เราขอขอบคุณ Individual, Inc.,
Fidelity Investments และ IDX (ปัจจุบันคือ GE Medical)
คู่มือสกรัมนี้ ได ้ถูกพัฒนาอย่างต่อเนื่องมาเป็นเวลามากกว่า 20 ปี โดย เจฟ ซัทเธอร์แลนด์ และ เคน
ชวาเบอร์ แหล่งข ้อมูลอื่นๆ จะให ้ข ้อมูลเกี่ยวกับ รูปแบบ กระบวนการทางาน และ
ความรู้เชิงลึกในการปฏิบัติงาน เพื่ออานวยความสะดวก
และเครื่องมือ ที่ช่วยทาให ้แบบแผนการทางานแบบสกรัมมีความสมบูรณ์ยิ่งขึ้น สิ่งต่าง ๆ
เหล่านี้จะช่วยทาให ้ผลิตภัณท์มีประสิทธิภาพ มีคุณค่า ส่งเสริมความคิดสร้างสรรค์ และ
สร้างความภาคภูมิใจ