একটি Sprint শুরু হওয়ার পরও যদি ডেভেলপারকে বারবার জানতে হয়—ফিচারটি কার জন্য, ব্যবহারকারী ঠিক কী করতে চান এবং কোন ফলকে গ্রহণযোগ্য ধরা হবে—তাহলে সমস্যাটি সাধারণত কোডে নয়, কাজের বর্ণনায়।
অস্পষ্ট User Story থেকে Product Owner, Developer, Designer ও Tester আলাদা অর্থ বুঝতে পারেন। এরপর Scope বদলায়, নতুন প্রশ্ন ওঠে এবং শেষ করা কাজ আবার সংশোধন করতে হয়। ভালো User Story এই অনিশ্চয়তা কমায়। এটি ব্যবহারকারীর প্রয়োজন ও প্রত্যাশিত ফল সামনে আনে, যাতে Development শুরুর আগেই টিম গুরুত্বপূর্ণ প্রশ্নগুলো নিয়ে আলোচনা করতে পারে।
তবে নির্দিষ্ট একটি Template অনুসরণ করলেই কাজ দ্রুত হবে—এমন নিশ্চয়তা নেই। Story-এর আকার, Acceptance Criteria, Dependency এবং টিমের আলোচনার মানও সমান গুরুত্বপূর্ণ।
User Story আসলে কী?
User Story হলো ব্যবহারকারীর দৃষ্টিকোণ থেকে কোনো প্রয়োজন বা কাঙ্ক্ষিত ফলের সংক্ষিপ্ত বিবরণ। Agile পদ্ধতিতে এটি কাজকে ছোট ও ব্যবহারকারীর জন্য মূল্যবান অংশে ভাগ করতে সাহায্য করে।
প্রচলিত Template:
একজন [ব্যবহারকারীর ধরন] হিসেবে, আমি [কাজ বা লক্ষ্য] করতে চাই, যাতে [প্রত্যাশিত লাভ বা কারণ]।
উদাহরণ:
একজন নিবন্ধিত ক্রেতা হিসেবে, আমি সংরক্ষিত ঠিকানা নির্বাচন করতে চাই, যাতে প্রতিবার নতুন করে ঠিকানা লিখতে না হয়।
এখানে ব্যবহারকারী কে, তিনি কী করতে চান এবং কেন চান—তিনটিই বোঝা যাচ্ছে। কিন্তু User Story শুধু এই একটি বাক্যে সীমাবদ্ধ নয়।
একটি কার্যকর Story-তে সাধারণত তিনটি বিষয় থাকে:
- Card: প্রয়োজনের সংক্ষিপ্ত লিখিত বিবরণ।
- Conversation: প্রয়োজন, Scope ও সম্ভাব্য সমাধান নিয়ে আলোচনা।
- Confirmation: কাজটি প্রত্যাশিত ফল দিয়েছে কি না, তা যাচাইয়ের শর্ত।
Card মূলত আলোচনার স্মারক। পুরো Specification নয়। Story-এর আসল মূল্য শুধু লেখায় নয়; টিমের যৌথ বোঝাপড়ায়।
User Story ও Product Backlog Item-ও সব ক্ষেত্রে একই বিষয় নয়। Scrum কোনো নির্দিষ্ট Backlog Item ফরম্যাট বাধ্যতামূলক করে না। কাজের ধরন অনুযায়ী Backlog-এ User Story, ত্রুটির বিবরণ, গবেষণার কাজ, Hypothesis বা অন্য উপযোগী ফরম্যাট থাকতে পারে।
অস্পষ্ট Story যেভাবে কাজ আটকে দেয়
ধরা যাক, Backlog-এ লেখা আছে: “ব্যবহারকারী যেন ঠিকানা সংরক্ষণ করতে পারেন।”
এখানে একাধিক প্রশ্নের উত্তর নেই। কতটি ঠিকানা রাখা যাবে? Guest User কি সুবিধাটি পাবেন? পুরোনো ঠিকানা সম্পাদনা করা যাবে? Checkout-এর সময় কোন ঠিকানা আগে দেখাবে? মুছে দেওয়া ঠিকানা আগের Order-এ কীভাবে থাকবে?
এসব সিদ্ধান্ত না নিয়েই Development শুরু হলে টিমের সদস্যরা নিজেদের মতো করে প্রয়োজনটি ব্যাখ্যা করতে পারেন। তখন কয়েক ধরনের সমস্যা দেখা দেয়:
- Sprint Planning-এ কাজের আকার নির্ভরযোগ্যভাবে বোঝা যায় না।
- Development চলাকালে Scope বাড়তে পারে।
- UI, API ও Data Flow নিয়ে ভিন্ন ধারণা তৈরি হয়।
- Tester দেরিতে গুরুত্বপূর্ণ Edge Case খুঁজে পান।
- Review-এর সময় তৈরি ফল প্রত্যাশার সঙ্গে না-ও মিলতে পারে।
প্রতিটি অস্পষ্ট Story-তেই এসব সমস্যা ঘটবে না। তবে Backlog Item সম্পর্কে টিমের বোঝাপড়া কম থাকলে Sprint Forecast নিয়েও অনিশ্চয়তা বাড়ে।
ভালো User Story কোথায় সময় বাঁচায়
উদ্দেশ্য পরিষ্কার রাখে
“Saved Address Feature” একটি ফিচারের নাম। ব্যবহারকারীর সমস্যা বা প্রত্যাশিত মূল্য এতে বোঝা যায় না।
অন্যদিকে, “প্রতিবার নতুন করে ঠিকানা না লিখে সংরক্ষিত ঠিকানা ব্যবহার করতে চাই”—এই বক্তব্যটি টিমকে উদ্দেশ্য বুঝতে সাহায্য করে। তখন Developer শুধু অনুরোধ করা Interface তৈরি করার বদলে প্রয়োজনটি পূরণের সহজ ও কার্যকর পদ্ধতি নিয়েও আলোচনা করতে পারেন।
Estimation-এর ভিত্তি শক্ত করে
Story ছোট এবং যথেষ্ট আলোচিত হলে কোন Interface, Service, Database, Permission বা Integration বদলাতে হবে, তা আগে থেকে শনাক্ত করা সহজ হয়। এতে Estimate নিখুঁত হবে না, তবে লুকানো Scope ও Dependency দৃশ্যমান হয়।
Story যাচাইয়ে INVEST একটি পরিচিত পদ্ধতি। একটি কার্যকর Story সাধারণত:
- Independent: অন্য কাজের ওপর অপ্রয়োজনীয়ভাবে নির্ভরশীল নয়।
- Negotiable: চূড়ান্ত সমাধান আগে থেকেই কঠোরভাবে নির্ধারণ করে না।
- Valuable: ব্যবহারকারী বা পণ্যের জন্য অর্থপূর্ণ মূল্য দেয়।
- Estimable: কাজটির আনুমানিক আকার বোঝা যায়।
- Small: একটি iteration-এর মধ্যে শেষ করার মতো।
- Testable: ফল যাচাই করা সম্ভব।
INVEST কোনো বাধ্যতামূলক নিয়ম নয়। এটি Story অতিরিক্ত বড়, অস্পষ্ট বা যাচাই-অযোগ্য কি না, তা বোঝার সহায়ক Checklist।
Acceptance Criteria প্রত্যাশিত ফল নির্দিষ্ট করে
Acceptance Criteria জানায়, কোন শর্ত পূরণ হলে Story-টিকে গ্রহণযোগ্য ধরা হবে। এটি সাধারণত কীভাবে কোড লিখতে হবে তা নির্দেশ করে না; বরং ব্যবহারকারী বা System-এর দিক থেকে কোন ফল দেখা যাবে, তা স্পষ্ট করে।
সংরক্ষিত ঠিকানার Story-এর Criteria হতে পারে:
- Checkout পেজে সক্রিয় সংরক্ষিত ঠিকানাগুলো দেখা যাবে।
- একটি ঠিকানা নির্বাচন করলে Delivery-এর প্রয়োজনীয় তথ্য পূরণ হবে।
- ব্যবহারকারী নির্বাচিত ঠিকানা পরিবর্তন করতে পারবেন।
- কোনো ঠিকানা সংরক্ষিত না থাকলে নতুন ঠিকানা যোগ করার ব্যবস্থা থাকবে।
- মুছে দেওয়া বা নিষ্ক্রিয় ঠিকানা নির্বাচন করা যাবে না।
এগুলো Developer-কে Scope বুঝতে এবং Tester-কে Test Case প্রস্তুত করতে সাহায্য করে।
জটিল আচরণ বোঝাতে Given–When–Then ফরম্যাট ব্যবহার করা যায়:
- Given: শুরুতে কোন অবস্থা রয়েছে।
- When: ব্যবহারকারী বা System কী কাজ করছে।
- Then: কী ফল দেখা উচিত।
এই ফরম্যাট আচরণভিত্তিক Scenario ও Acceptance Test লিখতে কাজে লাগে।
Acceptance Criteria Scrum-এর বাধ্যতামূলক অংশ নয়। এটি Backlog Item স্পষ্ট করার একটি ব্যবহারিক পদ্ধতি। Definition of Done-এর বিকল্প হিসেবেও একে ব্যবহার করা উচিত নয়।
কার্যকর User Story লেখার নিয়ম
ব্যবহারকারীকে যথাসম্ভব নির্দিষ্ট করুন
“As a user” অনেক ক্ষেত্রে অতিরিক্ত সাধারণ। প্রয়োজন অনুযায়ী “নিবন্ধিত ক্রেতা”, “অ্যাকাউন্ট অ্যাডমিন”, “সাপোর্ট এজেন্ট” বা “নতুন আবেদনকারী” লিখুন। ভিন্ন ব্যবহারকারীর অনুমতি, লক্ষ্য ও কাজের ধাপ আলাদা হতে পারে।
তবে বাস্তব পার্থক্য না থাকলে অকারণে নতুন Persona তৈরি করার দরকার নেই।
System Task-কে User Story বানাবেন না
“Database table তৈরি করতে চাই” ব্যবহারকারীর প্রয়োজন নয়; এটি Implementation-এর একটি Technical Task। Story-তে ব্যবহারকারীর দৃশ্যমান লক্ষ্য লিখুন। প্রয়োজনীয় Technical Task Developers পরে নির্ধারণ করতে পারেন।
আবার সব Technical বা Infrastructure কাজকে জোর করে User Story-তে রূপান্তর করারও প্রয়োজন নেই।
কারণের অংশে প্রকৃত মূল্য লিখুন
“রিপোর্ট Download করতে চাই, যাতে Download করতে পারি”—এই বাক্যে কারণটি নতুন কিছু জানায় না।
এর বদলে লেখা যায়:
একজন Finance Manager হিসেবে, আমি মাসিক লেনদেন CSV ফাইলে Export করতে চাই, যাতে হিসাবরক্ষণ সফটওয়্যারে তথ্য বিশ্লেষণ করতে পারি।
এখানে Feature-এর পাশাপাশি তার ব্যবহারিক উদ্দেশ্যও পরিষ্কার।
Story ছোট রাখুন, কিন্তু মূল্য নষ্ট করবেন না
একটি Backlog Item এমন আকারে রাখা ভালো, যাতে সেটি একটি Sprint-এর মধ্যে শেষ করা সম্ভব হয়। Refinement-এর মাধ্যমে বড় ও অস্পষ্ট Item-কে ছোট এবং আরও নির্দিষ্ট করা যায়।
একটি Story-তে Authentication, Payment, Notification, Reporting ও Admin Control একসঙ্গে থাকলে সেটি সম্ভবত অতিরিক্ত বড়। তবে ভাগ করার সময় খেয়াল রাখতে হবে, প্রতিটি অংশ যেন ব্যবহারযোগ্য কোনো মূল্য দেয়। শুধু Frontend ও Backend আলাদা করে দিলেই সব ক্ষেত্রে কার্যকর Story তৈরি হয় না।
আরও পড়ুন: SEO কী: Search Engine ও মানুষের জন্য Website উন্নত করার বাস্তব ধারণা
Dependency লুকিয়ে রাখবেন না
কাজটি Third-party API, Design Approval, অন্য Team, Data Migration বা আইনি পর্যালোচনার ওপর নির্ভর করলে তা Backlog-এর তথ্যের মধ্যে দৃশ্যমান রাখুন। Dependency অজানা থাকলে ছোট মনে হওয়া Story-ও Sprint-এর মাঝখানে আটকে যেতে পারে।
Acceptance Criteria ও Definition of Done এক নয়
Acceptance Criteria একটি নির্দিষ্ট Story বা Backlog Item-এর প্রত্যাশিত আচরণ বোঝায়। Definition of Done পুরো Increment-এর মান ও সম্পূর্ণতার যৌথ মানদণ্ড।
Definition of Done-এ থাকতে পারে:
- প্রয়োজনীয় Code Review সম্পন্ন হয়েছে।
- সম্মত Test পাস করেছে।
- Security ও Quality Standard পূরণ হয়েছে।
- কাজটি বিদ্যমান Increment-এর সঙ্গে যুক্ত।
- প্রয়োজনীয় Documentation হালনাগাদ হয়েছে।
কোনো কাজ Definition of Done পূরণ না করলে সেটিকে সম্পূর্ণ বলা ঠিক নয়। এটি টিমকে “Done” বলতে কী বোঝায়, সে বিষয়ে একটি অভিন্ন মান দেয়।
Sprint-এ নেওয়ার আগে পাঁচটি প্রশ্ন
Story প্রস্তুত কি না বুঝতে এই প্রশ্নগুলো কাজে লাগতে পারে:
- ব্যবহারকারী বা Stakeholder-এর প্রয়োজন পরিষ্কার কি?
- Story কোন মূল্য দেবে, তা বোঝা যাচ্ছে কি?
- প্রত্যাশিত ফল যাচাই করা সম্ভব কি?
- কাজটি একটি Sprint-এর মধ্যে Done করার মতো কি?
- Dependency ও অনির্ধারিত প্রশ্ন দৃশ্যমান কি?
একাধিক প্রশ্নের উত্তর অস্পষ্ট হলে Story নিয়ে আরও refinement করা ভালো। তবে এই তালিকাকে কঠোর approval gate বানালে নতুন অপেক্ষা ও অপ্রয়োজনীয় প্রক্রিয়া তৈরি হতে পারে। লক্ষ্য নিখুঁত Documentation নয়; কাজ শুরুর জন্য যথেষ্ট যৌথ বোঝাপড়া তৈরি করা।
শুরু করার সবচেয়ে বাস্তবসম্মত উপায়
ভালো User Story নিজে থেকে Development দ্রুত করে না। এর কাজ হলো প্রয়োজনীয় আলোচনা ও সিদ্ধান্তগুলো আগে সামনে আনা, যাতে Implementation চলাকালে কম অপ্রত্যাশিত পরিবর্তন আসে।
আসন্ন Sprint-এর গুরুত্বপূর্ণ Story-গুলো Product Owner, Developer, Designer ও Tester মিলে পর্যালোচনা করুন। ব্যবহারকারী, মূল্য, Scope, Acceptance Criteria এবং Dependency পরিষ্কার করুন। Story বড় হলে ব্যবহারযোগ্য ছোট অংশে ভাগ করুন। User Story-এর শক্তি Template-এ নয়। টিমের সবাই যেন একই সমস্যার সমাধান করছেন এবং কাজ সম্পন্ন বলতে কী বোঝায়, সে বিষয়ে একমত হতে পারেন—Development দ্রুত ও নির্ভুল হওয়ার বাস্তব ভিত্তি সেখানেই।
প্রায় জিজ্ঞাসিত প্রশ্ন
User Story কি শুধু Agile বা Scrum টিমের জন্য?
না। User Story Agile ও Scrum টিমে বেশি ব্যবহৃত হলেও অন্য ধরনের Product Development টিমও এটি ব্যবহার করতে পারে। মূল উদ্দেশ্য হলো ব্যবহারকারীর প্রয়োজনকে সহজ ও আলোচনাযোগ্য ভাষায় তুলে ধরা।
একটি ভালো User Story কত বড় হওয়া উচিত?
নির্দিষ্ট কোনো শব্দসীমা নেই। লিখিত Story সংক্ষিপ্ত হওয়া ভালো, কিন্তু কাজটি বোঝার জন্য প্রয়োজনীয় আলোচনা ও Acceptance Criteria আলাদাভাবে থাকতে পারে। Story এত বড় হওয়া উচিত নয় যে একটি Sprint-এর মধ্যে শেষ করা কঠিন হয়ে পড়ে।
Acceptance Criteria কে লিখবেন?
সাধারণত Product Owner বা Product Manager প্রাথমিক Criteria লিখতে পারেন। তবে Developer, Designer ও Tester-এর সঙ্গে আলোচনা করে তা চূড়ান্ত করলে অস্পষ্টতা ও বাদ পড়া Scenario কমে।
User Story-তে Technical Detail রাখা যাবে কি?
ব্যবহারকারীর প্রয়োজন বোঝাতে যতটুকু দরকার, ততটুকু রাখা যায়। তবে Database structure, Framework বা নির্দিষ্ট Implementation পদ্ধতি সাধারণত Technical Task, Design Note বা আলাদা Documentation-এ রাখা ভালো।
সব Product Backlog Item কি User Story হতে হবে?
না। Bug, Technical Debt, Research, Infrastructure Work বা Experiment-এর মতো কাজ সব সময় User Story হিসেবে লেখা স্বাভাবিক নাও হতে পারে। কাজের ধরন অনুযায়ী সবচেয়ে পরিষ্কার ফরম্যাট ব্যবহার করাই ভালো।
Story Point কি User Story-এর মান নির্ধারণ করে?
না। Story Point সাধারণত কাজের তুলনামূলক আকার, জটিলতা ও অনিশ্চয়তা বোঝাতে ব্যবহৃত হয়। বেশি বা কম Story Point কোনো Story ভালো বা খারাপ হওয়ার প্রমাণ নয়।
User Story স্পষ্ট হলেও Development দেরি হতে পারে কেন?
Dependency, প্রযুক্তিগত জটিলতা, পুরোনো System, নতুন Requirement, টিমের সীমিত সক্ষমতা বা সিদ্ধান্তের বিলম্বের কারণে কাজ আটকে যেতে পারে। ভালো Story এসব ঝুঁকি পুরোপুরি দূর করে না; বরং আগেই দৃশ্যমান করতে সাহায্য করে।
