AI-সহায়ক স্প্রিন্ট প্ল্যানিং: দায়িত্ব না হারিয়ে প্রস্তুতি কীভাবে দ্রুত করা যায়

এটি ক্রস-ফাংশনাল ডেভেলপমেন্ট দলের ক্লাসিক মিটিংগুলোকে AI কীভাবে বদলে দিচ্ছে সে বিষয়ে সিরিজের দ্বিতীয় নিবন্ধ। প্রথম নিবন্ধে আমি ব্যাকলগ রিফাইনমেন্ট নিয়ে আলোচনা করেছিলাম এবং একটি মূল সিদ্ধান্তে পৌঁছেছিলাম: AI দলের সমঝোতাকে নয়, বরং তার জন্য উপকরণ প্রস্তুত করাকে দ্রুত করে। এখন পরবর্তী ধাপে যাওয়া যুক্তিসঙ্গত — স্প্রিন্ট প্ল্যানিং — এবং দেখা যাক স্প্রিন্টের লক্ষ্য, পরিধি ও বাস্তবসম্মততার জন্য দলের দায়িত্ব না হারিয়ে এর প্রস্তুতি কীভাবে দ্রুত করা যায়।

প্রথম নজরে মনে হয়, ভালো রিফাইনমেন্টের পর প্ল্যানিং প্রায় কারিগরি আনুষ্ঠানিকতায় পরিণত হওয়া উচিত। ব্যাকলগের উপাদানগুলো ইতিমধ্যে স্পষ্ট করা হয়েছে, গ্রহণযোগ্যতার মানদণ্ড খসড়া করা হয়েছে, ঝুঁকিগুলো লিখে রাখা হয়েছে, খোলা প্রশ্নগুলো আংশিকভাবে বন্ধ হয়েছে, কারিগরি পদ্ধতির বিকল্পগুলো প্রস্তুত করা হয়েছে। শুধু স্প্রিন্টে কাজগুলো বেছে নিয়ে সেগুলো মানুষের মধ্যে ভাগ করে দিলেই হয়।

কিন্তু এটাই আসল ফাঁদ।

Scrum-এ স্প্রিন্ট প্ল্যানিং কাজ ভাগ করার মিটিং নয়। এটি এমন একটি ইভেন্ট যেখানে দল আরও তিনটি গুরুত্বপূর্ণ প্রশ্নের উত্তর দেয়: কেন এই স্প্রিন্ট মূল্যবান, স্প্রিন্টে আসলে কী করা সম্ভব এবং নির্বাচিত কাজটি কীভাবে সম্পন্ন হবে। আর এই কাঠামোতে AI-কে দেখলে মূল বিষয়টি স্পষ্ট হয়: AI সত্যিই দলকে দ্রুত পরিকল্পনার বিকল্প সংগ্রহ করতে, নির্ভরতাগুলো চিহ্নিত করতে, বিভাজন প্রস্তাব করতে এবং প্রশ্ন প্রস্তুত করতে সাহায্য করতে পারে। কিন্তু এটি স্প্রিন্ট লক্ষ্যের দায়িত্ব নিতে পারে না এবং নিজে থেকে পরিকল্পনাকে বাস্তবসম্মত করতে পারে না।

“AI বাস্তবসম্মতের মতো দেখতে একটি পরিকল্পনা সংগ্রহ করতে সাহায্য করে। এটিকে বাস্তবসম্মত করে তোলে শুধু দল।”

আমার মতে, এখানেই মূল পরিবর্তনটি রয়েছে। AI স্প্রিন্ট প্ল্যানিংয়ের প্রস্তুতি দ্রুত করে, কিন্তু লক্ষ্য, পরিধি ও সরবরাহের পদ্ধতি নিয়ে দলের সমঝোতা হিসেবে স্প্রিন্ট প্ল্যানিংকে প্রতিস্থাপন করে না।

কেন স্প্রিন্ট প্ল্যানিং শুধু ‘স্প্রিন্টে কাজ জমা করা’ নয়

Scrum Guide 2020-এ স্প্রিন্ট প্ল্যানিংকে এমন একটি ইভেন্ট হিসেবে বর্ণনা করা হয়েছে যা স্প্রিন্ট শুরু করে। এর ফলাফল পুরো ডেভেলপমেন্ট দলের সম্মিলিত কাজের মাধ্যমে তৈরি হয়।

স্প্রিন্ট প্ল্যানিং তিনটি বিষয়ের вокруг গঠিত

• কেন এই স্প্রিন্ট মূল্যবান?
• এই স্প্রিন্টে কী করা সম্ভব?
• নির্বাচিত কাজটি কীভাবে সম্পন্ন হবে?

এটি একটি গুরুত্বপূর্ণ ক্রম। প্রথমে কাজের তালিকা নয়, মূল্য। ‘কী শেষ করতে পারব’ নয়, ‘স্প্রিন্টের শেষে আমরা কী পরিবর্তন চাই’। এ কারণেই স্প্রিন্ট লক্ষ্য Jira-তে কোনো সাজসজ্জামূলক লাইন বা নির্বাচিত কাজগুলোর সুন্দর সংক্ষিপ্ত সারাংশ নয়। এটি স্প্রিন্টের একক লক্ষ্য, অর্থাৎ একটি একক লক্ষ্য যা দলকে ফোকাস দেয় এবং স্প্রিন্টের ভেতরে নতুন তথ্য এলে সিদ্ধান্ত নিতে দেয়।

স্প্রিন্ট ব্যাকলগ তিনটি অংশ নিয়ে গঠিত: ‘কেন’-এর জন্য স্প্রিন্ট লক্ষ্য, ‘কী’-এর জন্য নির্বাচিত ব্যাকলগ উপাদান এবং ‘কীভাবে’-এর জন্য কার্যকর পরিকল্পনা। আর বিশেষভাবে গুরুত্বপূর্ণ হলো, স্প্রিন্ট ব্যাকলগ ডেভেলপারদের দ্বারা এবং ডেভেলপারদের জন্য তৈরি একটি পরিকল্পনা। প্রোডাক্ট ওনার আলোচনা প্রস্তুত করতে এবং নির্বাচিত কাজকে প্রোডাক্ট লক্ষ্যের সঙ্গে যুক্ত করতে সাহায্য করেন, স্ক্রাম মাস্টার ইভেন্টটিকে উপযোগী ও উৎপাদনশীল হতে সাহায্য করেন, কিন্তু সম্পাদনের পরিকল্পনা এবং কারিগরি অংশের বাস্তবসম্মততার দায়িত্ব দলের ভেতরেই থাকে।

এখান থেকে AI নিয়ে আলোচনার জন্য একটি সরল কিন্তু অত্যন্ত গুরুত্বপূর্ণ সিদ্ধান্ত আসে: টুলটি স্প্রিন্ট লক্ষ্যের একটি খসড়া, প্রাথমিক ব্যাকলগ উপাদানের তালিকা, নির্ভরতা, ঝুঁকি ও বিভাজন প্রস্তাব করতে পারে। কিন্তু এটি দলের অঙ্গীকারের বাহক হতে পারে না। এটি দলের পক্ষে বলতে পারে না: ‘আমরা সত্যিই এটি নিতে প্রস্তুত’।

AI প্ল্যানিংয়ে আসলে কী বদলায়

প্রমাণের সীমা сразу স্পষ্ট করে নিই। আজ পর্যন্ত বাস্তব Scrum দলে AI-সহায়ক স্প্রিন্ট প্ল্যানিং নিয়ে শক্তিশালী গবেষণাভিত্তি খুব কম। অনেক বেশি কাজ রয়েছে সংলগ্ন বিষয়ে: রিকোয়ারমেন্টস ইঞ্জিনিয়ারিং, ইউজার স্টোরির গুণমান, esfuerzo অনুমান, টেস্ট জেনারেশন, মানুষ ও AI-এর совместное সিদ্ধান্ত গ্রহণ এবং AI ঝুঁকি ব্যবস্থাপনা। তাই ‘AI স্প্রিন্ট পরিকল্পনা করে’ নয়, বরং ‘AI আলোচনার জন্য খসড়া পরিকল্পনা সংগ্রহ দ্রুত করে এবং দলকে আগে কিছু ফাঁক দেখতে সাহায্য করে’ বলা বেশি সঠিক। এটি একটি গুরুত্বপূর্ণ পার্থক্য।

