← מסות

סקירת ספרינט ו-AI: מדוע הדמו אינו מחליף שיחה על ערך

ניתוח מעשי של האופן שבו AI משנה את סקירת הספרינט: היכן הוא מוזיל את ההכנה, מדוע אינו מחליף מפגש עבודה עם בעלי עניין, וכיצד לא להפוך את סקירת הספרינט לדמו AI מלוטש.

13 דקות קריאה
Telegramמקור
סקירת ספרינט ו-AI: מדוע הדמו אינו מחליף שיחה על ערך

זהו המאמר הרביעי בסדרה על האופן שבו AI משנה את הפגישות הקלאסיות של צוות פיתוח חוצה-תחומים. במאמר הראשון ניתחתי Backlog Refinement והראיתי ש-AI מאיץ את הכנת החומר, אך אינו מחליף בדיקת משמעות צוותית. בשני דובר על Sprint Planning: AI מרכיב טיוטת תוכנית, אך אינו נוטל על עצמו התחייבות צוותית. בשלישי — על Daily Scrum: AI מכין אותות על התקדמות הספרינט, אך אינו מבצע סנכרון במקום הצוות. כעת הגיוני לעבור לסקירת ספרינט ולנתח את הטעות המפתה ביותר: להפוך שיחה חיה על ערך לדמו AI יפה.

סקירת ספרינט נראית כמקום אידיאלי ל-AI. בסוף הספרינט כבר יש את כל מה שממנו קל להרכיב מצגת מרשימה: משימות סגורות ב-Jira, pull requests ממוזגים, שינויים בקוד, מסכים חדשים, מדדים מעודכנים, טיקטים של תמיכה, משוב משתמשים. AI יכול בתוך דקות להרכיב release notes, לשרטט תרחיש דמו, לעצב שקופיות, לספור כמה בסך הכול נעשה, ואף לייצר סיכום מסודר של מה שהמשתמשים אומרים.

במבט ראשון זהו רווח נקי. פחות הכנה ידנית. פחות "בואו נחליט חמש דקות לפני הפגישה מה מציגים". פחות מנייה משעממת של מה שנעשה. המצגת נראית מקצועית, ה-release notes כתובים בלכידות, המדדים מוצגים יפה ויזואלית.

אך כאן יש מלכודת, והיא חמורה יותר מאשר ב-Daily Scrum.

סקירת ספרינט אינה קיימת לשם הדגמה. תפקידה — לבחון יחד עם בעלי העניין את תוצאת הספרינט, לדון בהתקדמות לעבר Product Goal ולהתאים את Product Backlog. אם AI הופך את סקירת הספרינט לדמו מלוטש, הצוות מקבל מצגת יפה יותר, אך מאבד את העיקר: משוב כן, החלטה משותפת "מה לעשות הלאה" ואחריות למוצר.

"AI יכול להסיר את השגרה של ההכנה, אך סקירת ספרינט יקרה לא בזכות הדמו, אלא בזכות ההחלטה מה לשנות במוצר."

לשם מה נדרשת סקירת ספרינט

ב- Scrum Guide 2020 סקירת הספרינט מתוארת בקפדנות למדי. זהו האירוע השני מהסוף של הספרינט, עם timebox של עד ארבע שעות לספרינט חודשי. מטרתו — לבחון את תוצאת הספרינט ולקבוע התאמות המשך. Scrum Team מציג את תוצאות העבודה לבעלי העניין המרכזיים, ונדונה ההתקדמות לעבר Product Goal. ובנפרד, כמעט בפולמוס, מדייק Scrum Guide: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation" — זהו מפגש עבודה, ועל הצוות להימנע מצמצומו למצגת.

זהו המשפט המרכזי לכל המאמר. סקירת ספרינט אינה קבלת העבודה על ידי בעל המוצר, לא דוח בפני ההנהלה, לא דמו שיווקי ללקוח ולא טקס "אנחנו מעולים". זהו הרגע שבו הצוות ובעלי העניין מביטים יחד במה שנעשה ומה השתנה מסביב, ומחליטים מה לעשות הלאה. תוצאת האירוע אינה מחיאות כפיים, אלא Product Backlog מתוקן.

