Sprint Planning با AI؛ کدام قسمت را خودکار نکنیم؟

Sprint Planning پیش از AI چه تصمیمی بود؟

طبق Scrum Guide، Sprint Planning آغاز Sprint است و حاصل کار مشارکتی کل Scrum Team محسوب می‌شود. این رویداد سه سؤال دارد: چرا این Sprint ارزشمند است؟ چه چیزی در این Sprint می‌تواند Done شود؟ و کار انتخاب‌شده چگونه انجام می‌شود؟ این ترتیب مهم است، چون تیم را از فهرست‌کردن ticketها به سمت یک هدف و یک forecast قابل‌فهم می‌برد.

Product Owner باید برای گفت‌وگو دربارهٔ مهم‌ترین Product Backlog Itemها و ارتباط آن‌ها با Product Goal آماده باشد. Developers itemها را با گفت‌وگو انتخاب می‌کنند و برنامهٔ انجام کار را می‌سازند. بنابراین planning جلسهٔ تخصیص خودکار کار یا تبدیل ظرفیت به عدد قطعی نیست؛ فرصتی برای شفاف‌سازی، انتخاب و سازگارشدن با اطلاعاتی است که تیم در اختیار دارد.

AI چه چیزی را در planning تغییر می‌دهد؟

AI فاصلهٔ میان اطلاعات پراکنده و یک تصویر مشترک از کار را کوتاه می‌کند. یک دستیار متصل به اسناد، گفتگوها و repository می‌تواند پیش از جلسه خلاصه‌ای از تغییرهای اخیر، blockerها، تصمیم‌های قبلی و itemهای مشابه آماده کند. این قابلیت برای تیمی که context در چند ابزار پخش شده، ارزش واقعی دارد؛ چون زمان جلسه صرف پیدا کردن اطلاعات پایه نمی‌شود.

اما AI فقط بخشی از مسئله را حل می‌کند. خلاصهٔ خوب الزاماً به معنی فهم درست مسئله نیست. مدل ممکن است یک dependency مهم را به‌دلیل نبودن در داده نبیند، یک درخواست پرتکرار را با یک outcome مهم اشتباه بگیرد یا کار پشتیبان و ریسک انتشار را در breakdown نیاورد. خروجی باید ورودی گفت‌وگو باشد و کنار آن منبع، تاریخ، سطح اطمینان و سؤال‌های باز دیده شود.

چه بخش‌هایی را می‌توان با AI تقویت کرد؟

چهار دسته کار معمولاً برای کمک ماشینی مناسب‌اند، به‌شرط آنکه خروجی قابل‌بازبینی و قابل‌ردگیری باشد:

هدف از این automation حذف نقش‌ها نیست. هدف این است که افراد پیش از تصمیم، context مرتب‌تری داشته باشند و وقت جلسه را برای trade-off و یادگیری نگه دارند. هر پیشنهاد باید بتواند به یک منبع یا یک فرض روشن برگردد.

• آماده‌سازی pre-read: خلاصه‌کردن تغییرهای اخیر، تصمیم‌های قبلی، feedback و blockerها؛
• کشف ابهام: ساختن فهرست سؤال‌هایی که پاسخ آن‌ها برای انتخاب item یا تعریف Done لازم است؛
• پیشنهاد breakdown: شکستن item بزرگ به مسیرهای کوچک‌تر، با نشان‌دادن فرض‌ها و dependencyهای احتمالی؛
• تحلیل دادهٔ delivery: خلاصه‌کردن throughput، cycle time، کار پشتیبان و ظرفیت واقعی بدون تبدیل آن‌ها به وعدهٔ قطعی؛
• ثبت جلسه: جداکردن تصمیم، دلیل، owner، action و موضوعی که هنوز تصمیم‌گیری نشده است.

چه تصمیم‌هایی را نباید خودکار کنیم؟

مرز اصلی جایی است که خروجی مدل از پیشنهاد به تعهد تبدیل می‌شود. AI می‌تواند بگوید چند item از نظر متن شبیه‌اند، اما نمی‌تواند به‌تنهایی تشخیص دهد کدام مسئله در این Sprint برای محصول ارزش بیشتری دارد. می‌تواند ظرفیت گذشته را خلاصه کند، اما نباید از آن برای فشارآوردن به تیم یا اعلام یک deadline قطعی استفاده شود.

