product owner scrum sprint planningשוב הלך לכם יום עבודה שלם על sprint planning .

אתם יוצאים עצבניים, מתוסכלים וממורמרים.
poker planning, capacity planning, retrospective, daily standups, עוד ועוד ישיבות, ועוד  בזבוז זמן.  למה בכלל צריך את כל ה Scrum  הזה?

אז האמת שהבעיה היא לא ב Scrum.

Scrum מביא איתו דווקא הרבה עקרונות שמסייעים לבניית מוצרים טובים יותר ולשיפור time-to-market.

אבל בהחלט אין שום סיבה שמנהל מוצר ( או product owner) יבזבז יום שלם על sprint planning.

אז איך בכל זאת מוודאים שהצוות הבין את ה backlog ושנלקחים ה stories החשובים ל sprint, מבלי לבזבז יותר מידי זמן?
הנה הצעה למבנה של פגישת sprint planning שלא משבית את מנהל המוצר ליום שלם:

חלק א':  הצגת יעדי ה sprint על ידי מנהל המוצר
בתחילת הפגישה, מנהל המוצר מציג את ה backlog, מסביר כל user story, שם את הדגשים של מה חשוב, איפה אפשר להתפשר, ועונה על שאלות.

חלק ב: תיכנון ה sprint, ע" הצוות
זה הזמן ל capacity planning, ירידה לפרטים, משחקי פוקר וכו'.
חלק זה של הפגישה נמשך לרוב זמן רב, ולכן מומלץ שמנהל המוצר לא יהיה בכולו.

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

חלק ג': הצגת תוכנית ה sprint ואישורה ע"י מנהל המוצר.
בסיום ה-sprint planning, הצוות מציג למנהל המוצר את ה- stories שנלקחו ב- sprint כדי שיאשר את התוכנית. בנוסף מוצגים ההסתייגויות, סיכונים, מידע חסר וכו'.

 

scrum product owner

הרווחתם עכשיו מלא זמן להכין ניתוח מתחרים, לקרוא על מגמות חדשות בשוק, להשלים  PRDs , או סתם לעשות יוגה, כשאתם לא עונים על שאלות….

.