כעוגן נוסף מועיל גם Scrum Guide Expanded v2026.1, אך דווקא כמקור מלווה, ולא כגרסה קנונית חדשה של Scrum Guide. עבור מאמר זה הוא חשוב כמסגרת מעשית: סקירת ספרינט עוסקת בזרימת ערך אמיתית לבעלי העניין ובהתאמה משותפת של תוכנית המוצר, ולא במצגת סטטוס. בפרק העוסק ב-AI הוא מתאר את המודל כ-supervised decision-making partner: AI יכול לחזק שקיפות, בחינה והתאמה, אך אינו מחליף אחריות אנושית ואינו מבטל בקרה אמפירית של התהליך.

לכן הייתי מתאר את ייעודה של סקירת הספרינט דרך חמש פונקציות:

  • בחינת התוצאה האמיתית של הספרינט, ולא סיפור עליה;
  • איסוף משוב כן מבעלי עניין ומשתמשים;
  • בדיקת ההתקדמות לעבר Product Goal;
  • החלטה משותפת מה לעשות הלאה;
  • התאמת Product Backlog, ולא רק הצגת מה שנעשה.

זוהי מסגרת לשיחה על AI. אם הכלי מסייע לצוות לבצע טוב יותר את הפונקציות הללו, הוא מועיל. אם הוא רק מייפה את הדמו, הוא עשוי להיות נוח, אך לא בהכרח משפר את המוצר.

מה בדרך כלל משתבש

הבעיה בסקירת ספרינט לעתים רחוקות היא שהצוות אינו יודע להציג את מה שנעשה. הבעיה היא שהאירוע הולך ומדרדר עם הזמן לדמו חד-כיווני: הצוות מכין מצגת, מציג מסכים, מונה משימות סגורות, בעלי העניין מהנהנים בנימוס, מישהו אומר "מעולה, תודה", וכולם מתפזרים. ה-Backlog לעומת זאת אינו משתנה. Scrum.org מנתח בדיוק את האנטי-תבנית הזו בחומר Myth 12: The Sprint Review is a Demo: דמו יכול להיות חלק מהאירוע, אך מטרת סקירת הספרינט היא למקסם משוב ולהפחית סיכון, ולא לקיים מצגת.

אז הפגישה מתחילה לפעול נגד מטרתה. הצוות דן איך להציג יפה יותר, ולא מה חשוב לדון בו. בעלי העניין לא מספיקים לתת משוב, כי הצוות "נסחף בתמימות אחרי המצגת שלו" — Scrum.org מציין זאת בנפרד בחומר How to Engage Stakeholders in your Sprint Reviews. שאלות לא נוחות לא נשאלות. הפער בין מה שנבנה לבין מה שהשוק צריך צף מאוחר. ה-Product Backlog נשאר כפי שהיה לפני הפגישה, למרות שכל משמעות האירוע היא לשנות אותו על בסיס נתונים חדשים.

בהקשר של AI-assisted הבעיה הזו עלולה להתחזק. אם המודל מייצר בכל ספרינט מצגת, release notes ורשימת הישגים, הצוות מתרגל מהר למחשבה ש"הסקירה כבר מוכנה". אז ה-Sprint Review נעשה חלק אפילו יותר: פתחו את שקופיות ה-AI, קראו את ה-release notes, הראו מדדים, קיבלו "תודה" מנומסת וסגרו את הפגישה.

זה נראה מקצועי. אבל השאלה אינה עד כמה המצגת מורכבת בצורה קוהרנטית. השאלה היא האם הצוות שינה את ה-Product Backlog שלו, אם המציאות השתנתה.

איפה AI באמת עוזר

ל-AI ב-Sprint Review יש אזור תועלת מעשי בהחלט. הוא יכול להסיר את השגרה של ההכנה ולהעלות לפני השטח את מה שהצוות בקלות מאבד בסוף הספרינט. זה בעל ערך במיוחד כשהמקורות רבים: issue tracker, pull requests, CI/CD, אנליטיקה של המוצר, טיקטים של תמיכה, ביקורות מחנויות האפליקציות, תוצאות סקרים, הקלטות ראיונות עם משתמשים.

אבל כאן חשוב לא להבטיח יותר מדי. אפילו ה- DORA State of AI-assisted Software Development 2025 הטרי מתאר את ה-AI יותר כמגבר של פרקטיקות ארגוניות קיימות מאשר כערובה עצמאית ל-delivery טוב יותר. עבור Sprint Review זה אומר דבר פשוט: אם הצוות כבר יודע לנהל שיחה כנה על ערך ולהתאים את ה-backlog, ה-AI יעשה את הכניסה לשיחה הזו עשירה יותר. אם ה-Sprint Review הפך מזמן לריטואל דמו, ה-AI פשוט יעשה את הריטואל הזה מהיר ויפה יותר.

