Scrum ทำงานอย่างไรเมื่อคุณมีหลายโครงการ [ปิด]

ฉันอ่านประโยชน์และกระบวนการของ Scrum ได้ดีพอสมควร ฉันได้รับแนวคิดเกี่ยวกับสินค้าที่ค้างส่งแผนภูมิที่ถูกทำลายการทำซ้ำการใช้เรื่องราวของผู้ใช้และแนวคิดอื่น ๆ ของ "เฟรมเวิร์ก" ของ Scrum

ด้วยเหตุนี้ ... ฉันจึงทำงานให้กับ บริษัท พัฒนาเว็บไซต์ที่จัดการหลายโครงการในคราวเดียวโดยมีสมาชิกในทีมหกคนซึ่งประกอบกันเป็น "ทีมผู้ผลิต"

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

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

ไม่มีเหตุผลที่สินค้าค้างส่งและงานในมือของ sprint จะต้องมาจากโครงการเดียวแม้ในโครงการเดียวจะมีหน่วยงานที่ไม่ต่อเนื่องซึ่งเหมือนโครงการแยกกัน - UI, ชั้นธุรกิจ, สคีมาฐานข้อมูล ฯลฯ โดยเฉพาะอย่างยิ่งการพัฒนาซอฟต์แวร์สำหรับองค์กรเป็นเช่นนี้ซึ่งคุณมีฐานรหัสจำนวนมากที่ทุกคนต้องดำเนินการ กระบวนการ Scrum - การประชุมคำถามแผนภูมิเบิร์นดาวน์ ฯลฯ - ทั้งหมดทำงานไม่ว่าจะเป็นโครงการเดียวหรือหลายโครงการ

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

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

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

กฎข้อหนึ่งที่จะต้องปฏิบัติตามในบริบทดังกล่าวคือ ห้ามเปลี่ยนเนื้อหา Sprint ระหว่าง Sprint หากจำเป็นคุณสามารถลดการทำซ้ำให้สั้นลงเหลือสองหรือสามสัปดาห์เพื่อลดความเสี่ยงที่จะต้องเพิ่มรายการเร่งด่วนใน Sprint ปัจจุบัน

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

สิ่งที่ควรทราบอีกประการหนึ่งคือการดำเนินโครงการควบคู่กันไปจะทำลายตารางเวลาของคุณ พิจารณาสิ่งนี้: เพื่อความเรียบง่ายสมมติว่าเรามี 5 โครงการที่ใช้ทีมเดียวกันและเริ่มในวันเดียวกัน แต่ละโครงการต้องใช้ความพยายาม 3 ครั้งต่อเดือนในกรณีที่ดีที่สุดที่ทำงานคู่ขนานกันคุณจะดำเนินการให้เสร็จสิ้นในครั้งเดียวและจะใช้เวลา 15 เดือน ความเร็วของคุณจะกลายเป็นครีมเพราะคุณทำได้เพียง 1/5 ของความพยายามหนึ่งเดือนในการวิ่งครั้งเดียว นอกจากนี้คุณจะทำการประชุมสาธิต 5 ครั้งในเวลาเดียวกัน สถานการณ์สมมติที่ดีที่สุดคือคุณส่งมอบโครงการ 5 โครงการใน 15 เดือนและการแข่งขันของคุณจะอ้างว่าพวกเขาสามารถทำงานเดียวกันได้ใน 3 ทีมของคุณที่ประเมินว่าครบกำหนดจะต้องทนทุกข์ทรมานเพราะพวกเขาจะพิจารณาได้เพียง 20% ของแรงงานที่มีอยู่ คุณอาจพบว่าคุณไม่สามารถทำงานบางอย่างในการวิ่งครั้งเดียวได้ หากคุณต้องเปลี่ยนจำนวนโปรเจ็กต์ที่กำลังดำเนินการจาก 5 โปรเจ็กต์ทีมของคุณจะต้องปรับเปลี่ยนนิสัยการประเมินซึ่งจะทำลายประสิทธิภาพของทีม นอกจากนี้ทีมของคุณจะพบว่าการจัดระเบียบด้วยตนเองทำได้ยากเมื่อการมอบหมายงานใหม่อาจต้องใช้การสร้างสภาพแวดล้อมการพัฒนาใหม่ก่อนที่จะเริ่มงานได้

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

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

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

ฉันอยู่ในสถานการณ์ที่แม่นยำนี้

หากคุณมีเจ้าของผลิตภัณฑ์รายเดียวในโครงการต่างๆแล้ว Phillipe ก็ถูกต้องอย่างแน่นอน การวิ่งหนึ่งครั้งกับทีมเดียวควรทำงานได้ดี

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

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

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

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

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

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

สิ่งที่น่าคิด ...

ฉันคิดว่า anopres ถูกต้อง: วิธีที่ดีที่สุดคือหลีกเลี่ยงหลายโครงการในเวลาเดียวกันด้วยการต่อสู้ ทำทุกอย่างเพื่อให้มั่นใจว่าการวิ่งคู่ขนานมากเกินไปไม่ได้ผล

ให้เราสมมติ 5 โครงการแต่ละประมาณ 3 เดือนสำหรับทีมกับ 5 คน

แนวทางที่ 1: แต่ละคนทำงานในโครงการเดียวในทีม

• ความเร็วในการจัดส่ง 1/5 ต่อโครงการให้ 15 เดือนในการจัดส่งสำหรับทุกโครงการ
• ทุกคนมีความเชี่ยวชาญ แต่เฉพาะในโครงการของตัวเอง
• ไม่มีสปิริตของทีม

วิธีการวิ่ง 2: 1 ต่อโครงการสลับโครงการ

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

เข้าใกล้ 3: 5 โครงการในการวิ่งครั้งเดียว