AI আসার আগে স্প্রিন্ট প্ল্যানিংয়ের প্রস্তুতি প্রায়ই বেশ হাতে-কলমে ছিল। প্রোডাক্ট ওনার আগে থেকে অগ্রাধিকার দেখে প্রাথমিক কাজের পরিধি সংগ্রহ করার চেষ্টা করতেন। বিশ্লেষক যাচাই করতেন ব্যাকলগ উপাদানগুলো আলোচনার জন্য কতটা প্রস্তুত। ডেভেলপাররা কারিগরি সীমাবদ্ধতা ও অনুরূপ কাজগুলো মনে করতেন। QA টেস্টিং ঝুঁকি তুলে ধরতেন। স্ক্রাম মাস্টার খেয়াল রাখতেন যেন মিটিংটি আগে সমাধান করা উচিত ছিল এমন বিস্তারিত বিষয়ে বিশৃঙ্খল বিতর্কে পরিণত না হয়।

AI-এর সাথে এই প্রস্তুতিমূলক স্তরটি লক্ষণীয়ভাবে দ্রুততর হতে পারে — তবে শর্ত হলো দলের কাছে মানসম্মত ইনপুট কনটেক্সট এবং ফলাফল যাচাইয়ের স্পষ্ট প্রক্রিয়া থাকতে হবে। মডেল কয়েকটি Sprint Goal-এর বিকল্প তৈরি করতে, লক্ষ্যের চারপাশে ব্যাকলগের আইটেমগুলো গুছিয়ে দিতে, গ্রহণযোগ্যতার মানদণ্ডের দুর্বল জায়গাগুলো চিহ্নিত করতে, নির্ভরশীলতার একটি তালিকা প্রস্তাব করতে, ইতিহাসে অনুরূপ কাজ খুঁজে বের করতে, ঝুঁকিগুলোর খসড়া তৈরি করতে এবং QA, ব্যাকএন্ড, ফ্রন্টএন্ড ও ডিজাইনের জন্য প্রশ্ন প্রস্তুত করতে সাহায্য করতে পারে। কিন্তু এটি এটা প্রমাণ করে না যে চূড়ান্ত planning সবসময় দ্রুততর বা আরও নির্ভুল হবে: লাভের একটি অংশ মানবিক যাচাই, উৎস যাচাই এবং খসড়ার ভুল সংশোধনে ব্যয় হয়ে যেতে পারে।

এটি বিশেষভাবে উপকারী যখন দল AI-assisted refinement-এর পরে planning-এ আসে। আগের নিবন্ধে আমি দেখিয়েছি যে AI একটি কাঁচা অনুরোধকে দ্রুততরভাবে আরও পরিপক্ব ব্যাকলগ আইটেমে রূপান্তর করতে সাহায্য করে। কিন্তু এখন পরবর্তী প্রশ্ন ওঠে: ব্যাকলগের আইটেমগুলো যদি আরও ভালো দেখাতে শুরু করে, তাহলে কি এর অর্থ পরিকল্পনাও আরও ভালো হয়েছে?

অবশ্যই না।

AI পরিকল্পনার আর্টিফ্যাক্টগুলো আরও পরিচ্ছন্ন করতে পারে। এটি এমন একটি অনুভূতি তৈরি করতে পারে যে সবকিছু ইতিমধ্যে সংযুক্ত: এই যে Sprint Goal, এই যে কাজের পরিধি, এই যে ঝুঁকি, এই যে নির্ভরশীলতা, এই যে পরীক্ষার নোট। কিন্তু এটি এখনো পরিকল্পনা নয়। এটি পরিকল্পনার খসড়া। আর Sprint Planning-এর মূল্য ঠিক এখানেই যে দল এই খসড়াটি বাস্তবতার নিরিখে যাচাই করে।

AI দ্রুততরভাবে Sprint Goal, কাজের পরিধি, নির্ভরশীলতা ও ঝুঁকির বিকল্প তৈরি করতে সাহায্য করে, কিন্তু পরিকল্পনার বাস্তবতাযাচাইয়ে দলের ভূমিকা প্রতিস্থাপন করে না।

একই কেস নিয়ে এগোই: B2B LMS এবং email-রিমাইন্ডার

বিমূর্তভাবে না বলে প্রথম নিবন্ধের কেসটিই চালিয়ে যাই।

কর্পোরেট প্রশিক্ষণের জন্য একটি B2B LMS প্ল্যাটফর্ম আছে। বড় ক্লায়েন্টরা কর্মীদের জন্য compliance, নিরাপত্তা ও অভ্যন্তরীণ নিয়মাবলি বিষয়ক বাধ্যতামূলক কোর্স নির্ধারণ করে। ব্যবসা চায় এমন কর্মীদের জন্য স্বয়ংক্রিয় email-রিমাইন্ডার যোগ করতে, যারা নির্ধারিত সময়সীমার আগে বাধ্যতামূলক কোর্স সম্পন্ন করেনি।

refinement-এ দল ইতিমধ্যে বুঝে ফেলেছে যে কাজটি শুধু দেখতে সহজ। আসলে সমঝোতা করতে হবে:

• কাকে রিমাইন্ডারের শর্তপূরণকারী হিসেবে গণ্য করা হবে;
• শুধু বাধ্যতামূলক কোর্স নেওয়া হবে কি না;
• কোন স্ট্যাটাসগুলো বিবেচনায় নেওয়া হবে: not_started, in_progress, expired;
• কীভাবে বাদ দেওয়া হবে archived এবং নিষ্ক্রিয় ব্যবহারকারীদের;
• টাইম জোন কোথায় সংরক্ষিত থাকে;
• ভাষা সেটিং ও ভাষার fallback কীভাবে কাজ করে;
• শিডিউলার টাস্ক পুনরায় চালু হলে ডুপ্লিকেট থেকে কীভাবে রক্ষা পাওয়া যাবে;
• ইতিহাসের লগ / অডিট লগ দরকার কি না;
• ক্লায়েন্ট সাপোর্ট দল কী দেখতে পাবে;
• প্রথম সংস্করণের ন্যূনতম কাজের পরিধি কোথায় শেষ হয়।

একটি ভালো refinement-এর পরে দল Sprint Planning-এ ইতিমধ্যে একটি শক্ত খসড়া নিয়ে আসতে পারে। উদাহরণস্বরূপ, AI একটি ইউজার স্টোরির খসড়া, গ্রহণযোগ্যতার মানদণ্ড, প্রান্তিক কেসের তালিকা, প্রযুক্তিগত পদ্ধতির বিকল্প এবং খোলা প্রশ্ন সংগ্রহ করতে সাহায্য করেছে। কিন্তু planning-এ ভিন্ন ধরনের সিদ্ধান্ত নিতে হয়: দল ঠিক কী নিকটতম স্প্রিন্টে নেবে এবং কোন লক্ষ্যে নেবে।

এমন কেসের জন্য একটি দুর্বল Sprint Goal হতে পারত এমন:

“scheduler, email-রিমাইন্ডার এবং ইতিহাসের লগ তৈরি করা।”

আনুষ্ঠানিকভাবে বোধগম্য, কিন্তু এটি শুধু উপাদানের একটি তালিকা। এটি ব্যাখ্যা করে না স্প্রিন্টটি কেন মূল্যবান, কোন ন্যূনতম ফলাফল তৈরি হতে হবে এবং কোন সমঝোতাগুলো গ্রহণযোগ্য।

আরও শক্তিশালী একটি প্রকাশভঙ্গি:

