การวางแผน Sprint ตั้งอยู่บนสมมติฐานเงียบ ๆ ข้อหนึ่งมาตลอด นั่นคือ ขีดความสามารถเท่ากับจำนวนคนที่คุณมีคูณกับกรอบเวลา คุณประเมินงานขึ้นมา เทียบกับสิ่งที่ทีมทำเสร็จในรอบที่แล้ว แล้วก็รับปาก scope ที่พอดี
แต่พอเอา AI coding Agent เข้ามาในทีม สมการนี้ก็ไม่สะท้อนความจริงอีกต่อไป Agent หยิบ Task ไปทำได้ทันทีที่พร้อม ทำงานขนานไปกับ Agent ตัวอื่น ๆ และส่ง diff พร้อมผลการทดสอบกลับมาก่อนการประชุม standup ที่คุณตั้งใจจะคุยเรื่องนั้นด้วยซ้ำ ขีดความสามารถในการลงมือทำพุ่งสูงขึ้นอย่างมหาศาล ปฏิกิริยาที่ชวนให้ทำตามก็คือรับ scope เพิ่มเข้าไป และทีมที่ทำแบบนั้นมักเจอโหมดความล้มเหลวนี้ภายในสิ้นรอบแรก นั่นคือ Sprint ปิดลงพร้อมโค้ดที่เสร็จแล้วเพียบ แต่กลับมีกำแพงของความเปลี่ยนแปลงที่ยังไม่ผ่านการรีวิว ซึ่งไม่มีใครมีเวลาตรวจรับ
นี่คือประเด็นที่บทความนี้ต้องการเสนอ เมื่อมี Agent อยู่ในทีม การลงมือทำก็ไม่ใช่ข้อจำกัดของ Sprint อีกต่อไป แต่การรีวิวโดยมนุษย์ต่างหากที่เป็นข้อจำกัดของ Sprint ให้วางแผนโดยอิงจากปริมาณงานที่ตรวจรับได้ ไม่ใช่จากปริมาณโค้ดที่ผลิตได้ เราจะยก Sprint ใน Sharkly มาเป็นกลไกที่เป็นรูปธรรม และแยกข้อโต้แย้งเรื่องการวางแผนออกจากข้อเท็จจริงของผลิตภัณฑ์ให้ชัดเจน
สรุปสั้น ๆ
Sprint ใน Sharkly คือชุด Task ที่มีกรอบเวลาและเป็นของ Space หนึ่ง ๆ โดย Task ยังคงเป็นแหล่งของการลงมือทำและการพูดคุย ส่วน Sprint เข้ามาเพิ่มตารางเวลา scope และการรายงานให้ Sprints เป็นฟีเจอร์เสริมที่เปิดใช้ได้ และทำงานในสองโหมด ได้แก่ Automatic cadence ที่ Sharkly ดูแลตารางเวลาให้และยกงานที่ค้างอยู่ไปข้างหน้า กับ Manual ที่คนเป็นผู้สร้าง เริ่ม และปิด Sprint เอง การรายงานครอบคลุม scope งานที่เริ่มแล้ว งานที่ทำเสร็จ อัตราการทำเสร็จ capacity และประวัติ burnup สำหรับทีมลูกผสมระหว่างคนกับ Agent สิ่งที่เปลี่ยนไปในการวางแผนคือ Agent ทำให้ขีดความสามารถในการลงมือทำพุ่งสูงขึ้น แต่การตรวจรับยังอยู่ที่คน ดังนั้นคำมั่นใน Sprint ที่ตรงไปตรงมาจึงถูกจำกัดด้วยปริมาณงานที่เสร็จแล้วซึ่งผู้รีวิวของคุณตรวจรับได้ ไม่ใช่ปริมาณงานที่ Agent ของคุณผลิตได้
Sprint ใน Sharkly คืออะไร
Sprint หนึ่งรอบ คือชุด Task ที่มีกรอบเวลาและเป็นของ Space หนึ่ง ๆ ช่วยให้ทีมวางแผน scope ที่จดจ่อ ติดตามความคืบหน้า และตัดสินใจว่าจะทำอย่างไรกับงานที่ยังไม่เสร็จเมื่อหมดกรอบเวลา Task ยังคงเป็นแหล่งของการลงมือทำและการพูดคุย ส่วน Sprint เข้ามาเพิ่มตารางเวลา scope และการรายงานทับลงไป
เอกสารใช้คำว่า Sprint และความหมายก็ตรงกับที่ทั้งอุตสาหกรรมเข้าใจ Scrum Guide อธิบาย Sprint ว่าเป็นกรอบเวลาความยาวคงที่ที่ไอเดียกลายเป็นคุณค่า และเวอร์ชันของ Sharkly ก็สืบทอดแนวคิดนี้มา สิ่งที่ Sharkly เปลี่ยนไปคือ ใครเป็นคนลงมือทำภายในกรอบเวลานั้น
มีเส้นแบ่งสามข้อที่ทำให้แนวคิดนี้ยังคมชัด:
- Sprint เป็นของ Space เดียวเท่านั้น การเอา Task ไปใส่ใน Sprint ไม่ได้เปลี่ยนเจ้าของ Task
- Sprints เป็นฟีเจอร์เสริม เปิดใช้แยกตาม Space โดย Space ที่คิดแบบ continuous flow ก็เปิดใช้ไม่ได้เลย
- Sprint ไม่ใช่ Project และไม่ใช่ View ให้ใช้ Sprint เมื่อคำถามคืออะไรควรจะเสร็จภายในกรอบเวลาหนึ่ง ๆ ใช้ Project เมื่อผลลัพธ์อาจกินเวลาหลาย Sprint หรือหลาย Space และใช้ View เมื่อต้องการวิธีบันทึกไว้ดู Task ซ้ำ ๆ
ข้อแยกแยะข้อสุดท้ายนี้มีประโยชน์จริงในทีมลูกผสม: Project ถือผลลัพธ์ Sprint ถือคำมั่นระยะสั้น และ View ถือมุมมองที่แต่ละคนต้องใช้ในแต่ละวัน
Automatic cadence หรือโหมด Manual
เมื่อคุณเปิดใช้ Sprints ให้กับ Space คุณต้องเลือกหนึ่งในสองโหมดวงจรชีวิต การเลือกนี้เปลี่ยนพฤติกรรมของวงจรชีวิต ไม่ได้เปลี่ยนเจ้าของ Task
Automatic cadence ยกปฏิทินให้ Sharkly ดูแล คุณตั้งค่าความยาวของ Sprint ช่วง cooldown (ถ้าต้องการ) วันในสัปดาห์ที่จะเริ่ม จำนวน Sprint ในอนาคตที่ต้องดูแล เขตเวลา และกฎที่เพิ่ม Task อัตโนมัติเมื่อ Task เข้าสู่หมวดสถานะที่เลือกไว้ จากนั้น Sharkly จะสร้าง Sprint ในอนาคต เริ่มและปิดตามกำหนด และยกงานที่ยังไม่เสร็จไปข้างหน้า การเริ่ม Sprint ที่กำลังจะมาถึงก่อนกำหนดจะปิด Sprint ปัจจุบันก่อน แล้วยกงานที่ค้างอยู่ไปไว้ใน Sprint ที่กำลังเริ่ม
โหมด Manual ให้ทีมคุมวงจรชีวิตเอง คนเป็นผู้สร้าง Sprint ที่วางแผนไว้เมื่อจำเป็น เริ่ม Sprint โดยไม่เปลี่ยนวันที่ที่ตั้งไว้ รัน Sprint ที่ active มากกว่าหนึ่งรอบพร้อมกัน และเลือกได้ว่างานที่ยังไม่เสร็จจะไปที่ไหนเมื่อปิด Sprint ส่วนการสร้างอัตโนมัติ การยกงานไปข้างหน้า cooldown และกฎการเพิ่ม Task ตามสถานะ จะไม่ทำงานในโหมด Manual
| Automatic cadence | โหมด Manual | |
|---|---|---|
| ตารางเวลา | Sharkly สร้าง เริ่ม และปิด Sprint ตามจังหวะที่ตั้งค่าไว้ | คนเป็นผู้สร้าง เริ่ม และปิด Sprint เองอย่างชัดเจน |
| งานที่ยังไม่เสร็จ | ถูกยกไปยัง Sprint ถัดไปโดยอัตโนมัติ | เลือกเส้นทางตอนปิด: ไม่มี Sprint, ไปอีก Sprint หรือสร้างใหม่ |
| Sprint ที่ active พร้อมกัน | มี Sprint ปัจจุบันหนึ่งรอบตามจังหวะ | อนุญาตให้มี Sprint ที่ active มากกว่าหนึ่งรอบ |
| การรับ Task เข้ามา | กฎตามหมวดสถานะสามารถเพิ่ม Task ระหว่างกรอบเวลาได้ | คนเป็นผู้เพิ่ม Task ผ่านการวางแผน รายการ Task หรือฟิลด์ Sprint |
| เหมาะกับ | จังหวะที่สม่ำเสมอซึ่งทีมอยากให้มีคนดูแลกลไกให้ โดยไม่ต้องมีพิธีกรรม | รอบงานที่ไม่สม่ำเสมอ กรอบเวลาที่อิงการ release หรือความพยายามที่คาบเกี่ยวกัน |
คู่การตัดสินใจที่ตรงไปตรงมาคือ: ใช้ Automatic cadence เมื่อทีมของคุณทำงานเป็นจังหวะสม่ำเสมอและอยากให้มีคนดูแลกลไกให้ ใช้ Manual เมื่อรอบงานของคุณไม่สม่ำเสมอ เมื่อกรอบเวลาถูกกำหนดด้วยการ release มากกว่าปฏิทิน หรือเมื่อคุณต้องมี Sprint ที่ active สองรอบพร้อมกัน การสลับมาใช้ Manual จะเก็บ Sprint ที่มีอยู่ไว้ แต่หยุดการจัดตารางเวลาอัตโนมัติ ส่วนการปิดใช้ Sprints ทั้งหมดจะปิด Sprint ที่ active ลบ Sprint ในอนาคตทิ้ง และเก็บข้อมูลที่เสร็จแล้วไว้สำหรับการรายงาน
Task เข้า ออก และข้าม Sprint ได้อย่างไร
Sprints แสดงในห้าสถานะ ได้แก่ Current, Upcoming, Planned, Completed และ Canceled โดย Sprint ที่ Completed และ Canceled จะย้ายไปยังคลังเก็บของ Space แทนที่จะไปรกอยู่ในรายการวางแผนที่ยัง active
คุณเพิ่มหรือย้าย Task ได้ผ่านฟิลด์ Sprint ของมัน จากรายการ Task หรือระหว่างการวางแผน Sprint มีสองกฎที่สำคัญกว่าที่เห็น
ข้อแรก Task ไม่มี Sprint เลยก็ได้ นั่นคือที่อยู่ปกติของงานใน Backlog และของ Task ที่ยังไม่ผูกมัดกับกรอบเวลาใด ๆ
ข้อสอง การเพิ่ม Task เข้า Sprint ไม่ได้เปลี่ยนสถานะของมัน นี่คือกฎที่ทีมลูกผสมต้องซึมซับให้ได้ เพราะใน Sharkly หมวดสถานะ Backlog คือสถานะพักงาน การสร้าง Task หรือมอบหมาย Agent ขณะที่ Task ยังอยู่ใน Backlog จะไม่เริ่มการลงมือทำ การย้าย Task ออกจาก Backlog ไปยังสถานะที่พร้อมทำงานต่างหากที่จะเริ่ม Agent ที่ได้รับมอบหมายได้ ดังนั้นการวางแผน Sprint กับการปล่อยให้ลงมือทำจึงเป็นคันโยกคนละอัน คุณวางแผน Sprint ทั้งรอบในวันจันทร์ได้ โดยที่ Agent ถูกมอบหมายไว้แล้ว และจะไม่มีอะไรทำงานจนกว่าแต่ละ Task จะถูกย้ายไปยังสถานะที่พร้อมอย่างตั้งใจ จากนั้น Automations ที่ทำงานตามการเปลี่ยนสถานะก็สามารถรับช่วงการเปลี่ยนสถานะที่คุณอยากทำให้เป็นมาตรฐานได้
อีกหนึ่งกฎที่ช่วยปกป้องประวัติของคุณ: เพิ่ม Task เข้า Sprint ก่อนหน้าได้เฉพาะ Task ที่เสร็จแล้วเท่านั้น เพื่อให้แก้ไขข้อมูลย้อนหลังได้โดยไม่ต้องเอางานที่ยังไม่เสร็จไปใส่ในช่วงเวลาที่ปิดไปแล้ว
เรื่องวันที่นั้น ทั้งวันเริ่มและวันสิ้นสุดของ Sprint ที่วางแผนไว้แก้ไขได้ ส่วน Sprint ที่ active นั้นวันเริ่มคงที่ แต่เปลี่ยนวันสิ้นสุดได้
รายงาน Sprint บอกอะไรคุณได้บ้าง
การรายงาน Sprint ประกอบด้วยจำนวน Task และเมื่อ Space เปิดใช้การประเมินเวลา ก็จะมีผลรวมของแต้มประเมิน ครอบคลุมหกตัวเลข ได้แก่ scope งานที่เริ่มแล้ว งานที่ทำเสร็จ อัตราการทำเสร็จ capacity และประวัติ burnup
Capacity สมควรดูให้ละเอียดขึ้น เพราะเป็นตัวเลขที่บทสนทนาการวางแผนมักยึดเป็นหลัก Sharkly คำนวณมันจาก velocity ของ Sprint ที่เพิ่งทำเสร็จเมื่อมีประวัติมากพอ มิฉะนั้นจะถอยไปใช้การประเมินจากขนาดของ Space เอกสารแนะนำให้มองมันเป็นข้อมูลตั้งต้นในการวางแผน ไม่ใช่หลักประกัน และสำหรับทีมลูกผสม ข้อควรระวังนี้ไม่ใช่คำพูดตามพิธีการ เพราะ velocity ที่วัดจากกลุ่มคนล้วน ๆ จะหยุดทำนายอะไรได้ทันทีในสัปดาห์ที่คุณเพิ่ม Agent สามตัวเข้ามา ประวัติ burnup มักเผยอะไรมากกว่า ถ้า scope ทำเสร็จรวดเดียวในช่วงต้นแล้วเส้นกราฟแบนลง นั่นแปลว่า Agent ของคุณลงมือทำเสร็จแล้ว และผู้รีวิวของคุณใช้เวลาที่เหลือของ Sprint ตามเก็บงาน
ข้อจำกัดของทีมลูกผสม: วางแผนเพื่อการรีวิว ไม่ใช่เพื่อการลงมือทำ
ทุกอย่างในหัวข้อนี้เป็นข้อโต้แย้งเรื่องการวางแผน ไม่ใช่ฟีเจอร์ของผลิตภัณฑ์ Sharkly ให้กลไก Sprint ตามที่กล่าวมาข้างต้น ส่วนจะโหลดงานเข้า Sprint มากแค่ไหนเป็นการตัดสินใจเชิงดุลยพินิจ
เริ่มจากการแบ่งงานกันทำ Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนเป็นผู้กำหนดทิศทาง ให้อำนาจ และตรวจรับผลลัพธ์ ในงาน agentic coding ทุกสิ่งระหว่างการกำหนดทิศทางกับการตรวจรับสามารถมอบหมายต่อได้ แต่การตรวจรับยังคงเป็นของคน Agent ที่ทำ Task เสร็จแล้วยังไม่นับว่าเสร็จในความหมายใด ๆ ที่ Sprint ของคุณควรนับ เพราะ diff ผลการตรวจสอบ และข้อจำกัดที่รู้อยู่จะถูกส่งกลับมาที่ Task และยังต้องมีคนอ่านสิ่งเหล่านั้นแล้วตัดสินใจว่าจะตรวจรับ ขอให้แก้ไข หรือตัดสินใจ merge
ทีนี้ลองคิดเลขดู สมมติทีมห้าคนเพิ่ม Agent เข้าไปแล้วปริมาณงานที่ลงมือทำได้เพิ่มเป็นสามเท่า ปริมาณงานที่รีวิวได้ไม่ได้เพิ่มเป็นสามเท่าด้วย เพราะยังเป็นคนห้าคนเดิมที่ต้องรับผิดชอบ และแต่ละความเปลี่ยนแปลงที่ตรวจรับต้องใช้สมาธิจริง ๆ ถ้าคุณวางแผน Sprint โดยอิงจากขีดความสามารถในการลงมือทำ ส่วนเกินที่ได้มาจะไม่กลายเป็นคุณค่าที่ส่งมอบ มันจะกลายเป็นคิวของงานที่ยังไม่ถูกรีวิว และความเปลี่ยนแปลงที่ยังไม่ถูกรีวิวก็คือของค้างสต็อก ไม่ใช่ความคืบหน้า ที่แย่กว่านั้นคือ Sprint ที่กำลังจะปิดจะกดดันให้ผู้รีวิวเลือกทางลัดที่ทำให้การพัฒนาที่มี Agent หนาแน่นเป็นเรื่องอันตราย นั่นคือการตรวจรับผลลัพธ์โดยไม่อ่านมันเลย
ดังนั้นกลับคำถามการวางแผนเสียใหม่ แทนที่จะถามว่าทีมลงมือทำงานได้มากแค่ไหนในสองสัปดาห์ ให้ถามว่าคนในทีมของคุณตรวจรับงานที่ Agent ทำเสร็จได้มากแค่ไหนในสองสัปดาห์ ในทางปฏิบัติ สิ่งนี้เปลี่ยนพฤติกรรมสี่อย่าง:
- ประเมินต้นทุนการรีวิว ไม่ใช่แค่ต้นทุนการสร้าง Task ที่ Agent ทำได้ง่าย ๆ อาจยังตรวจรับได้ยาก
- จำกัดงานที่ทำเสร็จแล้วแต่ยังไม่ถูกตรวจรับให้ทำงานพร้อมกันได้ไม่เกินเพดาน ตัดสินใจว่าผู้รีวิวแต่ละคนตรวจรับ Task ได้จริงกี่ชิ้นต่อ Sprint แล้วหยุดวางแผนเมื่อเกินผลรวมนั้น นี่เป็นข้อตกลงในการทำงาน ไม่ใช่การตั้งค่าใน Sharkly แต่ตัวชี้วัดการทำเสร็จจะบอกคุณเองว่าเกินไปแล้ว
- ปล่อยให้ลงมือทำอย่างตั้งใจ เพราะ Backlog เป็นสถานะพักงาน คุณจึงกระจายจุดเริ่มงานได้ เพื่อให้งานที่เสร็จแล้วไหลมาในจังหวะที่ผู้รีวิวรับไหว แทนที่จะมาพร้อมกันหมดในวันที่สอง
- อ่านอัตราการทำเสร็จเป็นตัวเลขของการรีวิว เมื่อกราฟ burnup แบนลงขณะที่ Agent ว่างงาน ข้อจำกัดได้ประกาศตัวออกมาแล้ว นั่นคือสัญญาณให้เพิ่มผู้รีวิวหรือรับปากงานน้อยลง ไม่ใช่ให้เพิ่ม Agent
ทั้งหมดนี้ไม่ได้ทำให้ Agent ช้าลงเลย มันแค่เล็งเป้าให้ Agent เท่านั้น Sprint ที่วางแผนโดยอิงปริมาณงานที่ตรวจรับได้จะส่งมอบทุกอย่างที่รับปากไว้ และไม่เคยขอให้ใครอนุมัติโค้ดที่ตัวเองไม่มีเวลาอ่าน
วางแผน Sprint แบบลูกผสม ทีละขั้นตอน
- เปิดใช้ Sprints ให้กับ Space แล้วเลือกโหมด จังหวะที่สม่ำเสมอของทีมเหมาะกับ Automatic cadence ส่วนงานที่ขับเคลื่อนด้วยการ release เหมาะกับ Manual
- กำหนดรูปร่างของ scope ดึง Task ที่เป็นตัวเลือกเข้า Sprint ที่กำลังจะมาถึงผ่านการวางแผน Sprint หรือฟิลด์ Sprint ส่วนงานที่ยังไม่รับปากให้ปล่อยไว้โดยไม่มี Sprint
- มอบหมายทั้งสองส่วนของแต่ละ Task Sharkly แยกความรับผิดชอบของคนออกจากการลงมือทำของ Agent โดยคนจะอยู่ในชุดผู้รับผิดชอบ ส่วน Agent หรือ Crew จะอยู่ในช่องการลงมือทำเพียงช่องเดียว การเปลี่ยนอย่างหนึ่งไม่เคยเปลี่ยนอีกอย่างหนึ่ง
- เขียน Task ที่ Agent ลงมือทำได้ คำอธิบายควรมีเป้าหมาย ข้อจำกัด และเกณฑ์การตรวจรับที่คนใหม่หรือ Agent ต้องรู้เพื่อเดินหน้าต่อ
- ปล่อยงานตามจังหวะการรีวิว ย้าย Task ออกจาก Backlog เมื่อผู้รีวิวมีช่องว่างรับงานได้
- ปิด Sprint อย่างตั้งใจ ในโหมด Manual ให้เลือกว่างานที่ยังไม่เสร็จทุกชิ้นจะไปที่ไหน ใน Automatic cadence ให้ดูว่ามีอะไรถูกยกไปข้างหน้า แล้วถามว่ามันถูกกำหนด scope ใหญ่เกินไปหรือถูกรีวิวช้าเกินไป
วินัยที่กว้างขึ้นในการทำงานแบบนี้มีอยู่ในบทหลักของเราเรื่อง AI agent project management ส่วน Sprint คือชิ้นส่วนที่มีกรอบเวลาของระบบนั้น
ถ้าตอนนี้ Sprint ของคุณอยู่ใน Jira
คุณไม่จำเป็นต้องรื้อกระบวนการใหม่ทั้งหมดเพื่อลองทำสิ่งเหล่านี้ การเชื่อมต่อกับ Jira ของ Sharkly นำเข้าข้อมูล Sprint จาก Jira ได้ และเมื่อเปิดใช้การนำเข้า Sprint แล้ว Space ปลายทางสามารถสลับไปใช้โหมด Jira Sprint ได้ ทำให้จังหวะที่ทีมคุณใช้อยู่แล้วย้ายมาด้วย แทนที่จะเริ่มจากศูนย์ ส่วนคำแนะนำแบบทีละขั้นตอนเรื่องการมอบหมายตั๋ว Jira ให้ AI Agent แสดงแนวคิดเดียวกันในระดับตั๋วเดียว และเอกสารของ Sharkly ครอบคลุมการตั้งค่า Sprint และการเชื่อมต่อกับ Jira ไว้อย่างละเอียด
เริ่มจากสิ่งที่เล็กกว่าการย้ายระบบทั้งหมด: เปิดใช้ Sprints ใน Space เดียว วางแผนหนึ่งช่วงสองสัปดาห์โดยอิงขีดความสามารถในการตรวจรับจริงของผู้รีวิว แล้วเทียบกราฟ burnup กับรอบล่าสุดที่ใช้คนล้วน ๆ
คำถามที่พบบ่อย
จำเป็นต้องใช้ Sprints ใน Sharkly ไหม
ไม่จำเป็น Sprints เป็นฟีเจอร์เสริมที่เปิดใช้แยกตาม Space โดย Space ที่ชอบทำงานแบบ continuous flow จะไม่เปิดเลยก็ได้ และแม้เปิดใช้ Sprints แล้ว Task ก็ยังไม่มี Sprint ได้ ซึ่งเป็นสถานะปกติของงานใน Backlog
Task ที่ยังไม่เสร็จจะเป็นอย่างไรเมื่อ Sprint จบลง
ใน Automatic cadence Sharkly จะปิด Sprint ตามกำหนดและยกงานที่ยังไม่เสร็จไปยังรอบถัดไป ส่วนในโหมด Manual ขั้นตอนการปิดจะถามคุณว่างานที่ยังไม่เสร็จควรไปที่ไหน: ไม่มี Sprint, ไปยัง Sprint อื่นที่ active หรือกำลังจะมาถึง หรือไปยัง Sprint ที่สร้างขึ้นใหม่
Agent ทำงานใน Task ของ Sprint ได้โดยอัตโนมัติไหม
Agent หรือ Crew ที่ถูกตั้งเป็นผู้ลงมือทำของ Task สามารถทำงานนั้นได้ แต่การอยู่ใน Sprint เพียงอย่างเดียวไม่เคยทำให้อะไรเริ่มทำงาน Backlog เป็นสถานะพักงาน ดังนั้นการมอบหมาย Agent ให้ Task ที่อยู่ใน Backlog จะไม่เริ่มการลงมือทำ การย้าย Task ไปยังสถานะที่พร้อมต่างหากที่จะเริ่มการทำงานได้ การแยกแบบนี้ทำให้คุณวางแผน Sprint ทั้งรอบได้ก่อน แล้วค่อยปล่อยให้ลงมือทำตามจังหวะที่ผู้รีวิวรับไหว
Sharkly คำนวณ capacity ของ Sprint อย่างไร
Capacity ใช้ velocity ของ Sprint ที่เพิ่งทำเสร็จเมื่อมีประวัติมากพอ มิฉะนั้นจะถอยไปใช้การประเมินจากขนาดของ Space เอกสารแนะนำให้มองมันเป็นข้อมูลตั้งต้นในการวางแผน ไม่ใช่หลักประกัน ซึ่งยิ่งสำคัญเป็นทวีคูณสำหรับทีมลูกผสม เพราะ velocity วัดทั้งระบบ ไม่ได้วัดจุดคอขวดอย่างการรีวิวที่อยู่ข้างใน
เพิ่ม Task เข้าไปใน Sprint ที่จบไปแล้วได้ไหม
เพิ่ม Task เข้า Sprint ก่อนหน้าได้เฉพาะ Task ที่เสร็จแล้วเท่านั้น เพื่อรองรับการแก้ไขข้อมูลย้อนหลัง เช่น การให้เครดิตงานที่ทำเสร็จภายในช่วงเวลานั้นแต่ไม่ได้บันทึกไว้ โดยไม่ต้องเอางานที่ยังไม่เสร็จไปใส่ในช่วงเวลาที่ปิดไปแล้ว
