ทีมกำลังประเมินแต้มเรื่องราวธุรกิจต้องการเวลาที่แท้จริง

ฉันแน่ใจว่านี่ไม่ใช่เรื่องแปลก เรามีทีมการต่อสู้สองทีมที่ทำงานได้ดีในการประเมินเรื่องราวของผู้ใช้โดยใช้จุดเรื่องราว (กลุ่มดาวในทีมปัจจุบันมีอายุประมาณ 8 เดือนเท่านั้นแม้ว่าสมาชิกในทีมจะมีประสบการณ์การต่อสู้หลายปี) แต่มันยากสำหรับส่วนธุรกิจของ บริษัท ที่เกี่ยวข้องกับเรื่องราวของผู้ใช้ พวกเขาต้องการหน่วยเวลาจริง (หรือ "สูตรในการแปลงคะแนนเรื่องราวเป็นชั่วโมง") เพื่อให้พวกเขาสามารถวางแผนได้ว่าเมื่อใดที่สิ่งต่างๆจะพร้อม ( "เราจำเป็นต้องรู้เมื่อเราสามารถบอกลูกค้าได้ว่า Feature X จะอยู่ในการผลิต " )

ฉันและผู้นำการต่อสู้ของฉันได้อธิบายว่า "ไม่มีความสัมพันธ์ที่ชัดเจนระหว่างจุดเรื่องราวและเวลาที่เกิดขึ้นจริง" และ "จุดเรื่องราวใช้เพื่อกำหนดจำนวนทีมที่สามารถวิ่งได้" และฉัน คุณสามารถเดาได้ว่าพวกเขาพึงพอใจแค่ไหนกับคำตอบนั้น พวกเขายังต้องการทราบตามเวลาในปฏิทินเมื่อเราจะไปที่เรื่องราวผู้ใช้ครั้งที่ 27 ใน Backlog

ไม่ว่าในกรณีใดฉันได้รวบรวมสถิติบางส่วนและการประเมิน SP ของเราแปลเป็นผลลัพธ์ที่ใช้เวลาจริงที่แตกต่างกันอย่างดุเดือด (วัดโดยซอฟต์แวร์ scrum board ของเราซึ่งติดตามจำนวนตั๋วที่ใช้ในคอลัมน์ "กำลังทำงาน" ) สำหรับเรื่องราวของผู้ใช้ 1-SP นั้นแน่นอนว่ามีอคติอย่างหนักในช่วงเวลาสั้น ๆ (โดยมีการระเบิดขึ้นเป็นครั้งคราว) แต่โดยเฉพาะอย่างยิ่งสำหรับเรื่องราว 2-SP พวกเขาอยู่ทั่วทุกที่: มีปัจจัย 20 ระหว่างความสำเร็จ "เร็วที่สุด" และ "ช้าที่สุด" สำหรับเรื่องราว 3, 5 และ 8-SP สเปรดก็ยิ่งมากกว่า 2 เท่า

สิ่งนี้บ่งชี้ว่า (a) ทีมจำเป็นต้องมีความสอดคล้องกันมากขึ้นในการประเมินเรื่องราวของผู้ใช้ของ (สิ่งที่ควรจะเป็น) ความซับซ้อนที่คล้ายกันและ (b) ทีมต้องปรับปรุงความแม่นยำในการรายงานเวลา (เช่น "ทำงานต่อ" เมื่อพวกเขากำลังประชุมนัดอาหารกลางวันหรือเล่นฟุตบอล)

ฉันมีแผนที่จะปรับปรุงทั้ง (ก) และ (ข) แต่ฉันรู้สึกว่ายังไม่เพียงพอที่ธุรกิจคาดหวังว่า "เป็นรูปธรรมมากขึ้น" กว่าสิ่งที่ริเริ่มเหล่านี้จะให้ผล

อะไรคือกลยุทธ์ที่ดีในการดึงดูดใจทางธุรกิจเพื่อที่พวกเขาจะไม่เข้าไปยุ่งเกี่ยวกับวิธีการทำงานของเรามากเกินไป (เช่นโดยกำหนดให้ใช้การติดตามเวลาแยกต่างหากซึ่ง IMHO จะเป็นใบ้เพราะในกรณีใด ๆ จะมีความแม่นยำน้อยกว่า การติดตาม "อัตโนมัติ" ปัจจุบัน) ในขณะที่ในเวลาเดียวกันอนุญาตให้พวกเขาได้รับมาตรการบางอย่างสำหรับเมื่อเรื่องราวจะทำ?