“সিস্টেমটি নির্ধারিত সময়সীমার আগে অসম্পূর্ণ বাধ্যতামূলক কোর্সসহ সক্রিয় কর্মীদের কাছে একটি সঠিক রিমাইন্ডার পাঠায় এবং যাচাইযোগ্য প্রেরণের ইতিহাস সংরক্ষণ করে।”

এই প্রকাশভঙ্গিটি ভালো, কারণ এতে ইতিমধ্যে মূল্য ও সীমারেখা আছে। আমরা পূর্ণাঙ্গ ক্লায়েন্ট প্যানেলের প্রতিশ্রুতি দিচ্ছি না। জটিল রিমাইন্ডার লজিকের প্রতিশ্রুতি দিচ্ছি না। expired-কে ঘিরে সব বিতর্ক একসাথে সমাধান করছি না। বিস্তৃত অ্যানালিটিক্স তৈরি করছি না। কিন্তু আমরা ন্যূনতম মূল্যবান ফলাফলের প্রতিশ্রুতি দিচ্ছি: প্রযোজ্য কর্মী একটি সঠিক রিমাইন্ডার পান, এবং দল যাচাই করতে পারে কাকে, কখন এবং কেন চিঠি পাঠানো হয়েছে।

AI ছাড়া planning কেমন হতো

AI ছাড়া এমন সভা প্রায়ই কনটেক্সট পুনরুদ্ধার দিয়ে শুরু হয়। প্রোডাক্ট ওনার ব্যবসায়িক অনুরোধের কথা মনে করিয়ে দেন। অ্যানালিস্ট refinement-এ যা বের করা গেছে তা পুনরায় বর্ণনা করেন। ব্যাকএন্ড স্পষ্ট করে নোটিফিকেশন সার্ভিস কীভাবে কাজ করে। ফ্রন্টএন্ড জিজ্ঞেস করে সেটিংস স্ক্রিন দরকার কি না, নাকি ব্যাকএন্ড লজিকই যথেষ্ট। QA সময়সীমা, টাইম জোন, ডুপ্লিকেট ও স্ট্যাটাস নিয়ে প্রশ্ন তুলতে শুরু করে। ডিজাইনার বোঝার চেষ্টা করেন প্রথম পরিধিতে আদৌ কোনো UI আছে কি না।

সভার অর্ধেক সময় বাস্তবসম্মত পরিকল্পনা বাছাইয়ে না গিয়ে দলের মাথায় আবার উপাদান তুলে ধরায় চলে যায়। কোনো এক পর্যায়ে সহজ লোভ জাগে যে শুধু “সব গুরুত্বপূর্ণ জিনিস নিয়ে নেওয়া” হবে: শর্তপূরণ, scheduler, চিঠির টেমপ্লেট, ডিডুপ্লিকেশন / ডুপ্লিকেট দূরীকরণ, ইতিহাসের লগ, ভাষা সেটিং fallback, টাইম জোন, ক্লায়েন্ট সাপোর্ট দলের জন্য তথ্যের দৃশ্যমানতা, expired-এর হ্যান্ডলিং, ক্লায়েন্ট সেটিংস এবং আরও কয়েকটি প্রান্তিক কেস।

এই ধরনের কাজের পরিমাণ সাধারণ জ্ঞানের দৃষ্টিতে যুক্তিসঙ্গত মনে হতে পারে: সবকিছুই তো সংযুক্ত। কিন্তু ঠিক এখানেই planning ফুলতে শুরু করে। দল আপাতদৃষ্টিতে একটি সমন্বিত ফলাফলের কথা বলছে, কিন্তু বাস্তবে অনিশ্চয়তার কয়েকটি স্বাধীন দিক একসাথে নিচ্ছে। কোথাও পণ্যের অর্থবোধকতা অস্পষ্ট, কোথাও প্রযুক্তিগত বাস্তবায়ন, কোথাও পরীক্ষণ, কোথাও UI, কোথাও সহায়তা।

ফলে সভার শেষে এমন একটি Sprint Backlog তৈরি হতে পারে যা পূর্ণ দেখায়, কিন্তু ভঙ্গুর থাকে। এটি এই আশার উপর দাঁড়িয়ে থাকে যে স্প্রিন্টের চলাকালীন সব বিতর্কিত বিষয় সমাধান হয়ে যাবে। মাঝে মাঝে তা হয়ও। কিন্তু প্রায়শই ঠিক এভাবেই দল অসমাপ্ত কাজের স্থানান্তর, কাজের পরিধির লুকানো বিস্তার এবং একটি অপ্রীতিকর অনুভূতি পায়: “আমরা তো সবই আলোচনা করেছিলাম”।

AI-এর সাথে planning কীভাবে বদলায়

AI-এর সাথে একই সভা অন্য একটি স্তরে শুরু হতে পারে।

planning-এর আগে AI পণ্য মালিককে Sprint Goal-এর কয়েকটি বিকল্প প্রস্তুত করতে সাহায্য করে: একটি সংকীর্ণ প্রথম সংস্করণ, আরও বিস্তৃত গ্রাহক কাজের পরিধি, প্রযুক্তিগতভাবে নিরাপদ কাজের পরিধি, প্রসারিত উচ্চাভিলাষী পরিধি। বিশ্লেষক AI-কে অনুরোধ করেন ব্যাকলগের উপাদানগুলোকে প্রতিটি লক্ষ্যের বিকল্পের সাথে সংযুক্ত করতে এবং দেখাতে কোনগুলো লক্ষ্যকে সরাসরি সমর্থন করে না। ব্যাকএন্ড AI-এর মাধ্যমে বিজ্ঞপ্তির আর্কিটেকচার বর্ণনা প্রক্রিয়া করে এবং প্ল্যানার, ডিডুপ্লিকেশন ও আইডেম্পোটেন্সি কাজের ঝুঁকি চিহ্নিত করতে বলে। ফ্রন্টএন্ড ও ডিজাইনার যাচাই করেন প্রথম স্প্রিন্টে UI প্রয়োজন কি না, নাকি ন্যূনতম ইতিহাস প্রদর্শনেই সীমাবদ্ধ থাকা যায়। QA AI-কে নেতিবাচক দৃশ্যকল্প, সীমানা দৃশ্যকল্প এবং সময়-নির্ভর দৃশ্যকল্পের তালিকা প্রস্তুত করতে বলে।

দল planning-এ খালি পাতা নিয়ে আসে না, বরং বিকল্পের একটি সেট নিয়ে আসে:

• ন্যূনতম কাজের পরিধি: বাধ্যতামূলক কোর্স, not_started / in_progress, archived ও নিষ্ক্রিয় ব্যবহারকারীদের বাদ দেওয়া, একটি অনুস্মারক, ডুপ্লিকেট দূরীকরণ, ইতিহাস লগ;
• প্রসারিত কাজের পরিধি: প্লাস ভাষা সেটিং fallback এবং আরও সতর্ক টাইমজোন নীতি;
• প্রসারিত উচ্চাভিলাষী পরিধি: প্লাস গ্রাহক সহায়তা দলের জন্য দৃশ্যমানতা;
• কাজের পরিধির বাইরে: expired, জটিল পর্যায়ক্রমিকতার নিয়ম, প্রসারিত বিশ্লেষণ, গ্রাহকভিত্তিক পৃথক সময়সূচি।

এটি জ্ঞানীয় কাজ অনেক সাশ্রয় করে। এখন দল সভার বেশিরভাগ সময় বিকল্পগুলো প্রথমবারের মতো গঠন করতে ব্যয় করে না। তারা আলোচনা করে কোন বিকল্পটি বাস্তবসম্মত, কোনটি Sprint Goal-কে ভালোভাবে সমর্থন করে এবং কোন ঝুঁকিগুলো অস্পষ্ট রাখা যাবে না।

