כיצד לחשב ערכים בתרשים Burn Down ב-Scrum

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

הבה נזכור שוב כיצד נראית התרשים הזה.

בדוגמה זו נבחן ספרינט בן 10 ימים. אנו רואים בו שעברו 2 ימים (מכיוון שרק שני הקטעים הראשונים צבועים בגרף הירוק).

כמו כן אנו רואים את נפח הספרינט הכולל - זהו קו מקווקו שמראה שהנפח הכולל של הספרינט ביום שני בשעה 10:00, ביום שלישי בשעה 10:00 וביום רביעי בשעה 10:00 לא השתנה והוא שווה ל-17 SP (Story Points).

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

השריפה בפועל (הגרף הירוק) מראה את העבודה שנותרה בפועל. כלומר, כעת הושלם על ידי הצוות 1 Story Point מתוך 17 שיש להשלים להשלמה מוצלחת של הספרינט. כמשימה שהושלמה נחשבת לרוב משימה בסטטוס "Done" (מהו Done לכל צוות, הצוות מגדיר בעצמו. יש אפילו ארטיפקט מיוחד שנקרא DOD - Definition Of Done - הוא שונה לכל צוות ובו מתואר בצורה מדויקת מאוד מה משמעות הדבר שהמשימה הושלמה וניתן להעביר אותה לסטטוס "Done". לרוב זה "הועלה לפרודקשן", אך יכולים להיות ניואנסים. בסך הכל, לפי הגרף הנוכחי אנו מבינים שה-DOD הושלם רק בסיפור אחד, שהצוות העריך ב-1 SP.

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

אני משער שעשוי לעניין להבין מהו Story Point. למעשה, 1 SP אצל צוות אחד ו-1 SP אצל צוות אחר יכולים להסתיר מאחוריהם נפח עבודה שונה. אצלנו, למשל, יש צוותים עם אותו מספר אנשים, אך אצל אחד הקיבולת לספרינט היא 17 SP, ואצל האחר 35SP. וזה נורמלי. העניין הוא שהצוות עצמו בוחר לעצמו משימת ייחוס שלפיה הוא מעריך את כל המשימות בגרומינגים (שם מיושן - זוהי פגישה שבועית שבה ה-PO מביא User Stories להערכה, והצוות מעריך אותן באמצעות פוקר תכנון) (ב-SAFe זה PBR - Product Backlog Refinement).

לפיכך, אנו יכולים לקבל User Story ייחוס "אני, בתפקיד נהג רכב, רוצה לאחר תדלוק הרכב, לקבל בעת הצורך קבלה מודפסת על נייר". להסכים שהיא עבור הצוות שלנו 8SP. וכאשר ה-PO מספר User Story חדש, שעלינו להעריך, אנו כבר מעריכים אותו ביחס למשימת הייחוס. בהתאם לכך, החדש כבר יכול להיות מוערך על ידי הצוות ב-5 SP, למשל, וכן הלאה כל הסיפורים בבקלוג מקבלים את ההערכות שלהם.

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

אני מקווה שהסברתי בצורה מספיק ברורה כיצד מתקבלים הערכים בתרשים Burn Down.