(ในอดีตในระหว่างการวางแผนเราได้แบ่งเรื่องราวของผู้ใช้เป็นไอเท็มงานซึ่งถูกประเมินเป็นรายบุคคลในเวลาทำงานจริงแต่สิ่งที่ฉันกำลังพูดถึงที่นี่คือเรื่องราวของผู้ใช้ในบันทึกด้านหลังที่จะไม่มีรายละเอียดหรือการแบ่งระดับ -ลง.)

อัปเดต:ผู้จัดการของฉันมีลางสังหรณ์ว่ามีการแจกแจงเส้นโค้งแบบเบลล์ของชั่วโมงที่ใช้ไปต่อเรื่อง แต่ข้อมูลที่ฉันเรียงไว้และกราฟที่เขาทำให้เขาไม่เข้าใจความคิดนั้นอย่างละเอียด :-)

คุณถูกต้องไม่มีสูตรการแปลงคะแนนเรื่องราวเป็นชั่วโมง คุณสามารถแปลงเมตรเป็นฟุตได้โดยที่ไม่ต้องเสียค่าใช้จ่าย แต่อย่างใด แต่คุณไม่สามารถบอกได้ว่าเรื่องราว 3 จุดจะใช้เวลา X ชั่วโมงดังนั้นเรื่องราว 5 จุดจะใช้เวลา Y ชั่วโมง (แก้หา Y)

HorusKol ได้สัมผัสในส่วนต่อไปนี้ ความเร็วในการวิ่งของคุณในฐานะทีมสามารถช่วยในการส่งมอบระยะยาว สมมติว่าทีมของคุณอยู่ที่ 50 คะแนนต่อการวิ่งหนึ่งครั้งและการวิ่งแต่ละครั้งจะใช้เวลา 2 สัปดาห์ ดังนั้น 50 คะแนนต่อการวิ่งคูณด้วย 50 สัปดาห์ในหนึ่งปี (สมมติว่าคนใช้เวลา 2 สัปดาห์ในการหยุดพัก) จากนั้นทีมปัจจุบันของคุณสามารถทำคะแนนได้สูงสุด 2,500 คะแนนใน 12 เดือน

ดังนั้นธุรกิจขึ้นอยู่กับคุณด้วย 170 คะแนนมูลค่าเรื่องราวและมหากาพย์ หารด้วยความเร็วประวัติศาสตร์ของทีม 50 คะแนน (ค่าเฉลี่ยของการวิ่งทุกครั้ง) และคุณได้รับ 3.4 การวิ่ง เนื่องจากเราทำการประมาณให้ปัดขึ้นเป็น 4 sprints: 8 สัปดาห์ สองเดือนโดยทั่วไป ฉันชอบที่จะใช้ 3-4 sprints ล่าสุดและใช้เวลาประมาณ สมมติว่าทีมของคุณในการวิ่ง 3 ครั้งสุดท้ายทำไปแล้ว 53, 67 และ 55 คะแนนตามลำดับ มันไปได้ถึง 58-ish points ซึ่งในอัตรานั้นคือ 2.9 sprints - โดยทั่วไปแล้ว 3 sprints ดูเหมือนว่าไทม์ไลน์ของคุณสำหรับคะแนน 170 เหล่านั้นดูเหมือนว่า 6 ถึง 8 สัปดาห์

บอกธุรกิจ 2 เดือน อย่าบอกพวกเขา 6-8 สัปดาห์เพราะพวกเขาจะได้ยิน "6 สัปดาห์" อย่าแม้แต่จะบอกพวกเขา 8 สัปดาห์เพราะเดือนส่วนใหญ่มีพวกเขาอยู่ประมาณ 4.5 สัปดาห์และเมื่อคนได้ยิน "4 สัปดาห์" พวกเขาคิดทันที "1 เดือน" เมื่อค่าประมาณถึง 4 สัปดาห์จะกลายเป็น 1 เดือน จากนั้นแค่ทำงานเป็นเดือน หากคุณเข้าชมหนึ่งปีหรือมากกว่านั้นอย่างสุจริตอย่าคาดการณ์งานนั้น มันไม่มีจุดหมาย มากเกินไปสามารถเปลี่ยนแปลงได้ในหนึ่งปี