עוזר AI טוב לפני Sprint Review אוסף לא "איך להציג בצורה מרשימה יותר", אלא הקשר שימושי להחלטה על המוצר:

  • מה באמת השתנה במוצר במהלך הספרינט ואיך זה קשור ל-Product Goal;
  • אילו חלקים מהאינקרמנט מוכנים לבדיקה ואילו עדיף להראות בכנות כלא גמורים;
  • מה אומרים מדדי המוצר לאחר השחרורים הקודמים;
  • איזה משוב הגיע מהמשתמשים ומהתמיכה, כולל סותר ולא נוח;
  • אילו השערות של ספרינטים קודמים אוששו ואילו לא;
  • אילו שאלות מוצר פתוחות כדאי להעלות לדיון עם בעלי העניין;
  • אילו פריטים ב-Product Backlog אולי איבדו רלוונטיות או, להיפך, עלו בעדיפות.

במצב כזה AI לא מחליף את ה-Sprint Review. הוא מפחית את העלות של ההכנה אליו. הצוות מגיע לא עם נתונים גולמיים ולא עם שקופיות שנאספו בחופזה, אלא עם תמונה שכבר מובנית: הנה התוצאה, הנה הנתונים, הנה המשוב, הנה השאלות הפתוחות. זה מאפשר לבזבז פחות זמן על איסוף עובדות ויותר על השיחה "מה אנחנו משנים עכשיו במוצר?".

זה ממשיך את ההיגיון של המאמרים הקודמים בסדרה. ב-refinement ה-AI עזר לאסוף חומר לדיון. ב-planning — אפשרויות לתוכנית. ב-Daily Scrum — אותות על מהלך הספרינט. ב-Sprint Review הוא יכול לאסוף את התוצאה ואת המשוב. אבל בכל ארבעת המקרים החלק האנושי לא נעלם: הצוות ובעלי העניין חייבים לבדוק מה חשוב, מה השתנה ואיזו החלטה לקבל.

שני משתתפים ב-Sprint Review דנים במשוב ובהחלטה מה לשנות ב-Product Backlog
AI שימושי כשכבה מכינה: הוא אוסף את התוצאה ואת המשוב, והצוות עם בעלי העניין מחליט מה לשנות ב-Product Backlog.

למה AI לא צריך להפוך את Sprint Review לתיאטרון דמו

הגרסה המסוכנת ביותר של AI-assisted Sprint Review נראית מאוד משכנעת: המודל מייצר מצגת עם שקופיות יפות, release notes קוהרנטיים, רשימת "הישגי המפתח של הספרינט", גרפים של מדדים וסיכום חלק של משוב משתמשים. לפעמים מתווספת תחזית אוטומטית לגבי Product Goal ושינויים מוצעים ב-backlog.

מנקודת מבט של שקיפות פורמלית זה נוח. מנקודת מבט של Scrum זו עלולה להיות הידרדרות.

ראשית, פורמט כזה מחזק את החד-צדדיות. ככל שהדמו של ה-AI יפה יותר, כך הפיתוי "להעביר" את הפגישה כמצגת חזק יותר. תשומת הלב עוברת ממשוב להצגה: הצוות מגן על השקופיות ולא מזמין את בעלי העניין לוויכוח על ערך.

שנית, סיכום AI של משוב עלול למחוק בדיוק את מה שלשמו נערך ה-Sprint Review. הערך האמיתי של הפידבק הוא בסתירות, באותות חלשים, באי-הסכמה לא נוחה ובהערה נדירה אך חשובה. סיכום חלק וממוצע בקלות זורק את החריגים, ובמוצר לעתים קרובות דווקא החריג הוא האות. זהו הסיכון הקלאסי של information integrity ו-misinformation, המתואר ב- פרופיל NIST ל-AI גנרטיבי.

שלישית, המודל עלול להמציא בביטחון תובנות שאינן קיימות בנתונים. קונפבולציה מסוכנת במיוחד ב-Sprint Review, משום ש"מסקנה" שנוצרה על אודות משתמשים הופכת בקלות להחלטת מוצר. אם ה-AI כותב "המשתמשים מבקשים X", בעוד שלמעשה היו אלה שני טיקטים וראיון אחד, הצוות מסתכן בשינוי ה-Product Backlog על בסיס הזיה.