در این نقاط، انسان باید تصمیم‌گیرنده بماند و دلیل تصمیم هم ثبت شود. این موضوع فقط برای رعایت Scrum نیست؛ برای کنترل هزینه و ریسک پروژه هم ضروری است. تصمیمی که scope را بزرگ می‌کند، quality bar را پایین می‌آورد یا کار پرریسک را بدون discovery وارد Sprint می‌کند، می‌تواند هزینهٔ ساخت و مالکیت را بیشتر از چیزی کند که در quotation اولیه دیده شده است.

• تعریف ارزش Sprint و نهایی‌کردن Sprint Goal؛
• انتخاب مقدار کاری که تیم با توجه به ظرفیت، Definition of Done و اطلاعات تازه forecast می‌کند؛
• تبدیل پیشنهاد مدل به commitment زمانی یا قراردادی؛
• پایین‌آوردن معیار کیفیت برای اینکه item در پایان Sprint Done به‌نظر برسد؛
• حذف مسئله یا گروهی از کاربران فقط چون در دادهٔ اخیر کمتر دیده شده‌اند؛
• تخصیص خودکار کار به افراد بدون دیدن مهارت، تمرکز، وابستگی و مسئولیت واقعی آن‌ها؛
• تأیید آماده‌بودن itemهای امنیتی، حریم خصوصی یا مالی بدون owner انسانی.

خبر ابزارها: Jira به سمت planning agentic می‌رود

در بررسی صفحهٔ رسمی Atlassian در ۱۵ سپتامبر ۲۰۲۶، Jira قابلیت‌هایی را معرفی می‌کند که از ساخت work از Confluence، Slack، ایمیل، IDE و حتی تصویر تا خلاصه‌سازی context، شکستن work item و واگذاری کار به agent را پوشش می‌دهد. این تغییر جهت مهم است: AI دیگر فقط کنار ticket متن پیشنهاد نمی‌دهد؛ به intake، planning و execution نزدیک می‌شود.

تحلیل من این است که با نزدیک‌شدن agent به مسیر اجرا، کنترل سطح اختیار مهم‌تر از خود قابلیت می‌شود. تیم باید بداند agent چه contextی می‌بیند، چه کاری می‌تواند انجام دهد، کدام action نیاز به تأیید دارد، چه چیزی log می‌شود و چگونه rollback می‌کنیم. اینکه vendor امکان assign کردن کار را فراهم کرده، به معنی آن نیست که تصمیم دربارهٔ ownership را می‌توان بی‌گفت‌وگو به سیستم سپرد.

یک نکتهٔ دیگر هم مهم است: قابلیت‌های اعلام‌شدهٔ ابزار خبر بازار هستند، نه شواهد قطعی دربارهٔ outcome هر تیم. باید در مقاله و در تصمیم خرید، بین چیزی که vendor اعلام کرده، چیزی که تیم واقعاً آزمایش کرده و نتیجه‌ای که با metric مستقل سنجیده شده تفاوت بگذاریم.

مدل سه‌مرحله‌ای حکیم برای استفاده از AI

برای تیم کوچک، لازم نیست از ابتدا یک orchestration پیچیده بسازید. می‌توانید مرز اختیار را در سه مرحله مشخص کنید:

مرحلهٔ اول، قبل از planning است. AI context را جمع می‌کند و draft می‌سازد؛ owner انسانی منابع، تکرارها و سؤال‌های حساس را بررسی می‌کند. مرحلهٔ دوم، داخل planning است. مدل در صورت نیاز پیشنهاد می‌دهد، اما تیم دربارهٔ value، scope، capacity و trade-off صحبت می‌کند. مرحلهٔ سوم، بعد از planning است. AI تصمیم‌ها و actionها را ثبت و ناسازگاری‌ها را یادآوری می‌کند؛ owner انسانی خروجی نهایی و مسئولیت هر action را تأیید می‌کند.