ฉันพบว่านี่เป็นวิธีที่แม่นยำในการแปลงคะแนนเรื่องราวเป็นชั่วโมง ...

คุณจะได้รับความแปรปรวนในระยะเวลาที่ต้องใช้ในการสร้างเรื่องราวให้เสร็จสมบูรณ์ นักพัฒนาบางคนทำงานได้เร็วกว่าคนอื่น ๆ การใส่จุดเรื่องราวทั้งหมดลงในชามและเปิดเครื่องปั่นเพื่อทำงานด้วยค่าเฉลี่ยจะช่วยลดความไม่สอดคล้องเหล่านั้น

โอ้และอย่าลืมส่วนที่สำคัญที่สุด:

ปัดขึ้น เสมอ.

คุณอาจมีการแปลงโดยเนื้อแท้จากจุดเรื่องราวไปเป็นเวลาโดยประมาณ - คุณตัดสินใจได้อย่างไรว่าคุณเลือกงานที่เพียงพอสำหรับการวิ่งของคุณ คุณอาจพูดอะไรบางอย่างเช่น "ทีมสามารถจัดการ 20 คะแนน (หรือ 40 คะแนนหรืออะไรก็ได้) ต่อสัปดาห์" หลังจากการวิ่งสองสามครั้งคุณควรจะสามารถแก้ไขได้ตามความสมบูรณ์ดังนั้นตอนนี้ก็คือ 15 หรือ 25 (หรือ 35 หรือ 50 หรือ ... ) ชี้การวิ่ง - นี่คือความเร็วของทีมของคุณ

สำหรับเรื่องราวของผู้ใช้ 1-SP นั้นแน่นอนว่ามีอคติอย่างหนักในช่วงเวลาสั้น ๆ (โดยมีการระเบิดขึ้นเป็นครั้งคราว) แต่โดยเฉพาะอย่างยิ่งสำหรับเรื่องราว 2-SP พวกเขาอยู่ทั่วทุกที่: มีปัจจัย 20 ระหว่างความสำเร็จ "เร็วที่สุด" และ "ช้าที่สุด" สำหรับเรื่องราว 3, 5 และ 8-SP สเปรดก็ยิ่งมากกว่า 2 เท่า

ความแตกต่างของเวลาในการทำเรื่องที่เฉพาะเจาะจงบางอย่างนั้นโอเคภายในค่าคะแนน - ความเร็วจะตรวจสอบความไม่แน่นอนนั้นโดยเฉลี่ยในประวัติศาสตร์ที่ผ่านมา

อย่างไรก็ตามคุณอาจต้องพิจารณาอย่างถี่ถ้วนในการกำหนดจุดโดยเฉพาะอย่างยิ่ง 2 ตัวชี้เหล่านั้นหากคุณมีความผันผวนมาก งานที่มีคะแนนสูงกว่านั้นไม่แน่ใจ (และควรถูกทำลาย) - แต่งานที่มีขนาดเล็กเท่ากับตัวชี้ 2 ตัวควรสอดคล้องกัน

เนื่องจากงานทั้งหมดที่ได้รับมอบหมายค่าจุดเดียวกันควรต้องการความพยายามที่คล้ายกันจึงไม่เหมาะสมที่จะมีช่วงเวลาให้เสร็จสมบูรณ์

ดังนั้นดูที่ตัวชี้ 2 ตัวซึ่งใช้เวลานานที่สุดในการย้อนหลังของคุณ ทำไมบางสิ่งบางอย่างที่น่าจะทำให้ตอนเช้ากลายเป็นคำขวัญ 10 วัน? มีบางสิ่งที่ถูกตั้งค่าสถานะในเช้าวันแรกนั้นเพื่อพูดว่า "สิ่งนี้จำเป็นต้องกลายเป็นเรื่องยิ่งใหญ่ ทันทีที่เกิดขึ้นแน่นอนงานพิเศษที่จำเป็นควรใส่ลงในมือและไม่ยุ่งเกี่ยวกับส่วนที่เหลือของการวิ่ง