• ต้องการการแบ่งงานที่ละเอียดมากเกินไปเพื่อให้เข้ากับการวิ่ง
• การสร้างที่เพิ่มขึ้นน้อยมากต่อโครงการ
• ส่งมอบโครงการแรกหลังจากประมาณ 12-15 เดือน

แนวทางที่ 4: แนะนำ - งานต่อเนื่อง

• ทีมทำงานในโครงการเดียวหลังจากโครงการ
• โครงการแรกเริ่มต้นและส่งมอบหลังจาก 3 เดือน
• โครงการที่สองเริ่มต้นหลังจากเดือนที่ 3 ส่งมอบหลังจากเดือนที่ 6
• ...
• โครงการที่ 5 เริ่มต้นหลังจากเดือนที่ 12 ส่งมอบหลังจากเดือนที่ 15
• ทีมงานให้ความสำคัญกับโครงการการวิจัยอย่างเข้มข้นและการทำงานร่วมกันกับลูกค้า
• ทั้งทีมมีความรู้ทั่วไปเกี่ยวกับโครงการทั้งหมด
• ไม่ต้องเสียเวลากับการสลับบริบท
• ต้องการความร่วมมือในทีมที่ดี (ความขัดแย้งอาจทำให้การส่งช้าลง)

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

แล้ว Backlog กรูมมิ่งล่ะ? หากทีมทำงานในโปรเจ็กต์เดียวในคราวเดียวที่ง่าย - ทุกคนจะเข้าร่วม หากมีหลายโปรเจ็กต์เราอาจต้องมอบหมายให้คนโสดแยกเซสชั่นกรูมมิ่ง (ไม่เกี่ยวข้องกับทีมเต็มทีม)

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

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

ขอแสดงความนับถืออดัม

อย่างที่ @Chris กล่าวว่าโครงการปกติจะมีโครงการย่อยอยู่ภายใน คุณมีงานในมือเพียงรายการเดียว

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

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

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

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

ฉันยังคงพยายามหาวิธีที่ดีที่สุดในการทำเช่นนี้ แต่นี่คือสิ่งที่เรากำลังผลักดันในตอนนี้ ฉันหวังว่ามันจะช่วยได้

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

ฉันขอแนะนำให้เรียกใช้ Sprint หนึ่งรายการสำหรับแต่ละโครงการและมีการประชุมแบบสแตนด์อัพวันละ 1 ครั้งเพื่อจัดการสปริง / โครงการที่ใช้งานอยู่ทั้งหมด

ฉันต้องการมีส่วนร่วม นี่คือวิธีที่ฉันทำ:

• มีเจ้าของผลิตภัณฑ์หนึ่งรายและสินค้าค้างส่งหนึ่งรายการต่อทีม เจ้าของผลิตภัณฑ์ไม่จำเป็นต้องเป็นบุคคลเดียว แต่ "เอนทิตี" ของเจ้าของผลิตภัณฑ์รายนี้เป็นผู้รับผิดชอบสินค้าค้างส่งของผลิตภัณฑ์
• สินค้าค้างส่งมีเรื่องราวของผู้ใช้ของทุกโครงการ (โครงการทั้งหมดที่นี่) เรื่องราวของผู้ใช้แต่ละคนมีความพยายาม / เรื่องราว (ความรับผิดชอบของทีม) และมูลค่าทางธุรกิจ (ความรับผิดชอบของเจ้าของผลิตภัณฑ์)
• เรามี "product backlog กรูมมิ่ง" ที่ตอบสนองทุกการวิ่ง ก่อนการประชุมครั้งนี้เจ้าของผลิตภัณฑ์ได้อัปเดตคุณค่าทางธุรกิจของเรื่องราว (หากพวกเขาต้องการการเปลี่ยนแปลงไม่ว่าด้วยเหตุผลทางธุรกิจใดก็ตามที่เราไม่สนใจและไม่ควรสนใจ -) และรวมเรื่องราวใหม่ ๆ ไว้ด้วย ในการประชุมนี้จะมีการอธิบายเรื่องราวใหม่ ๆ และความพยายามจะได้รับการอัปเดตด้วย การประชุมนี้ใช้เวลาประมาณหนึ่งชั่วโมง (ยกเว้นครั้งแรกประมาณ 4 ชั่วโมง)
• เมื่อเรากำลังจะวางแผนการวิ่งครั้งใหม่เราจะเปิด backlog ของผลิตภัณฑ์เรียงลำดับเรื่องราวตาม ROI (นี่คือมูลค่าทางธุรกิจ / ความพยายาม) และวางแผนเรื่องราวจนกว่าเวลาจะหมดไป

และนั่นแหล่ะ ฉันสามารถพูดได้ว่ามันใช้ได้ดีทีเดียว เราใช้สเปรดชีตของ Google สองสามรายการ (งานในมือของผลิตภัณฑ์และงานในมือของ sprint ทั้งที่มีแผนภูมิและสิ่งของต่างๆ) ในการทำสิ่งนี้และทำซ้ำ (ด้วยความหมายเฉพาะ) สำหรับองค์กรออนไลน์ทุกวัน: เวลาความคืบหน้าของงาน ฯลฯ

ปัญหาของวิธีนี้คือฉันทำซ้ำงานในสเปรดชีตค้างของ sprint และทำ redmine แต่ฉันไม่พบเครื่องมือออนไลน์ใด ๆ สำหรับการทำสิ่งนี้ทางออนไลน์โดยสิ้นเชิง ฉันคิดถึงสินค้าค้างส่งใน redmine (ไม่มีความหมายอื่นใดที่ใช้ได้ผลสำหรับฉัน) บอร์ดเดียวในจิระเรื่องราวอื่น ๆ ในไทกา ฯลฯ