• قبل از جلسه: context، dependency، ریسک و سؤال‌های باز؛
• در جلسه: گزینه‌ها و فرض‌ها، نه تصمیم نهایی یا تعهد خودکار؛
• بعد از جلسه: decision log، actionها، owner و موارد نیازمند بازبینی.

اثر AI بر هزینه و برآورد پروژه

وقتی AI بخشی از planning یا coding را سریع‌تر می‌کند، ممکن است تصور کنیم هزینهٔ ساخت به همان نسبت کم می‌شود. این نتیجه‌گیری زود است. هزینهٔ واقعی یک پروژه فقط زمان تولید خروجی نیست؛ discovery، طراحی، review، تست، integration، امنیت، deploy، monitoring، آموزش، پشتیبانی و rework هم بخشی از مسیر مالکیت هستند.

در planning با AI، دو اثر متضاد ممکن است هم‌زمان رخ دهد: هزینهٔ آماده‌سازی context کم شود و در مقابل، تعداد پیشنهادها و scope احتمالی بیشتر شود. اگر هر پیشنهاد بدون معیار وارد backlog شود، تیم به‌جای تمرکز، کار بیشتری برای بررسی و نگهداری ایجاد می‌کند. بنابراین AI باید uncertainty را آشکار کند، نه اینکه با تولید چندین breakdown آن را پنهان کند.

برای برآورد بهتر، هر itemی که مدل پیشنهاد می‌دهد باید به outcome، فرض، ظرفیت، quality bar و معیار توقف وصل شود. این کار کمک می‌کند هزینهٔ ساخت را از هزینهٔ اجرا و هزینهٔ فرصت جدا ببینیم و وعدهٔ زمانی را با دادهٔ کافی بسازیم، نه با اعتماد به یک عدد ماشینی.

یک قالب عملی برای Sprint Planning با AI

اگر بخواهم از فردا این روش را روی یک تیم کوچک اجرا کنم، برای هر Sprint یک سند کوتاه با این بخش‌ها می‌سازم. AI می‌تواند نسخهٔ اولیه را پر کند، اما team باید آن را در همان جلسه تصحیح کند:

در پایان جلسه، اگر تیم نتواند در چند جمله بگوید چرا این Sprint ارزشمند است، چه چیزی واقعاً Done می‌شود و چه ریسکی هنوز باز است، مشکل کمبود اتوماسیون نیست؛ مشکل کمبود وضوح است. AI نباید این علامت را با متن طولانی‌تر بپوشاند.

• Sprint Goal و outcome مورد انتظار؛
• سه تا پنج item اصلی و ارتباط هرکدام با Goal؛
• فرض‌های مهم و شواهدی که انتخاب را پشتیبانی می‌کنند؛
• ظرفیت واقعی و کارهای پشتیبان، on-call یا maintenance؛
• Definition of Done و quality bar برای این Sprint؛
• dependency، ریسک، تصمیم‌های برگشت‌پذیر و برگشت‌ناپذیر؛
• مواردی که به‌جای commitment باید به discovery یا آزمایش کوچک تبدیل شوند؛
• owner هر تصمیم و تاریخ inspect کردن outcome.

اثر AI بر Agile و مدیریت پروژه

AI می‌تواند ریتم Agile را بهتر کند، اگر زمان آزادشده صرف گفت‌وگوی بهتر و یادگیری سریع‌تر شود. خلاصه‌سازی context، پیدا کردن کارهای تکراری و ثبت تصمیم‌ها به تیم کمک می‌کند کمتر دنبال اطلاعات بگردد. اما اگر مدیر از همین خروجی برای افزایش فشار، بالا بردن تعداد ticket یا مقایسهٔ افراد استفاده کند، AI به‌جای بهبود سیستم، کیفیت تصمیم را پایین می‌آورد.

از دید مدیریت پروژه، مسئلهٔ اصلی جابه‌جایی محل ریسک است. بخشی از ریسک تولید کم می‌شود، اما ریسک نظارت، provenance، دسترسی، حریم خصوصی، vendor lock-in و خطای پنهان بیشتر دیده می‌شود. مدیر پروژه باید از تیم بپرسد کدام قسمت واقعاً حذف شده، کدام قسمت فقط به review منتقل شده و برای failure چه مسیر برگشتی داریم.