และลองดูว่าทีมประเมินรายการนั้นต่ำกว่า - คุณสามารถทำสิ่งที่ดีกว่าในการตรวจสอบรายการในอนาคตได้หรือไม่

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

มันก็เหมือนกับการพยากรณ์อากาศ: ยิ่งไกลยิ่งเชื่อถือน้อย นั่นคือการเปรียบเทียบทุกคนจะเข้าใจ ข้อผิดพลาดในการประมาณเพิ่มขึ้น

ฝ่ายขายจะต้องเรียนรู้ที่จะพูดคุยในเงื่อนไขการแย่งชิงลูกค้า การแย่งชิงกันไม่สมเหตุสมผลในการแยกมันควรจะนำไปใช้ในแนวตั้งทั่วทั้ง บริษัท และควรขยายเข้าไปในอาณาจักรของลูกค้า

คุณในฐานะทีมพัฒนาควรแน่วแน่ในเรื่องนี้ คุณสามารถให้ความคาดหวังและคาดเดากับพวกเขา แต่อย่าปล่อยให้มันเป็นภาระผูกพันที่ยืดเวลาการวิ่งเพียงครั้งเดียว

ฉันทำบางสิ่งเมื่อฉันได้รับคำถามเช่นนี้

ก่อนอื่นฉันตอบคำถามเกี่ยวกับอนาคตโดยอธิบายอดีต ฉันจะพูดอะไรบางอย่างเช่นเราได้ผ่านเรื่องราวเหล่านี้ประมาณสองเรื่องต่อสัปดาห์ ดังนั้นหากไม่มีการเปลี่ยนแปลงใด ๆ เราคาดว่าจะทำเรื่อง 27 ในประมาณ 14 สัปดาห์

ประการที่สองฉันต้องการให้ลูกค้าที่เผชิญหน้ากับผู้คนรับผิดชอบตารางการซื้อขายและความเสี่ยง ฉันจะพูดอะไรเช่นจำไว้ทีมวิศวกรรมทำงานบนพื้นฐานของการประมาณการ 50/50 หากไม่มีอะไรเปลี่ยนแปลงมีโอกาส 50/50 ในฟีเจอร์ 27 พร้อมใน 14 สัปดาห์ สันนิษฐานว่าคุณไม่ต้องการรายงานสิ่งที่มีระดับความเสี่ยงนั้นให้กับลูกค้า คุณต้องการให้ฉันคำนวณประมาณการที่เรามีพูดว่า 90% มั่นใจหรือไม่? จากนั้นคุณจะต้องตรวจสอบหลักฐานทางประวัติศาสตร์ของคุณและพูดสิ่งที่ชอบ: มีโอกาส 90% ที่ 27 เรื่องจะทำได้ใน 25 สัปดาห์ที่ผ่านมาเป็น

ท้ายนี้เตือนเพื่อนร่วมงานของคุณว่าเมื่อเขาให้คำมั่นสัญญากับภายนอก บริษัท จะถูกตรึงไว้ การทำสัญญาจากภายนอกเกี่ยวกับเนื้อเรื่องหมายเลข 27 จะช่วยลดความคล่องตัวทั้งหมดของ บริษัท จากนั้นคุณจะต้องมุ่งมั่นในการดำเนินการเฉพาะอย่าง เมื่อใดก็ตามที่มีคนมาหาคุณพร้อมคำขอเปลี่ยนแปลงตอนนี้คุณต้องตอบเรามุ่งมั่นที่จะทำเรื่องราว 27 ให้เสร็จก่อนวันที่ x ฉันสามารถทำการเปลี่ยนแปลงนี้ได้เฉพาะเมื่อคุณติดต่อกับลูกค้าและบอกว่าข้อผูกมัดของเรานั้นไม่สามารถใช้ได้อีกต่อไป โดยทั่วไปการสร้างภาระผูกพันที่เฉพาะเจาะจงสำหรับการทำงานมากกว่าหนึ่งเดือนหรือมากกว่านั้นในอนาคตนั้นมาพร้อมกับปัญหามากมาย

