จะทำอย่างไรกับการประเมินเรื่องราวที่ไม่สมบูรณ์

ฉันเป็นส่วนหนึ่งของทีมพัฒนาที่ค่อนข้างใหม่Scrumสมมติว่าในตอนท้ายของการวิ่งเรื่องราวใหญ่ ๆ สองสามเรื่องนั้นไม่ว่าin progressจะacceptedโดย PO หรือไม่ก็ตาม

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

ถ้าเป็นเช่นนั้นพวกเขาควรได้รับการประเมินอีกครั้ง? ในมุมมองของฉันงานที่เหลือในเรื่องราวของผู้ใช้เหล่านี้อาจน้อยหรือมาก? ถ้าไม่ทำไมล่ะ

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

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

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

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

ถ้าเป็นเช่นนั้นพวกเขาควรได้รับการประเมินอีกครั้ง? ในมุมมองของฉันงานที่เหลือในเรื่องราวของผู้ใช้เหล่านี้อาจน้อยหรือมาก? ถ้าไม่ทำไมล่ะ

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

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

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

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