רביעית, הצוות עלול להתחיל להאציל שיקול דעת מוצרי לכלי. אם ה-AI הציע שינויים ב-backlog, נדמה שאפשר פשוט לאמץ אותם. אם ה-AI אמר שה-Product Goal מושג, נדמה שאין מה לדון. זו אינה אוטומציה של Sprint Review, אלא העברת האחריות למקום שבו אחריות אינה יכולה להתקיים: על המוצר אחראי בעל המוצר יחד עם הצוות, ולא המודל.

"הדגמת AI יכולה להיות קלט שימושי. היא אינה אמורה להפוך לתחליף לשיחה על ערך."

נמשיך את המקרה: B2B LMS ותזכורות בדוא"ל

ניקח את אותו מקרה מהמאמרים הקודמים: פלטפורמת B2B LMS, קורסים חובה, תזכורות בדוא"ל לעובדים שלא השלימו קורס חובה לפני הדדליין. בתכנון בחר הצוות ב-Sprint Goal צר: המערכת שולחת תזכורת נכונה אחת לעובדים פעילים עם קורס חובה שלא הושלם לפני הדדליין ושומרת היסטוריית שליחה ניתנת לבדיקה.

בלי AI, Sprint Review בס�プリント כזה עלול בקלות לגלוש להדגמה. הצוות מציג מסך הגדרת תזכורות, מדגים מייל בדיקה, אומר "המתזמן עובד, הדה-דופליקציה במקום, יומן ההיסטוריה נכתב", בעלי העניין מהנהנים, מישהו משבח את עיצוב המייל. פורמלית הכול טוב. ה-Backlog לא משתנה.

אך הצוות עלול לפספס את העיקר: התזכורות נשלחות, אבל שיעור הפתיחה נמוך כי נושא המייל לא מוצלח; שירות התמיכה כבר קיבל כמה פניות "למה קיבלתי תזכורת על קורס שאיני חייב לעבור" — כלומר גבול ה-eligibility עובד לא כפי שציפו; לקוח גדול אחד מבקש לוח זמנים אישי, וזה עשוי לשנות את סדרי העדיפויות של הספרינט הבא; ופרשנות הסטטוס expiredשהצוות חשב שהיא מחוץ להיקף העבודה, למעשה חשובה לבעלי העניין.

ה-AI יכול לעזור כאן. לפני ה-Sprint Review הוא אוסף קלט: מה נשלח ולמי, מה שיעור הפתיחה ושיעור ההקלקה, אילו פניות הגיעו לתמיכה ועל מה הן, אילו משובים השאירו לקוחות הפיילוט, אילו פריטי backlog קשורים ל-Sprint Goal הזה. זה חומר טוב לשיחה.

אך הערך מופיע רק בפגישה, כאשר הצוות ובעלי העניין עושים את הצעד הבא: מחליטים ששיעור פתיחה נמוך הוא בעיה מוצרית ולא קוסמטיקה; שיש לחדד את גבול ה-eligibility ולהעבירו ל-backlog כפריט נפרד; שלוחות זמנים אישיים ללקוחות גדולים הם החלטה אסטרטגית ולא תיקון מהיר; ושפרשנות ה- expired יש להעביר מהר מ"מחוץ להיקף העבודה" לעדיפות הקרובה. ה-AI נתן תוצאה ונתונים. הצוות עם בעלי העניין התאים את ה-Product Backlog.

אנטי-פטרנים

להלן כמה אנטי-פטרנים שהייתי עוקב אחריהם בנפרד בעת הטמעת AI ב-Sprint Review.

1. ה-AI הופך את המצגת ליפים יותר, והפגישה נשארת חד-כיוונית

אם המאמץ מופנה לליטוש שקופיות ו-release notes, ה-Sprint Review מתחזק כהדגמה ולא כמפגש עבודה. מועיל יותר שה-AI יכין שאלות לבעלי העניין ונושאים מוצריים פתוחים, ולא רק תצוגה מרשימה של מה שנעשה.

2. סיכום AI של משוב ממצע ומאבד אותות חלשים

סיכום חלק נעים לקריאה, אך מסוכן בכך שהוא משליך סתירות והערות נדירות אך חשובות. יש להביא משוב תוך שמירה על אי-הסכמה וחריגים, ולא רק "מצב רוח כללי" ממוצע.