কিন্তু ঠিক এখানেই একটি নতুন ফাঁদ দেখা দেয়। AI-সংকলিত পরিকল্পনা এতটাই পরিচ্ছন্ন দেখাতে পারে যে দল এটি যাচাই করা শুরু না করে সম্পাদনা করতে শুরু করে। “আমরা কি সত্যিই এটি করতে পারি?” বলে জিজ্ঞাসা না করে কেবল শব্দচয়ন উন্নত করে। দলের প্রাপ্য ধারণক্ষমতা নিয়ে বিতর্ক না করে সুন্দর বিভাজনে বিশ্বাস করে। নির্ভরশীলতা যাচাই না করে ধরে নেয় যে যদি সেগুলো টেবিলে ঢুকে থাকে, তাহলে সেগুলো ইতিমধ্যে বিবেচনায় নেওয়া হয়েছে।

তখন AI planning-এ সাহায্য করে না। এটি কেবল অত্যধিক আশাবাদী পরিকল্পনাকে আরও বিশ্বাসযোগ্য করে তোলে।

প্রধান ফাঁদ: পরিকল্পনার মিথ্যা বাস্তবতা

refinement-এ প্রধান ঝুঁকি ছিল মিথ্যা স্পষ্টতা: কাজটি বোধগম্য দেখায় কারণ AI এটি সুন্দরভাবে সাজিয়েছে। Sprint Planning-এ ঝুঁকি ভিন্ন — মিথ্যা বাস্তবতা।

মিথ্যা বাস্তবতা তখন দেখা দেয় যখন পরিকল্পনা সুসংগত, পূর্ণ ও যৌক্তিক দেখায়, কিন্তু একইসাথে দলের প্রকৃত সীমাবদ্ধতার বিপরীতে যাচাই করা হয়নি। এতে একটি Sprint Goal, কাজের তালিকা, অনুমান, নির্ভরশীলতা ও ঝুঁকি আছে। কিন্তু কেউ সত্যিকারভাবে যাচাই করেনি দলের প্রাপ্য ধারণক্ষমতা যথেষ্ট কি না, গত স্প্রিন্টের অসমাপ্ত কাজ আছে কি না, QA অতিরিক্ত বোঝা কি না, প্রয়োজনীয় বিশেষজ্ঞ উপলব্ধ কি না, সত্যিই Definition of Done পর্যন্ত পৌঁছানো সম্ভব কি না এবং সবচেয়ে কঠিন অংশটি “সংহত করা”, “সমর্থন যোগ করা” বা “সীমানা পরিস্থিতি বিবেচনা করা” শব্দগুলোর নিচে লুকানো আছে কি না।

এই ঝুঁকি কয়েকটি সুপরিচিত সমস্যার সাথে ভালোভাবে মেলে।

প্রথমটি — পরিকল্পনা ত্রুটি। দলগুলো ইতিমধ্যেই ভবিষ্যতের কাজের জটিলতাকে অবমূল্যায়ন করার প্রবণতা রাখে, বিশেষত যখন তারা পরিকল্পনাকে “ভেতর থেকে” দেখে এবং কাঙ্ক্ষিত দৃশ্যকল্পে মনোযোগ দেয়। AI সাহায্য করতে পারে যদি এটি ঐতিহাসিক তথ্য, অনুরূপ কাজ, অতীতের বিলম্ব এবং অসমাপ্ত কাজ স্থানান্তরের সাধারণ কারণ তুলে ধরে। কিন্তু এটি পরিকল্পনা ত্রুটিকে বাড়িয়েও দিতে পারে যদি এটি একটি মসৃণ বিশ্বাসযোগ্য গল্প তৈরি করে: “সবকিছু সুসংগত দেখাচ্ছে, তাই সবকিছু বাস্তবসম্মত”।

দ্বিতীয়টি — অটোমেশন পক্ষপাত। যখন সিস্টেম একটি পরিচ্ছন্ন পরিকল্পনা প্রস্তাব করে, তখন মানুষের পক্ষে সক্রিয় যাচাইয়ের মোড থেকে নিষ্ক্রিয় সম্মতির মোডে যাওয়া সহজ। দল আর সক্রিয়ভাবে বিরোধিতা খোঁজে না, কারণ “AI সবকিছু একত্র করেছে”। এটি planning-এ বিশেষভাবে বিপজ্জনক, যেখানে সিদ্ধান্তের গুণমান নির্ভর করে লেখার পূর্ণতার উপর নয়, বরং সীমাবদ্ধতা নিয়ে সৎ আলোচনার উপর।

তৃতীয়টি — মডেলের হ্যালুসিনেশন বা কনফ্যাবুলেশন / আত্মবিশ্বাসী বানানো গল্প। AI আত্মবিশ্বাসের সাথে এমন একটি নির্ভরশীলতা বানিয়ে ফেলতে পারে যা নেই। অথবা “অনুরূপ কাজ”-এর উল্লেখ করতে পারে যা আসলে কেবল উপরিতলেই অনুরূপ ছিল। অথবা স্ট্যাটাস, টাইমজোন, ভাষা সেটিং fallback বা আর্কিটেকচারাল সীমাবদ্ধতা সম্পর্কে ভুল সিদ্ধান্তে পৌঁছাতে পারে। সমস্যা এই নয় যে এই ধরনের ভুল সবসময় স্থূল। বরং উল্টোটা, সবচেয়ে বিপজ্জনক ভুলগুলো বিশ্বাসযোগ্য দেখায়।

চতুর্থটি — ছদ্ম-নির্ভুলতা। যদি AI একটি সুন্দর মূল্যায়ন, একটি পরিচ্ছন্ন পরিসর বা একটি আত্মবিশ্বাসী ধাপের ক্রম দেয়, তাহলে দলের মধ্যে নির্ভুলতার অনুভূতি জন্মাতে পারে। কিন্তু পরিকল্পনার নির্ভুলতা ভালো একটি টেবিল থেকে জন্মায় না। Agile-ভিত্তিক শ্রম-প্রাক্কলন নিয়ে গবেষণা দেখায় যে প্রাক্কলনের গুণমান অনেক কারণের উপর নির্ভর করে: দলের অভিজ্ঞতা, পূর্ববর্তী অভিজ্ঞতা, কাজের আকার, তথ্যের গুণমান, প্রাক্কলন অনুশীলন, প্রকল্প ব্যবস্থাপনা এবং ব্যবসায়িক প্রভাব। তাই এটা লেখা বা ভাবা বিপজ্জনক যে AI নিজে থেকেই “প্রাক্কলন উন্নত করে”। আরও সৎ একটি প্রকাশভঙ্গি হলো: AI অনুপস্থিত তথ্য, অনুরূপ ঘটনা এবং অস্থির অনুমান চিহ্নিত করতে সাহায্য করতে পারে, কিন্তু প্রাক্কলন তবুও দলকেই যাচাই করতে হবে।

তাই Sprint Planning-এ AI-এর পরিপক্ব ব্যবহার শুরু হয় “এটি আমাদের জন্য কী পরিকল্পনা তৈরি করেছে?” প্রশ্ন দিয়ে নয়, বরং “এই পরিকল্পনায় কী ভুল, অসম্পূর্ণ বা অতিরিক্ত মসৃণ হতে পারে?” প্রশ্ন দিয়ে। একটি ভালো দল শুধু AI-খসড়া উন্নত করে না, বরং ইচ্ছাকৃতভাবে তা খণ্ডন করার চেষ্টা করে: উৎস, অনুমান, নির্ভরতা, দলের প্রাপ্য ধারণক্ষমতা, Definition of Done এবং যেসব জায়গায় মডেল তথ্যের অনুমোদনের চেয়ে বেশি আত্মবিশ্বাসের সাথে সাধারণীকরণ করতে পারে, সেগুলো যাচাই করে।

ভূমিকা অনুযায়ী কী বদলায়

প্রোডাক্ট ওনার

প্রোডাক্ট ওনার AI-এর সাথে দ্রুত Sprint Goal-এর বিকল্প এবং কাজের পরিধি পান। তিনি মডেলকে কয়েকটি দৃশ্যপট দেখাতে বলতে পারেন: ন্যূনতম, নিরাপদ, উচ্চাভিলাষী, stretch। দ্রুত দেখতে পারেন ব্যাকলগের কোন উপাদানগুলো সত্যিই লক্ষ্যকে সমর্থন করে, আর কোনগুলো শুধু “এগুলোও উপকারী”।