Agile در عصر AI یعنی کوتاه‌کردن چرخهٔ یادگیری با حفظ اختیار و accountability، نه تبدیل تیم به اپراتور پیشنهادهای مدل. اگر Sprint Goal، Definition of Done و inspect-and-adapt باقی بمانند، AI می‌تواند دستیار خوبی باشد. اگر این سه حذف شوند، حتی planning بسیار سریع هم فقط سرعت رسیدن به rework را بالا می‌برد.

چک‌لیست قبل از تأیید Sprint

• آیا Sprint Goal یک outcome روشن دارد یا فقط فهرست کار است؟
• آیا هر پیشنهاد AI به منبع، فرض یا evidence مشخص وصل است؟
• آیا Developers مقدار کار و روش انجام آن را خودشان بررسی کرده‌اند؟
• آیا کار review، تست، امنیت، integration و deploy داخل تصویر کار هست؟
• آیا scope جدیدی که AI پیشنهاد داده، owner و معیار توقف دارد؟
• آیا item مبهم به discovery یا آزمایش کوچک تبدیل شده است؟
• آیا Definition of Done به‌خاطر فشار زمانی پایین نیامده است؟
• آیا actionهای جلسه owner و زمان بازبینی دارند؟
• آیا برای خروجی اشتباه یا action ناخواستهٔ agent مسیر rollback داریم؟
• آیا موفقیت Sprint با outcome سنجیده می‌شود، نه فقط تعداد ticket بسته‌شده؟

جمع‌بندی

واقعیت عمومی: Scrum Guide، Sprint Planning را یک کار مشارکتی دربارهٔ ارزش Sprint، کار قابل‌تحویل و روش انجام معرفی می‌کند. صفحهٔ رسمی Atlassian هم نشان می‌دهد Jira و Rovo به سمت ساخت، خلاصه‌سازی، breakdown و واگذاری work به agentها حرکت کرده‌اند.

تحلیل من: بهترین استفاده از AI در planning، کم‌کردن اصطکاک شناختی است، نه حذف قضاوت. مدل باید کمک کند اطلاعات را زودتر ببینیم، فرض‌ها را واضح‌تر کنیم و تصمیم را بهتر ثبت کنیم. نباید به‌جای تیم ارزش را تعیین کند، commitment بسازد یا کیفیت را تأیید کند.

پیشنهاد حکیم: یک Sprint را با سه مرز روشن آزمایش کنید. AI قبل از جلسه context و سؤال بسازد، داخل جلسه فقط گزینه و evidence بدهد و بعد از جلسه decision log و actionها را مرتب کند. اگر بعد از چند Sprint زمان رسیدن از signal به تصمیم کم شد، rework پایین آمد و outcome واضح‌تر شد، آن‌وقت automation را مرحله‌به‌مرحله گسترش دهید.

منابع اولیه برای بررسی

Scrum Guide نسخهٔ HTML برای تعریف Scrum، سه موضوع Sprint Planning، مسئولیت Product Owner و Developers و اصول empiricism: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.

صفحهٔ رسمی Atlassian دربارهٔ Jira و Rovo برای ساخت work، خلاصه‌سازی context، breakdown، ساخت work از منابع مختلف و واگذاری کار به agent: https://www.atlassian.com/software/jira/ai — بررسی‌شده در 2026-09-15.

مرز شواهد و تحلیل

تعریف‌های Scrum و قابلیت‌های اعلام‌شدهٔ Jira و Rovo از منابع اولیهٔ بالا گرفته شده‌اند. قابلیت‌ها، سطح دسترسی و شرایط محصول vendor ممکن است تغییر کنند و این مقاله تضمین عملکرد یا توصیهٔ خرید نیست. مدل سه‌مرحله‌ای، چک‌لیست، چارچوب هزینه و تحلیل اثر AI بر Agile و مدیریت پروژه دیدگاه امین رضا سیدآبادی است و باید با context و ریسک هر تیم تطبیق داده شود.