3. ה-AI ממציא תובנות מוצריות שאינן בנתונים

"המשתמשים רוצים X" נשמע משכנע, אך דורש בדיקה: על כמה אותות מבוססת המסקנה, האם זו הזיה, האם הוא החליף מקרה נדיר בביקוש המוני. תובנה מהמודל היא השערה, לא החלטה.

4. מדדים מוצגים כהישג ולא כעילה להחלטה

"שלחנו 10,000 מיילים" הוא פעילות, לא ערך. ה-Sprint Review צריך לקשר מדדים ל-Product Goal ולשאול מה הם משנים בתוכנית, ולא להשתמש בהם כהוכחה שהספרינט עבר היטב.

5. ה-AI מציע שינויים ב-Product Backlog, והם מתקבלים בלי דיון

הצעת המודל יכולה להיות קלט שימושי, אך התאמת ה-backlog היא החלטה מוצרית של בעל המוצר יחד עם הצוות ובעלי העניין, ולא יישום אוטומטי של המלצות AI.

6. תיאטרון הדגמה להנהלה במקום בדיקה לשם הסתגלות

אם ה-Sprint Review הופך למופע "נראה להנהלה שאנחנו מצוינים", ה-AI רק הופך את המופע למשכנע יותר. זה שוחק את האמון באירוע ומונע מהצוות משוב כן.

כיצד ישתנו התפקידים

ה-AI אינו מבטל את התפקידים בתוך Scrum Team, אך משנה את ההדגש בהכנה ובקיום ה-Sprint Review. פחות ערך בהרכבה ידנית של מצגת. יותר ערך בבדיקה כנה של התוצאה, בעבודה עם משוב ובהחלטה משותפת על המוצר.

תפקידסיכון בתרחיש AI גרועשימוש בוגר ב-AI
בעל המוצרמקבל סיכום משוב AI ושינויי backlog מוצעים כפתרון מוכן ומפסיק בעצמו להעריך את הערך.משתמש בקלט AI כחומר גלם, אך בעצמו מנהל את השיחה על הערך, בודק תובנות ואחראי על התאמת Product Backlog.
מפתחיםמבזבזים את ההכנה על ליטוש הדגמת AI במקום להראות בכנות מה מוכן ומה לא.משתמשים ב-AI כדי לאסוף במהירות תוצאות וסיכונים, ובודקים בכנות את האינקרמנט יחד עם בעלי העניין.
Scrum Masterמעביר את הפסיליטציה לשקופיות ועוקב רק אחרי תזמון המצגת.מגן על Sprint Review מפני הפיכתו להדגמה, עוזר למעורבות בעלי העניין ולשמירה על מיקוד בהסתגלות.
בעלי ענייןמקבלים הדגמת AI חלקה, מהנהנים בנימוס ואינם נותנים משוב אמיתי.רואים תוצאה ונתונים בכנות, שואלים שאלות לא נוחות ומשפיעים על סדרי העדיפויות של המוצר.
מהנדס איכות / QAמאשר את רשימת ה'הושלם' של ה-AI ויוצר מראית עין של מוכנות האינקרמנט.עוזר להראות בכנות מה תואם את Definition of Done ומה לא, והיכן נותרו סיכוני איכות.
מעצב UX/UIנופל מהסקירה משום שהדגמת ה-AI מתמקדת בפונקציות ובמדדים.מביא תצפיות משתמשים ומשוב על החוויה, ועוזר לקשר בין התוצאה לערך אמיתי.

מסנן מעשי ל-Sprint Review בסיוע AI

לא הייתי מתחיל בהטמעת 'מחולל הדגמות AI'. הייתי מתחיל בשאלה צרה יותר: איזה קלט עוזר לצוות ולבעלי העניין לקבל החלטת מוצר כנה מהר יותר? לאחר מכן אפשר להשתמש ב-AI כשכבת הכנה, ולא כתחליף לאירוע.

קלט AI ל-Sprint Review מועיל אם הוא עוזר לענות על השאלות:

  • מה באמת השתנה במוצר ואיך זה קשור ל-Product Goal?
  • מה מוכן לבדיקה כנה, ומה צריך להציג כלא גמור?
  • מה אומרים הנתונים והמשוב, כולל משוב סותר?
  • אילו השערות אוששו ואילו נכשלו?
  • אילו שאלות מוצר פתוחות כדאי לדון בהן עם בעלי העניין?
  • אילו פריטים ב-Product Backlog יש לשנות, להוסיף או להסיר?
  • איזו החלטה נקבל בעקבות הדיון, ולא רק מה נציג?