কিন্তু প্রোডাক্ট ওনারের দায়িত্ব মুছে যায় না। বরং আরও স্পষ্ট হয়। যদি AI স্প্রিন্টে যেসব জিনিস সম্পর্কিত মনে হয় সেগুলো সব নেওয়ার প্রস্তাব দেয়, প্রোডাক্ট ওনারকে মূল্যের প্রশ্ন ধরে রাখতে হবে: ব্যবহারকারী বা স্টেকহোল্ডারের জন্য সত্যিই কোন ন্যূনতম ফলাফল দরকার? এখন কী না করা যায়? কী Sprint Goal ধ্বংস করবে, আর কী শুধু থাকলেই ভালো?

ব্যবসায়িক বিশ্লেষক

বিশ্লেষকের জন্য AI সংযুক্তি যাচাইয়ের হাতিয়ার হিসেবে উপকারী। এটি গ্রহণযোগ্যতার মানদণ্ডে ফাঁক, ব্যাকলগ উপাদানগুলোর মধ্যে অসঙ্গতি, অন্তর্নিহিত অনুমান এবং planning-এ উত্থাপনযোগ্য প্রশ্ন দ্রুত খুঁজে পেতে সাহায্য করে।

কিন্তু বিশ্লেষক সেই মানুষই থাকেন যিনি আনুষ্ঠানিকভাবে সুন্দর একটি প্রয়োজনীয়তা এবং প্রকৃতপক্ষে যাচাই করা প্রয়োজনীয়তার মধ্যে পার্থক্য করেন। LMS-কেসে বিশ্লেষককেই লক্ষ্য করতে হবে যে “অসম্পূর্ণ কোর্স” কোনো সুস্পষ্ট পরিভাষা নয়। এগুলো নির্দিষ্ট স্ট্যাটাস, ব্যতিক্রম, সময়সীমা, ক্লায়েন্টের নিয়ম এবং সিস্টেমের ডেটা।

ব্যাকএন্ড ডেভেলপার

ব্যাকএন্ড AI থেকে প্রযুক্তিগত ঝুঁকির দ্রুত প্রথম পাস পায়: শিডিউলারের কাজ, idempotency, ডিডুপ্লিকেশন কী, অডিট লগ, পুনরায় চেষ্টার লজিক, নোটিফিকেশন সার্ভিসের সাথে ইন্টিগ্রেশন। এটি প্রস্তুতি দ্রুত করে।

কিন্তু AI সম্পূর্ণ বাস্তব আর্কিটেকচার তেমনভাবে জানে না যেমনভাবে দল জানে। এটি একটি যুক্তিসঙ্গত স্কিম প্রস্তাব করতে পারে যা legacy-সীমাবদ্ধতা, অস্থির কিউ, ডেটার বৈশিষ্ট্য বা সার্ভিসগুলোর মধ্যে সমঝোতা বিবেচনা করে না। তাই ব্যাকএন্ডের AI-এর প্রযুক্তিগত বিভাজন “গ্রহণ” করা উচিত নয়। তার উচিত তা সমালোচনা করা।

ফ্রন্টএন্ড ডেভেলপার

ফ্রন্টএন্ড দ্রুত যাচাই করতে পারে প্রথম কাজের পরিধিতে UI দরকার কি না, কোন অবস্থাগুলো দেখাতে হবে, ব্যবহারকারী কীভাবে পাঠানোর ইতিহাস দেখবে, সেটিংস ব্যবস্থাপনা দরকার কি না বা শুধু পড়ার অনুমতি যথেষ্ট কি না।

কিন্তু planning-কে সৎভাবে উত্তর দিতে হবে: Sprint Goal-এর জন্য UI সত্যিই দরকার, নাকি এটি ইতিমধ্যে সম্প্রসারণ? যদি লক্ষ্য হয় সঠিকভাবে রিমাইন্ডার পাঠানো এবং যাচাইযোগ্য ইতিহাস সংরক্ষণ করা, তাহলে সম্ভবত প্রথম স্প্রিন্টে পূর্ণাঙ্গ ক্লায়েন্ট ইন্টারফেস দরকার নেই। AI বিকল্প প্রণয়নে সাহায্য করতে পারে, কিন্তু দলকে সমঝোতা গ্রহণ করতে হবে।

গুণমান প্রকৌশলী / QA প্রকৌশলী

QA সম্ভবত যতটা মনে হয় তার চেয়ে বেশি AI থেকে লাভ করতে পারে। মডেল দ্রুত নেতিবাচক দৃশ্যপট, সীমানা দৃশ্যপট, সময়-নির্ভর দৃশ্যপট, টাইমজোন যাচাই, ভাষা fallback, archived এবং নিষ্ক্রিয় ব্যবহারকারী, শিডিউলার কাজের পুনরায় চালু এবং ডুপ্লিকেট অপসারণ তৈরি করে।

কিন্তু QA-কেই দলকে ছদ্ম-কভারেজ থেকে রক্ষা করতে হবে। পরীক্ষার ধারণার একটি দীর্ঘ তালিকা এখনও বোঝায় না যে পরিকল্পনা পরীক্ষাযোগ্য। পরিকল্পনা তখনই পরীক্ষাযোগ্য যখন গ্রহণযোগ্যতার মানদণ্ড দ্ব্যর্থহীন, ডেটা доступable, পর্যবেক্ষণযোগ্যতা স্পষ্ট এবং দল বোঝে কীভাবে Definition of Done পূরণ প্রমাণ করতে হবে।

UX/UI ডিজাইনার

ডিজাইনার AI-এর সাথে দ্রুত UI-পদ্ধতির বিকল্প সংগ্রহ করেন: রিমাইন্ডার সেটিংস, পাঠানোর ইতিহাস, ত্রুটির অবস্থা, ক্লায়েন্ট সহায়তা দলের জন্য সংকেত। কিন্তু planning-এ তার কাজ সুন্দর ইন্টারফেস বৈশিষ্ট্য দিয়ে কাজের পরিধি বাড়ানো নয়, বরং প্রয়োজনীয় এবং কাম্যকে আলাদা করতে সাহায্য করা।

আমাদের কেসে পূর্ণ dashboard উপকারী হতে পারে, কিন্তু প্রথম Sprint Goal-এর জন্য বাধ্যতামূলক নয়। যদি designer মূল্য না হারিয়ে ব্যবহারকারীর পথ সংকুচিত করতে সাহায্য করেন, তিনি পরিকল্পনার বাস্তবতাবোধ বাড়ান।

স্ক্রাম মাস্টার

AI-assisted planning-এ স্ক্রাম মাস্টার “সভার আয়োজক” নন, বরং দলের অঙ্গীকারের গুণমানের রক্ষক। তার কাজ হলো নিশ্চিত করা যে AI-খসড়া নিজে থেকেই কর্তৃত্ব হয়ে না ওঠে।

এখানে স্ক্রাম মাস্টারের ভালো প্রশ্নগুলো এমন:

• আমরা কি সত্যিই বুঝি এই স্প্রিন্ট কেন মূল্যবান?
• ডেভেলপাররা কি এই Sprint Backlog-কে নিজেদের পরিকল্পনা মনে করে?
• AI-খসড়ার কোন অংশ আমরা তথ্য দিয়ে যাচাই করেছি?
• কোথায় পরিকল্পনাটি খুব মসৃণ দেখাচ্ছে?
• নতুন তথ্য এলে আমরা প্রথমে কী সরিয়ে ফেলব?
• Sprint Goal কি কাজের তালিকায় পরিণত হয়েছে?

তুলনা: AI ছাড়া এবং AI সহ Sprint Planning