คุณมีการแปลง (หยาบมาก) อยู่แล้ว: การ
แย่งชิงกันคือ (ปกติ) สองสัปดาห์
คุณรู้ว่าคุณสามารถทำเสร็จแล้วสมมติว่ามีประมาณ 20 เรื่องราวที่มีมูลค่าของฟีเจอร์ในช่วงสองสัปดาห์นั้น (หรือคุณจะกำหนดว่าอะไรคือฟีเจอร์และจำนวนฟีเจอร์ที่บรรจุลงในการวิ่งครั้งเดียว) และ sprints ก่อนหน้าของคุณยืนยันว่า คุณทำคะแนน 18, 21, 23, 19 และ 20 ให้เสร็จในห้าครั้งสุดท้าย)

สมมติว่าฟีเจอร์ X (และการพึ่งพาทั้งหมด) ได้รับการประเมินว่าเป็น 47 เรื่อง
ดังนั้นคุณสามารถประเมินได้ว่าหากคุณใช้การดำเนินการที่มีความสำคัญสูงสุดคุณควรใช้เวลาประมาณ 3 sprints นั่นคือ 6 สัปดาห์ (แต่ให้แน่ใจว่าการประเมินของคุณคำนึงถึงผู้ที่สามารถทำอะไรได้ - ถ้า 35 คะแนนเหล่านั้นเป็นฐานข้อมูล ใน DB Guy คุณจำเป็นต้องแก้ไขความเร็วโดยประมาณของคุณเพื่อพิจารณาสิ่งนั้น)

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

"ฟีเจอร์Yจะเสร็จเมื่อใด"
"ถ้าเราจดจ่อกับมันต่อไป ... 12 สัปดาห์"
" 12 สัปดาห์?!?คุณบอกว่าจะใช้เวลา 4"
"ใช่ แต่คุณบอกให้เราจัดลำดับความสำคัญคุณลักษณะXซึ่งเราบอกว่าคุณจะผูกทรัพยากรทั้งหมดของเราและใช้เวลา 8 สัปดาห์"
"คุณไม่สามารถทำงานกับคุณสมบัติXและคุณสมบัติYในเวลาเดียวกันได้หรือไม่"
" คร่ำครวญ "

เวลาที่กำหนดใน Sprint นั้นพูดได้ 2 สัปดาห์ คุณไม่สามารถคาดการณ์เรื่องราวที่จะเกิดขึ้นได้มากกว่า 2 sprint เช่นคุณมี sprint ปัจจุบันของคุณและ sprint ถัดไป ฉันคิดว่าคุณได้เตรียมเรื่องราวที่ถูกพูดคุยกับทีมสำหรับการวิ่งครั้งต่อไปและจัดลำดับความสำคัญโดยธุรกิจ ดังนั้นที่ดีที่สุดคุณสามารถพูดได้อย่างแน่นอนว่าเป็น 4 สัปดาห์ของการทำงาน

ทุกอย่างที่เกิน 4 สัปดาห์อาจมีการเปลี่ยนแปลงและธุรกิจสามารถสร้างแผนงานที่ไม่ได้กำหนดไว้ในชั่วโมง ที่ควรมีการวางแผนต่อการวิ่งให้พูด epic1 บางอย่าง (มหากาพย์เหมือนในกลุ่มจิราของเรื่องราวที่จัดกลุ่ม) และ epic2 ควรทำในการวิ่ง 47 และ 48 และ epic3 ควรจะทำในการวิ่ง 49. บทกวีที่ฉันประเมินประมาณชั่วโมงเอง ดูว่าหนึ่งหรือสองจะพอดีในการวิ่งระยะเวลาจะลื่นต่อไป หากคุณสมบัติไม่ทำงานธุรกิจต้องตัดขอบเขตหรือยอมรับโซลูชันที่ไม่สมบูรณ์แบบที่สามารถปรับปรุงได้ในภายหลังตามที่ต้องการ (ซึ่งควรจะว่องไว, โอบกอดความเป็นจริงแทนที่จะทำตามแผนต่อไป)

คุณสามารถสร้างแผนภูมิแกนต์ที่ดี (นั่นคือสิ่งที่ธุรกิจต้องการ) ด้วยการวิ่งในอนาคตและหัวข้อหลัก / บทกวีสำหรับผู้ที่