ולהפך: אם קלט ה-AI עונה בעיקר על השאלה 'איך להציג את מה שנעשה בצורה מרשימה יותר', זה לא Sprint Review. זו הדגמה. היא יכולה להיות שימושית לתקשורת, אבל אין לבלבל בינה לבין בדיקת התוצאה והתאמת Product Backlog.

ניהול והיגיינת נתונים

Sprint Review רגיש במיוחד לנתונים, משום שהכנה ב-AI מתחילה בקלות לאסוף משוב מכרטיסי תמיכה, CRM, הקלטות ראיונות, סקרים, ביקורות בחנויות אפליקציות והתכתבויות עם לקוחות. ככל שהגישה רחבה יותר, כך הסיכום משכנע יותר. אבל הסיכון גבוה יותר לדליפת מידע רגיש, לעיוות המשמעות ולתלות יתר במסקנה בטוחה אך חלקית של המודל. מחלקות סיכון אלה מתוארות היטב ב פרופיל NIST ל-AI גנרטיבי, ב מסגרת NIST לניהול סיכוני AI 1.0 וב OWASP Top 10 for LLM Applications 2025.

הצוות צריך להסכים מראש אילו מקורות משוב מותרים ל-AI, כיצד מאנונימיזציה נתוני משתמשים, מי רואה את הסיכום שנוצר והאם ניתן להציג ציטוטי לקוחות גולמיים לבעלי עניין חיצוניים. בעבודה עם נתונים אישיים של משתמשים ולקוחות, שימושיים עוגנים כמו EDPB Opinion 28/2024 ו ICO monitoring at work impact assessment — לא כהוראה משפטית למאמר, אלא כתזכורת לבסיס חוקי, מזעור נתונים, שקיפות ומידתיות.

מבחינה מעשית המשמעות היא: לא למשוך למודל נתונים אישיים מיותרים, להפריד עובדות מפרשנויות שנוצרו, לסמן תובנות AI כהשערות, לאמת ציטוטי משתמשים מול המקור ולא להציג ב-Sprint Review 'מסקנות' שאי אפשר לאמת בנתונים. AI צריך לעזור לצוות לראות בכנות את התוצאה והמשוב, ולא לייצר תמונה משכנעת אך לא מאומתת.

מסקנה מעשית

AI אכן יכול להפוך את ה-Sprint Review לשימושי יותר. הוא יכול להסיר את שגרת ההכנה, לאסוף מראש את תוצאת הספרינט, לקשר אותה למדדים, לצבור משוב, להאיר פערים בין התוכנית למציאות ולהציע נושאים לדיון עם בעלי העניין.

אבל זה עובד רק אם הצוות מבין את הגבול: AI מכין את הקלט, ולא מנהל את ה-Sprint Review. הוא עוזר לראות את התוצאה והנתונים, אך אינו מחליט מה משמעותם למוצר. הוא יכול לאסוף משוב, אך אינו יוצר בעצמו שיחה כנה על הערך. הוא יכול להציע שינויים ב-backlog, אך אינו נוטל אחריות על המוצר.

לכן את הטענה המרכזית הייתי מנסח כך: AI צריך להפחית את עלות ההכנה, כדי שלצוות ולבעלי העניין יישאר יותר קשב לשיחה על הערך ועל התאמת התוכנית. אם קורה ההפך וה-Sprint Review הופך להדגמת AI מלוטשת, הצוות מאבד בדיוק את מה שלשמו האירוע קיים: בדיקה כנה של התוצאה, משוב אמיתי, החלטה משותפת ואחריות על המוצר.

צוות בוגר לא שואל: "האם אנחנו יכולים להטיל על ה-AI להרכיב סקירת ספרינט?". הוא שואל אחרת: "איזה חלק מהשגרה של ההכנה יכול ה-AI להסיר, כדי שסקירת הספרינט שלנו תהפוך לשיחה כנה יותר על ערך ועל מה לשנות במוצר?". זה ניסוח פחות מרשים. אבל הוא קרוב יותר לפרקטיקה אמיתית של מוצר.

מקורות ונקודות התייחסות

← כל המסות