راهنمای مطالب
آشنایی با رویداد برنامهریزی اسپرینت
برنامهریزی اسپرینت، همانطور که در راهنمای اسکرام توضیح داده شده، با تعیین کارهایی که لازم در اسپرینت انجام شوند، آغازگر اسپرینت است. این برنامه حاصل همکاری تمامی اعضای تیم اسکرام است.
مالک محصول اطمینان حاصل میکند که شرکتکنندگان برای بحث درباره مهمترین آیتمهای بکلاگ محصول و چگونگی همراستایی آنها با هدف محصول آماده هستند. تیم اسکرام ممکن است افراد دیگری را نیز برای ارائه مشاوره به برنامهریزی اسپرینت دعوت کند.

موضوعات مورد بحث در برنامهریزی اسپرینت:
- موضوع اول: چرا این اسپرینت ارزشمند است؟ مالک محصول توضیح می دهد که چگونه میتواند ارزش و کارایی محصول در اسپرینت فعلی افزایش می یابد. سپس کل تیم اسکرام برای تعیین هدف اسپرینت همکاری میکنند تا اطمینان حاصل کنند که هدف تعیین شده برای ذینفعان ارزش بهمراه داشته باشد. هدف اسپرینت باید قبل از پایان برنامهریزی اسپرینت نهایی شود.
- موضوع دوم: چه کاری میتوان در این اسپرینت انجام داد؟ توسعهدهندگان از طریق بحث و گفتگو با مالک محصول، آیتمهایی از بکلاگ محصول را برای انجام دادن در اسپرینت فعلی انتخاب میکنند. تیم اسکرام ممکن است در طول این فرآیند این آیتمها را بازبینی کند، تا از قابل درک و شفاف بودن آنها اطمینان حاصل کند.
انتخاب مقدار کاری که میتوان در یک اسپرینت انجام داد ممکن است چالشبرانگیز باشد. با این حال، هرچه توسعهدهندگان بیشتر درباره عملکرد گذشته، ظرفیت آینده و تعریف انجام شده (DoD)خود بدانند، پیشبینیهای اسپرینت خود را با اطمینان بیشتری انجام میدهند.
- موضوع سوم: چگونه کار انتخاب شده انجام خواهد شد؟ توسعهدهندگان برای هر یک از آیتمهای منتخب بکلاگ محصول، کارهای (Tasks) لازم برای ایجاد یک افزایش (Increment) که با تعریف انجام شده (Definition of Done)مطابقت دارد را برنامهریزی میکنند. این کار اغلب با تجزیه آیتمهای بکلاگ محصول به کارهای کوچکتر یک روزه یا کمتر انجام میشود. چگونگی انجام این کار به صلاحدید توسعهدهندگان است و هیچکس دیگری به آنها نمیگوید چگونه آیتمهای بکلاگ محصول را به افزایشها (Increments) تبدیل کنند.
هدف اسپرینت، آیتمهای بکلاگ محصول انتخاب شده برای اسپرینت و برنامه تحویل آنها بهعنوان بکلاگ اسپرینت شناخته میشوند.
برنامهریزی اسپرینت حداکثر هشت ساعت برای یک اسپرینت یکماهه زمانبندی میشود. برای اسپرینتهای کوتاهتر، این رویداد معمولاً کوتاهتر است.
متن اصلی این نوشته در سایت Scrum.org را اینجا بخوانید.