ฉันชอบที่จะปล่อยทุก sprint และจากนั้นฉันเตรียมปล่อยกับสิ่งที่เสร็จแล้วใน sprint (หรือสิ่งที่ลงนามในการปล่อยโดยธุรกิจแม้ว่าจะไม่สมบูรณ์) สิ่งที่ยังไม่เสร็จจะวิ่งไปวิ่งต่อไป วิธีนี้ฉันมีการส่งมอบที่คาดการณ์ได้ในระยะเวลาประมาณ 2-3 สัปดาห์ (หนึ่งสัปดาห์สำหรับการแก้ไขในที่สุดเมื่อมีการเปิดตัวผู้สมัคร)

นั่นคือประสบการณ์ของฉันกับทีมเล็ก ๆ การพึ่งพาจากภายนอกจำนวนเล็กน้อยและสิ่งที่ฉันเชื่อว่าธุรกิจสมเหตุสมผล ระยะของคุณอาจแตกต่างกันไป

สำหรับคุณสมบัติใหม่แทบเป็นไปไม่ได้ที่จะประเมินเวลาที่ต้องการ

ประสบการณ์กับการพัฒนาซอฟต์แวร์แสดงให้เห็นว่าในกรณีส่วนใหญ่มีรายละเอียดที่คุณไม่สามารถมองเห็นได้ก่อนที่จะเริ่มพัฒนา ในกรณีที่ดีที่สุด deteils เหล่านั้นอาจต้องใช้เวลาเพิ่มเติม แต่ในกรณีที่แย่ที่สุดโครงการก็อาจล้มเหลวได้เช่นกัน เหตุผลที่เป็นความซับซ้อนของการพัฒนาซอฟต์แวร์เอง

นี่คือเหตุผลที่ SCRUM เพียงประมาณความซับซ้อนของปัญหา (เรื่องราว) แต่ไม่ใช่เวลา โอกาสเดียวที่คุณมีคือการแยกคุณสมบัติที่มีความซับซ้อนสูงออกเป็นขนาดเล็ก วิธีนี้คุณสามารถลดความเสี่ยงได้

เนื่องจากการประมาณเวลาแทบเป็นไปไม่ได้จึงไม่มีสูตรการแปลงคะแนนเรื่องราวเป็นประมาณการเวลา ความเร็วอาจเป็นเพียงการประเมินที่หยาบมากเท่านั้นไม่มาก

ใน SCRUM เจ้าของผลิตภัณฑ์สามารถเปลี่ยนลำดับความสำคัญของรายการในมือก่อนการวิ่งแต่ละครั้ง ดังนั้นต้นแบบ SCRUM ไม่สามารถประมาณค่าใด ๆ สำหรับการวิ่งมากกว่าหนึ่งครั้ง เขาไม่ทราบว่าสิ่งใดที่ค้างอาจมีความสำคัญในการวิ่งครั้งต่อไป

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

ไปที่โพสต์เริ่มต้น:

คุณดีมากถ้าคุณแบ่งงานส่วนใหญ่ของคุณเป็น 1 SP ถึง 5 SP เรื่องราว การประมาณความเร็วอาจดีขึ้นถ้างานคล้ายกันและทีมของคุณจะมีประสบการณ์มากขึ้น แต่ถ้ามีชิ้นส่วนใหม่ที่ไม่เคยมีมาใหม่ในรายการใหม่คุณต้องใช้ชีวิตด้วยความไม่ถูกต้อง

เนื่องจากนักพัฒนาซอฟต์แวร์ของคุณใช้เวลากับงานที่ไม่ใช่การพัฒนา (เช่นการประชุม) คุณไม่ควรวางแผนกับการพัฒนา 8 ชั่วโมงต่อวัน แต่น้อยกว่าเช่น 6 ชั่วโมง จากนั้นคุณจะได้รับการสำรองสำหรับงานอื่น ๆ หรือสำหรับรายการงานที่ต้องใช้เวลามากขึ้น

หากเพื่อนร่วมธุรกิจของคุณต้องการประมาณการที่แม่นยำ (ซึ่งขัดแย้งกับตัวเอง) ให้อธิบายปัญหาที่เกิดขึ้นโดยธรรมชาติของการพัฒนาซอฟต์แวร์ จากนั้นแสดงให้เห็นถึงข้อดีของวิธีการที่คล่องตัว