পরিকল্পনার ক্ষেত্র	AI ছাড়া	AI-এর সাথে কী বদলায়
Sprint Goal	জীবন্ত আলোচনায় গঠিত হয়, মাঝে মাঝে কাজ বাছাইয়ের পরেও	AI দ্রুত লক্ষ্যের কয়েকটি বিকল্প প্রস্তাব করে
কাজের পরিধি নির্বাচন	দল ধারাবাহিকভাবে ব্যাকলগ আইটেম নিয়ে আলোচনা করে এবং প্রায়ই সীমানা নিয়ে বিতর্ক করে	AI একটি সংক্ষিপ্ত তালিকা, কাজের পরিধির বিকল্প এবং পরিধির বাইরের প্রস্তাব সংগ্রহ করে
দলের প্রাপ্য ধারণক্ষমতা	মানুষ, ছুটি, সাপোর্ট এবং অসমাপ্ত কাজ স্থানান্তরের ভিত্তিতে হাতে গণনা করা হয়	AI ঐতিহাসিক সংকেত এবং ক্যালেন্ডার সীমাবদ্ধতা সংগ্রহ করতে পারে
নির্ভরতা	দলের স্মৃতি ও অভিজ্ঞতার মাধ্যমে প্রকাশ পায়	AI টেক্সট ও ইতিহাস থেকে প্রাথমিক নির্ভরতা দ্রুত বের করে
বিশ্লেষণ	ডেভেলপাররা নিজেরাই কাজ ভাগ করে	AI দ্রুত ও আরও বিস্তারিতভাবে বিশ্লেষণ প্রস্তাব করে
পরীক্ষণ	QA হাতে গুরুত্বপূর্ণ পরিস্থিতি তুলে ধরে	AI নেতিবাচক ও সীমানা পরিস্থিতির প্রাথমিক বিকল্প তৈরি করে
ঝুঁকি ব্যবস্থাপনা	ঝুঁকিগুলো প্রায়ই খণ্ডিতভাবে আলোচিত হয়	AI দ্রুত ঝুঁকির তালিকা ও অনুমানের রেজিস্টার তৈরি করে
দলের অঙ্গীকার	আলোচনার পর দলের সম্মতি থেকে উদ্ভূত হয়	AI একটি পরিমার্জিত পরিকল্পনা তৈরি করে, যা গ্রহণ করা সহজতর
ডকুমেন্টেশন	প্রায়ই মিটিংয়ের পরে হাতে লেখা হয়	AI সিদ্ধান্ত, অনুমান এবং পরবর্তী পদক্ষেপ দ্রুত লিপিবদ্ধ করে

নতুন ঝুঁকি এবং হাতে কী যাচাই করতে হবে

পরিকল্পনার ক্ষেত্র	নতুন ঝুঁকি	হাতে কী যাচাই করতে হবে
Sprint Goal	Sprint Goal কাজের পরিধির একটি সুন্দর সংক্ষিপ্ত সারাংশে পরিণত হয়	লক্ষ্যে শুধু “কী করছি” নয়, “কেন” আছে কি
কাজের পরিধি নির্বাচন	মিথ্যা পূর্ণতা এবং কাজের পরিধির অতিরিক্ত ঘনত্ব	প্রতিটি আইটেম কি সত্যিই Sprint Goal-এর জন্য প্রয়োজন? প্রথমে কী সরানো যায়?
দলের প্রাপ্য ধারণক্ষমতা	প্রকৃত বিচ্যুতি, বাগ, সাপোর্ট এবং মিটিং বাদ পড়া	ছুটি, সাপোর্টের চাপ, অসমাপ্ত কাজ, বাধ্যতামূলক মিটিং এবং বাহ্যিক নির্ভরতার অপেক্ষা বিবেচনায় আছে কি
নির্ভরতা	মডেল অস্তিত্বহীন নির্ভরতা তৈরি করতে পারে বা সাংগঠনিক নির্ভরতা বাদ দিতে পারে	সব বাহ্যিক নির্ভরতা মানুষ দ্বারা নিশ্চিত এবং দায়িত্বপ্রাপ্ত ব্যক্তি আছে
বিশ্লেষণ	দল নিষ্ক্রিয়ভাবে অন্যের বিভাজন যুক্তি গ্রহণ করে	বিভাজন দলের আর্কিটেকচার, ঝুঁকি এবং Definition of Done প্রতিফলিত করে
পরীক্ষণ	ছদ্ম-কভারেজ: অনেক টেস্ট, কিন্তু ব্যর্থতার মোড নয়	যাচাইযোগ্য গ্রহণযোগ্যতার মানদণ্ড, পর্যবেক্ষণযোগ্যতা এবং পরীক্ষার ডেটা আছে কি
ঝুঁকি ব্যবস্থাপনা	তালিকা সম্পূর্ণ দেখায় এবং বিষয়টি বন্ধ করে দেয়	কোন ঝুঁকিগুলো তথ্য দ্বারা নিশ্চিত নয়? কোনগুলো এখনই কমানো যায়?
দলের অঙ্গীকার	মালিকানা / দায়বদ্ধতার ক্ষয়: “পরিকল্পনা তো তৈরি হয়ে গেছে”	ডেভেলপাররা স্পষ্টভাবে Sprint Backlog-কে নিজেদের পরিকল্পনা হিসেবে নিশ্চিত করেছে
ডকুমেন্টেশন	প্রোটোকলে চুক্তি নয়, মডেলের বিশ্বাসযোগ্য ভাষা ঢোকে	সব গুরুত্বপূর্ণ সিদ্ধান্ত, তথ্য এবং খোলা প্রশ্ন অংশগ্রহণকারীদের দ্বারা নিশ্চিত

এই টেবিলে মূল বিষয়টি AI “planning আরও ভালো করে” তা নয়। আরও সঠিক ধারণা: AI প্রায় সর্বত্র খসড়া, তালিকা, বিকল্প এবং প্রোটোকল তৈরির গতি বাড়ায়। কিন্তু প্রায় কোথাওই বাস্তবতা, বাস্তবায়নযোগ্যতা এবং মালিকানা / দায়বদ্ধতার চূড়ান্ত মানবিক যাচাই-চক্র বাতিল করে না।

ডেটা গভর্নেন্স ও হাইজিন: যা চিন্তা না করে মডেলকে দেওয়া যাবে না

planning-এ প্রায়ই সবকিছু AI-তে লোড করার প্রলোভন দেখা দেয়: Jira-র কাজ, Slack-এর আলোচনা শাখা, ক্লায়েন্টের অনুরোধ, সাপোর্ট লগ, ডকুমেন্টেশনের অংশ, দলের ক্যালেন্ডার, ইনসিডেন্টের ইতিহাস, স্টেকহোল্ডারদের সাথে চিঠিপত্র। planning-এর গুণমানের দৃষ্টিকোণ থেকে এটি বোধগম্য: যত বেশি প্রসঙ্গ, তত ভালো খসড়া।

কিন্তু governance-এর দৃষ্টিকোণ থেকে এটি বিপজ্জনক।

যদি দল Sprint Planning প্রস্তুতিতে AI ব্যবহার করে, তবে আগেই সম্মত হতে হবে কোন ডেটা মডেলে পাঠানো যাবে আর কোনটি যাবে না, কে ফলাফল যাচাই করে এবং বিতর্কিত জায়গাগুলো কীভাবে লিপিবদ্ধ হয়। এখানে একটি সরল governance-পদ্ধতি ভালো কাজ করে: স্পষ্টভাবে দায়িত্বপ্রাপ্ত যাচাই নির্ধারণ করা, তথ্যকে অনুমান থেকে আলাদা করা, অজানাগুলো লিপিবদ্ধ করা, AI-সুপারিশের উপরে দলের গুরুত্বপূর্ণ হাতে-করা ওভাররাইড সংরক্ষণ করা এবং মূল দাবিগুলোর উৎস যাচাই করা। প্রম্পট / মডেলের কাছে অনুরোধে চিন্তা না করে ঢোকানো উচিত নয়:

• প্রকৃত ক্লায়েন্টের নাম;
• ব্যবহারকারী ও কর্মীদের ইমেইল ঠিকানা;
• প্রোডাকশন ডেটা;
• নিরাপত্তা ইনসিডেন্টের বিবরণ;
• ক্রেডেনশিয়াল, টোকেন, API-কী;
• সম্পূর্ণ অডিট লগ;
• আইনি নথি ও চুক্তির শর্তাবলি;
• HR-তথ্য;
• planning-এর জন্য প্রয়োজন নেই এমন বাণিজ্যিকভাবে সংবেদনশীল বিবরণ।

সর্বনিম্ন ও বেনামিকৃত প্রসঙ্গ নিয়ে কাজ করা নিরাপদ: প্রকৃত শনাক্তকারীকে বেনামিকৃত প্রতিস্থাপনে বদলানো, সংবেদনশীল ডেটা মুছে সম্পাদনা / বেনামিকরণ ব্যবহার করা, কাঁচা এক্সপোর্টের বদলে সমষ্টিগত ঐতিহাসিক প্যাটার্ন পাঠানো, তথ্যকে অনুমান থেকে আলাদা করা এবং planning প্রস্তুতিতে কোন প্রম্পট / মডেলের কাছে অনুরোধ ও মডেলের উত্তর সত্যিই ব্যবহৃত হয়েছে তা লিপিবদ্ধ করা।

এটি আমলাতন্ত্র নয়। এটি AI-assisted planning-কে ডেটা ফাঁসের চ্যানেলে পরিণত না করার এবং নির্দিষ্ট সিদ্ধান্তের জন্য প্রয়োজনীয়তার চেয়ে বেশি প্রসঙ্গ মডেলকে না দেওয়ার একটি উপায়।

চেকলিস্ট: AI-সংগৃহীত Sprint Plan আলোচনা করা যাবে, যদি…

এই চেকলিস্টটি অফিসিয়াল Scrum-আর্টিফ্যাক্ট নয়। এটি একটি ব্যবহারিক ফিল্টার, যা দলকে AI-খসড়াকে প্রকৃত পরিকল্পনার সাথে গুলিয়ে ফেলা থেকে বিরত রাখতে সাহায্য করে।

AI-সংকলিত Sprint Plan আলোচনা করা যেতে পারে, যদি:

• Sprint Goal একটি মূল্য বা ব্যবহারকারী / স্টেকহোল্ডারের জন্য পরিবর্তিত অবস্থা হিসেবে প্রণীত হয়, কাজের তালিকা হিসেবে নয়।
• নির্বাচিত প্রতিটি ব্যাকলগ আইটেমের জন্য দল ব্যাখ্যা করতে পারে যে এটি কীভাবে Sprint Goal-কে সমর্থন করে।
• দলের প্রাপ্য ধারণক্ষমতা বিমূর্তভাবে নয়, বরং ছুটি, সাপোর্ট, বাগফিক্স, অসমাপ্ত কাজের স্থানান্তর, অনবোর্ডিং এবং বাধ্যতামূলক সভাগুলো বিবেচনায় নিয়ে হিসাব করা হয়েছে।
• গত স্প্রিন্টের অসমাপ্ত কাজ স্পষ্টভাবে বিশ্লেষণ করা হয়েছে: কী স্থানান্তরিত হচ্ছে, কী বাতিল হচ্ছে, কী পুনর্মূল্যায়ন প্রয়োজন।
• বাহ্যিক নির্ভরতাগুলো স্পষ্টভাবে উল্লেখ করা হয়েছে, প্রতিটির একটি দায়িত্বপ্রাপ্ত ব্যক্তি এবং স্পষ্ট স্ট্যাটাস রয়েছে।
• নির্বাচিত কাজের পরিমাণের জন্য দল Definition of Done-এর পথ দেখে, শুধু “কোড প্রায় প্রস্তুত” অবস্থা নয়।
• পরিকল্পনা পরীক্ষাযোগ্য: গ্রহণযোগ্যতার মানদণ্ড, নেতিবাচক দৃশ্যকল্প, সীমানা দৃশ্যকল্প, পর্যবেক্ষণযোগ্যতা এবং যাচাইয়ের জন্য স্পষ্ট ডেটা রয়েছে।
• দল এক বাক্যে স্প্রিন্টের ন্যূনতম মূল্যবান কাজের পরিমাণ বলতে পারে।
• নতুন তথ্য উঠে এলে কাজের পরিমাণ থেকে প্রথমে কী বাদ দেওয়া যাবে, তা দল আগেই বোঝে।
• AI-খসড়ার গুরুত্বপূর্ণ বাস্তব দাবিগুলো ম্যানুয়ালি যাচাই করা হয়েছে: স্ট্যাটাস, নির্ভরতা, ঐতিহাসিক ডেটা, আর্কিটেকচারাল সীমাবদ্ধতা, ডেডলাইনের নিয়ম, লোকালাইজেশন, ডিডুপ্লিকেশন।
• অংশগ্রহণকারীদের মধ্যে কেউ বিশেষভাবে AI-খসড়াকে খণ্ডন করার চেষ্টা করেছে, শুধু উন্নত করার নয়।
• দল আলাদাভাবে দেখেছে কোথায় পরিকল্পনা অতিরিক্ত মসৃণ, অতিরিক্ত নির্ভুল বা সন্দেহজনকভাবে “স্বতঃসিদ্ধ”।
• ডেভেলপাররা স্পষ্টভাবে নিশ্চিত করেছে যে Sprint Backlog তাদের পরিকল্পনা, এবং Sprint Goal স্প্রিন্টের জন্য দলের অঙ্গীকার।
• planning-এর ফলাফল এমনভাবে লিপিবদ্ধ করা হয়েছে যে স্পষ্ট: কী সিদ্ধান্ত হয়েছে, কী অনুমান করা হয়েছে, কী অজানা রয়ে গেছে এবং কী কাজের পরিমাণের বাইরে রাখা হয়েছে।

বাস্তবে এই চেকলিস্টটি আনুষ্ঠানিক নিয়ন্ত্রণ-বাধা হিসেবে নয়, বরং planning-এর শেষে চিন্তার একটি সংক্ষিপ্ত শৃঙ্খলা হিসেবে ব্যবহার করা যায়। বিশেষভাবে দুটি প্রশ্ন উপকারী: “এই AI-খসড়ায় কী ভুল হতে পারে?” এবং “বাস্তবতা আরও জটিল হলে আমরা প্রথমে কী বাদ দেব?”।

আমি দলকে যা সুপারিশ করব

প্রথমত, Sprint Planning-এর আগে AI ব্যবহার করা উচিত “সে স্প্রিন্ট পরিকল্পনা করবে” এজন্য নয়, বরং একটি ভালো মানবিক আলোচনার জন্য উপাদান প্রস্তুত করার জন্য। সে বিকল্প, নির্ভরতা, অনুমান, ঝুঁকি, সীমানা ক্ষেত্র, কাজের পরিমাণের বিকল্প এবং প্রশ্ন সংগ্রহ করুক। কিন্তু সিদ্ধান্ত দলের কাছেই থাকা উচিত।

দ্বিতীয়ত, সর্বদা পরিকল্পনার খসড়াকে দলের অঙ্গীকার থেকে আলাদা রাখা উচিত। AI-খসড়া একটি চমৎকার প্রস্তুতি হতে পারে, কিন্তু Sprint Backlog তখনই প্রকৃত হয় যখন ডেভেলপাররা এটিকে তাদের নিজেদের পরিকল্পনা হিসেবে বোঝে।

তৃতীয়ত, AI-উৎপন্ন অনুমানকে শুধু কাঠামোগত দেখায় বলে বেশি বস্তুনিষ্ঠ হিসেবে গ্রহণ করা উচিত নয়। স্বয়ংক্রিয় মূল্যায়ন / AI-সমর্থিত শ্রম-প্রয়াস মূল্যায়নের প্রতিলিপি ও পর্যালোচনা সতর্কতার যথেষ্ট ভিত্তি দেয়: একটি জটিল মডেল শুধু জটিলতার কারণে একটি সরল বেসলাইন মডেলের চেয়ে ভালো হয়ে যায় না। অনুমানে শুধু ভুল নয়, অতিরিক্ত আত্মবিশ্বাসও বিপজ্জনক। নির্ভুলতার বিভ্রম তৈরি করার চেয়ে অনিশ্চয়তা চিহ্নিত করতে AI ব্যবহার করা ভালো।

চতুর্থত, কাজের পরিমাণের বাইরে কী আছে তা স্পষ্টভাবে লিপিবদ্ধ করা উচিত। ভালো AI-assisted planning সেশনে মূল্য প্রায়ই শুধু দল যা বেছে নিয়েছে তা দিয়েই তৈরি হয় না, বরং যা সচেতনভাবে নেয়নি তা দিয়েও তৈরি হয়। LMS-কেসে এটি হতে পারে expired, ক্লায়েন্ট সাপোর্ট দলের জন্য একটি পূর্ণাঙ্গ ড্যাশবোর্ড, রিমাইন্ডারের পর্যায়ক্রমের জটিল সেগমেন্টেশন এবং উন্নত অ্যানালিটিক্স।

পঞ্চমত, যাচাইয়ের মালিক নিয়োগ করা উচিত। ব্যবসায়িক অর্থ যাচাই করেন প্রোডাক্ট ওনার, প্রয়োজনীয়তার সংগতি — অ্যানালিস্ট, আর্কিটেকচারাল বাস্তবায়নযোগ্যতা — ডেভেলপাররা, পরীক্ষাযোগ্যতা — QA, ব্যবহারকারী অভিজ্ঞতার সীমানা — ডিজাইনার, দলীয় চুক্তির গুণমান — Scrum Master। AI একটি সাধারণ খসড়া প্রস্তুত করতে পারে, কিন্তু যাচাইয়ের মালিক হতে পারে না।

উপসংহার

যদি Backlog Refinement-এ AI আলোচনার জন্য উপাদান দ্রুত সংগ্রহ ও গঠন করতে সাহায্য করে, তবে Sprint Planning-এ সে পরিকল্পনার বিকল্প দ্রুত সংগ্রহ করতে সাহায্য করে। সে Sprint Goal প্রস্তাব করতে পারে, ব্যাকলগ আইটেম গোষ্ঠীবদ্ধ করতে পারে, নির্ভরতা চিহ্নিত করতে পারে, ডিকম্পোজিশনের খসড়া করতে পারে, পরীক্ষার দৃশ্যকল্প প্রস্তুত করতে পারে, অনুমান লিখে রাখতে পারে এবং এমনকি সভার ফলাফল সুন্দরভাবে লিপিবদ্ধ করতে পারে।

কিন্তু এটি পরিকল্পনাকে বাস্তবসম্মত করে না।

একটি বাস্তবসম্মত Sprint Plan তখনই আসে যখন দল সততার সাথে মূল্য, কাজের পরিমাণ, দলের প্রাপ্য ধারণক্ষমতা, নির্ভরতা, Definition of Done, পরীক্ষাযোগ্যতা এবং এটি কাজে নেওয়ার নিজেদের প্রস্তুতি যাচাই করেছে। AI এই যাচাই ত্বরান্বিত করতে পারে, কিন্তু প্রতিস্থাপন করতে পারে না। সে আরও বিকল্প দেখতে সাহায্য করতে পারে, কিন্তু মানুষের পক্ষে দলীয় অঙ্গীকার বেছে নিতে পারে না।

তাই Sprint Planning-এ AI-এর প্রধান প্রভাব আমি এভাবে প্রকাশ করব: এটি পরিকল্পনার বিকল্প প্রস্তুত করার খরচ কমায়, কিন্তু মানবিক যাচাইয়ের মূল্য বাড়ায়। একটি সুন্দর পরিকল্পনা তৈরি করা যত সহজ হয়েছে, এটি প্রকৃত দলীয় পরিকল্পনা কি না তা বোঝা তত বেশি গুরুত্বপূর্ণ হয়েছে।

একটি পরিপক্ব দলে AI স্প্রিন্ট প্ল্যানিংকে স্বয়ংক্রিয় স্প্রিন্ট ব্যাকলগ জেনারেশনে পরিণত করে না। এটি এটিকে লক্ষ্য, সীমাবদ্ধতা এবং আপস নিয়ে আরও নির্দিষ্ট আলোচনায় পরিণত করে। এবং এটিই সম্ভবত অটোমেশনের সবচেয়ে উপকারী রূপ: প্ল্যানিং থেকে মানুষকে সরিয়ে না দিয়ে, বরং সেই সিদ্ধান্তগুলোর জন্য তাদের মনোযোগ মুক্ত করা, যা কোনো টুল তাদের হয়ে নিতে পারে না।

উৎস ও নির্দেশিকা

• Scrum Guide 2020 — স্প্রিন্ট প্ল্যানিং, স্প্রিন্ট গোল, স্প্রিন্ট ব্যাকলগ, দায়িত্বের ক্ষেত্র।
• NIST AI ঝুঁকি ব্যবস্থাপনা ফ্রেমওয়ার্ক 1.0 — ব্যবস্থাপনা / নিয়ন্ত্রণ, জবাবদিহিতা / দায়, মানুষ ও AI মিথস্ক্রিয়ার কনফিগারেশন।
• জেনারেটিভ AI-এর জন্য NIST প্রোফাইল — কনফাবুলেশন / আত্মবিশ্বাসের সাথে বানানো, অতিরিক্ত নির্ভরতা, গোপনীয়তা এবং ঝুঁকি ব্যবস্থাপনা।
• ChatGPT as a tool for User Story Quality Evaluation — ব্যবহারকারী স্টোরির গুণমান সংক্রান্ত কাজের জন্য একটি মধ্যম মানের প্রমাণভিত্তির উদাহরণ।
• Large Language Models for Software Engineering: Survey and Open Problems — সফটওয়্যার ডেভেলপমেন্ট / সফটওয়্যার ইঞ্জিনিয়ারিংয়ে LLM-এর পর্যালোচনা।
• Agile সফটওয়্যার ডেভেলপমেন্টে শ্রম-ব্যয় মূল্যায়ন: একটি পদ্ধতিগত সাহিত্য পর্যালোচনা — Agile মূল্যায়নের গুণমানের কারণসমূহ।
• Reasons and Approaches for Accurate Effort Estimations in Agile Iterative Development — তথ্যের গুণমান, দল, মূল্যায়ন অনুশীলন, প্রকল্প ব্যবস্থাপনা, ব্যবসায়িক প্রভাব।
• GPT2SP replication report — স্টোরি পয়েন্টে AI-মূল্যায়নের সীমাবদ্ধতা এবং সরল বেসলাইন মডেল / নির্দেশিকার সাথে তুলনা।
• কর্মক্ষেত্রের নথিপত্রের পরিবর্তন পূর্বাভাসের মাধ্যমে নির্ভরযোগ্য পুনরাবৃত্তিমূলক Agile পরিকল্পনার দিকে — নথিপত্রের পরিবর্তন ও প্ল্যানিংয়ের ভঙ্গুরতার মধ্যে সম্পর্ক।
• The Planning Fallacy — সময়সীমা অবমূল্যায়ন নিয়ে ধ্রুপদী কাজ।
• Automation Bias in Intelligent Time Critical Decision Support Systems — অটোমেশন পক্ষপাত, বাদ দেওয়ার ত্রুটি এবং কার্যের ত্রুটি।
• Generalization bias in large language model summarization — বড় ভাষা মডেল দ্বারা তৈরি সারাংশে অতিরিক্ত সাধারণীকরণের ঝুঁকি।
• LLM অ্যাপ্লিকেশনের জন্য OWASP Top 10 — সংবেদনশীল তথ্য, অতিরিক্ত নির্ভরতা, প্রম্পট ও নিরাপত্তা ঝুঁকি।