User story কীভাবে লিখবেন (উদাহরণ ও acceptance criteria সহ)
User story হলো একটি feature-এর ছোট বর্ণনা, ব্যবহারকারীর দৃষ্টিকোণ থেকে: "As a [ধরনের ব্যবহারকারী], I want [লক্ষ্য] so that [কারণ]।" এর নিচে লেখা হয় acceptance criteria — story সম্পন্ন বলে গণ্য হতে যে কয়েকটি নির্দিষ্ট শর্ত সত্য হতে হবে। প্রতিটি story এতটা ছোট রাখুন যাতে একবারে বানিয়ে পরীক্ষা করা যায়, আর criteria এমনভাবে লিখুন যাতে যে কেউ সেগুলো যাচাই করতে পারে।
Agile software দলগুলোর মাধ্যমে user story জনপ্রিয় হয়েছে, কিন্তু AI app builder দিয়ে একা বানালেও এটি সমানভাবে কাজের। একটি ভালো story একটি ভালো prompt।
কাঠামো
একটি user story-র তিনটি অংশ থাকে:
As a [কে], I want [কী] so that [কেন]।
- কে একটি নির্দিষ্ট ধরনের ব্যবহারকারী: প্রথমবারের দর্শক, পেমেন্টকারী সদস্য, একটি ক্লিনিকের রিসেপশনিস্ট, একজন admin। "ব্যবহারকারী" নয়।
- কী হলো তারা যা করতে চায়, তাদের নিজের ভাষায়। পর্দা কীভাবে কাজ করে তা নয়।
- কেন হলো সেই ফলাফল যা তারা চায়। এটি মানুষ প্রায়ই বাদ দেয়, অথচ এটিই আপনাকে ভুল জিনিস বানানো থেকে থামায়।
উদাহরণ:
As a জিমের সদস্য, I want ফোন থেকে একটি ক্লাসের booking বাতিল করতে so that অপেক্ষা তালিকার কেউ আমার জায়গা নিতে পারে এবং আমাকে no-show ফি দিতে না হয়।
"কেন" অংশটি "কী" অংশ বলেনি এমন দুটি জিনিস বলে দেয়: এটি ফোনে কাজ করতে হবে, এবং অপেক্ষা তালিকা ও ফি-র নিয়ম জড়িত।
Acceptance criteria
Story বলে কী চাওয়া হচ্ছে। Acceptance criteria বলে কখন তা সম্পন্ন। এগুলো এত নির্দিষ্ট হওয়া উচিত যে দুজন মানুষ একমত হতে পারে প্রতিটি পাস করেছে কি না।
এগুলো লেখার একটি সাধারণ উপায় হলো Given / When / Then:
- Given একটি শুরুর অবস্থা
- When ব্যবহারকারী কিছু করে
- Then এটি হলো ফলাফল
জিম booking story-র জন্য:
- Given আমার একটি booking আছে যা ১২ ঘণ্টার বেশি দূরে, when আমি Cancel ট্যাপ করে নিশ্চিত করি, then booking-টি সরে যায় এবং আমি "Booking cancelled" দেখি।
- Given আমি একটি booking বাতিল করি এবং ক্লাসে অপেক্ষা তালিকা আছে, when বাতিলটি সংরক্ষিত হয়, then অপেক্ষা তালিকার প্রথম ব্যক্তি জায়গাটি পায় এবং একটি email পায়।
- Given একটি booking ১২ ঘণ্টার কম দূরে, when আমি Cancel ট্যাপ করি, then নিশ্চিত করার আগে আমি দেখি যে একটি দেরিতে-বাতিলের ফি প্রযোজ্য।
- Given আমি ফোনের প্রস্থের একটি screen-এ আছি, then Cancel বোতামটি পাশে স্ক্রোল না করেই দেখা যায়।
একটি সাধারণ checklist-ও চলে, যতক্ষণ প্রতিটি আইটেম পরীক্ষাযোগ্য। "বাতিল করা সহজ" পরীক্ষাযোগ্য নয়। "booking তালিকা থেকে বাতিল করতে সর্বোচ্চ দুটি ট্যাপ লাগে" পরীক্ষাযোগ্য।
ধাপে ধাপে: একটি ভালো story লেখা
ধাপ ১: একজন বাস্তব ব্যবহারকারী ও একটি বাস্তব সমস্যা দিয়ে শুরু করুন
এক ধরনের ব্যবহারকারী এবং আজ তারা যে বিষয়ে ভোগে তা বেছে নিন। গ্রাহকদের সাক্ষাৎকার নিয়ে থাকলে তাদের নিজের ভাষা ব্যবহার করুন। "আমি প্রায়ই বাতিল করতে ভুলে যাই আর চার্জ হয়ে যায়" "বাতিলের feature যোগ করো"-এর চেয়ে ভালো শুরু।
ধাপ ২: এক লাইনের story লিখুন
টেমপ্লেট পূরণ করুন। যদি বিশ্বাসযোগ্য একটি "so that" লিখতে না পারেন, জিজ্ঞেস করুন feature টি আদৌ দরকার কি না।
ধাপ ৩: তিন থেকে ছয়টি acceptance criteria যোগ করুন
আগে মূল সফল ক্ষেত্রটি ঢাকুন, তারপর গুরুত্বপূর্ণ ভিন্নতাগুলো: ভিন্ন ভূমিকা, খালি অবস্থা, একটি সীমা, একটি ত্রুটি। ছয়টির বেশি লিখলে story সম্ভবত অনেক বড়।
ধাপ ৪: কী scope-এর বাইরে তা লিখে রাখুন
একটি লাইন অনেক আলোচনা বাঁচায়: "Scope-এর বাইরে: পেইড ক্লাসের refund; admin দিয়ে সদস্যের হয়ে বাতিল।" বানানোর সময় story বেড়ে যাওয়া থামায়।
ধাপ ৫: INVEST দিয়ে যাচাই করুন
ভালো story-র জন্য INVEST একটি প্রচলিত checklist। একটি story হওয়া উচিত:
| অক্ষর | মানে | দ্রুত পরীক্ষা |
|---|---|---|
| I | Independent (স্বাধীন) | অন্য একটি story-র জন্য অপেক্ষা না করে বানানো যায় |
| N | Negotiable (আলোচনাযোগ্য) | প্রয়োজনটি বর্ণনা করে, একটি নির্দিষ্ট design নয় |
| V | Valuable (মূল্যবান) | শিপ হলে একজন ব্যবহারকারী লক্ষ করবে |
| E | Estimable (আনুমানিকযোগ্য) | মোটামুটি আন্দাজ করা যায় এটি কত বড় |
| S | Small (ছোট) | একবারে বানানো ও পরীক্ষা করা যায় |
| T | Testable (পরীক্ষাযোগ্য) | প্রতিটি acceptance criterion যাচাই করা যায় |
প্রতিটি story-কে নম্বর দেওয়ার দরকার নেই। যখন একটি story ভুল মনে হয় এবং কারণ জানতে চান তখন এটি সবচেয়ে কাজের।
ভালো ও খারাপ উদাহরণ
| দুর্বল story | সমস্যা | ভালো story |
|---|---|---|
| As a user, I want a dashboard. | নির্দিষ্ট ব্যবহারকারী নেই, কারণ নেই, পরীক্ষাযোগ্য নয় | As a shop owner, I want to see today's orders and revenue on one screen so that I know at a glance if the day is going well. |
| As an admin, I want the database to have a status column. | বাস্তবায়ন বর্ণনা করে, প্রয়োজন নয় | As an admin, I want to mark orders as shipped so that customers stop emailing to ask where they are. |
| As a customer, I want to manage my account. | অনেক বড়: অনেক feature ঢেকে ফেলে | As a customer, I want to change my email address so that receipts go to my new inbox. |
| As a visitor, I want the site to be fast. | Story নয়; সবার দরকার এমন একটি গুণ | এটি প্রতিটি story-তে একটি criterion হিসেবে লিখুন, অথবা আলাদা একটি performance লক্ষ্য হিসেবে। |
খুব বড় story কীভাবে ভাগ করবেন
বড় story-তেই project আটকে যায়। ভাগ করার সাধারণ উপায়:
- ব্যবহারকারীর ভূমিকা অনুযায়ী। সদস্যরা নিজের booking বাতিল করে; কর্মীরা যে কারও বাতিল করে।
- Flow-র ধাপ অনুযায়ী। ক্লাস ব্রাউজ করা; একটি ক্লাস বুক করা; একটি reminder পাওয়া।
- আগে সহজ ক্ষেত্র। এখন একটি বিনামূল্যের ক্লাস বাতিল; ফি ও refund পরের story-তে।
- ডেটার ভিন্নতা অনুযায়ী। আগে একটি শাখা সমর্থন করুন, পরে একাধিক।
- সফল পথ আগে, তারপর ত্রুটি। আগে কাজ করার মতো করে বানান, তারপর ভর্তি ক্লাস, মেয়াদোত্তীর্ণ pass ইত্যাদির হ্যান্ডলিং যোগ করুন।
প্রতিটি টুকরো তবুও এমন কিছু হওয়া উচিত যা একজন ব্যবহারকারী ব্যবহার করতে পারে এবং লক্ষ করতে পারে।
User story-কে prompt হিসেবে ব্যবহার
Acceptance criteria-সহ একটি user story একটি ভালো AI app builder prompt-এর খুব কাছাকাছি। এটি AI-কে দেয় কে, কী, কেন আর সম্পন্নের সংজ্ঞা। প্রতি বার্তায় একটি story পাঠান:
As a gym member, I want to cancel a class booking from my phone so that someone on the waitlist can take my spot. Acceptance criteria:
- Cancel is on each booking in My Bookings, with a confirmation step.
- Cancelling more than 12 hours before the class just removes the booking.
- Less than 12 hours before, show "A late-cancellation fee of $5 applies" before confirming, and record the fee on the booking.
- If the class has a waitlist, the first person gets the spot and an email.
- Works on a phone-width screen. Out of scope: refunds, staff cancelling for members. Build this, then check each criterion in the preview and tell me which pass.
আপনি AI-কে একটি মোটা ধারণা থেকে story খসড়া করতেও বলতে পারেন, তারপর নিজে সম্পাদনা করুন:
আমার app-এর ধারণা: [দুই-তিন বাক্য]। একটি প্রথম সংস্করণের জন্য user story লিখুন, ব্যবহারকারীর ধরন অনুযায়ী দলবদ্ধ করে, প্রতিটিতে ৩ থেকে ৫টি Given/When/Then acceptance criteria সহ। চিহ্নিত করুন কোনগুলো লঞ্চের জন্য অপরিহার্য আর কোনগুলো পরে হতে পারে।
সবসময় ফলাফল পড়ুন ও সম্পাদনা করুন। AI আপনার ব্যবহারকারী জানে না; আপনি জানেন।
Acceptance criteria আপনার test plan-ও হিসেবে কাজ করে। Story বানানো হলে প্রতিটি criterion নিজে ধরে ধরে যাচাই করুন। এর ওপর ভিত্তি করে আমাদের লঞ্চের আগে আপনার app পরীক্ষা করা গাইডটি তৈরি।
অন্য নথিগুলোর সঙ্গে user story কোথায় বসে
- Product requirements document পুরো product বর্ণনা করে: সমস্যা, ব্যবহারকারী, scope। User story হলো তার ভেতরের বিস্তারিত টুকরো। দেখুন AI দিয়ে PRD কীভাবে লিখবেন।
- Bug report এমন কিছু বর্ণনা করে যা ইতিমধ্যে বানানো একটি story-র বিপরীতে ভাঙা। দেখুন ভালো bug report কীভাবে লিখবেন।
- MVP হলো সবচেয়ে ছোট সেই story-সেট যা মূল মূল্য দেয়। দেখুন MVP কী।
সাধারণ ভুল
- "As a user…" খুব অস্পষ্ট। ব্যবহারকারীর আসল ধরনের নাম দিন।
- "so that" বাদ দেওয়া। কারণ ছাড়া সঠিক আপস করা যায় না।
- প্রয়োজনের বদলে সমাধান লেখা। "আমি একটি dropdown চাই" কেউ ভাবার আগেই একটি design-কে আটকে দেয়।
- পরীক্ষা করা যায় না এমন criteria। "সহজ", "দ্রুত" আর "স্বজ্ঞাত" হলো ইচ্ছা, criteria নয়।
- যেগুলো আসলে epic। "আমার account পরিচালনা" দশটি story।
- শুরুতেই সব story লেখা। পরের কয়েকটি বিস্তারিত লিখুন; বাকিগুলো সেখানে না পৌঁছানো পর্যন্ত এক লাইনের রাখুন।
Mythex-এ story
Mythex-এ একটি ধারণাকে story-তে রূপ দেওয়ার জন্য Plan মোড ভালো জায়গা: কিছু সম্পাদনার আগে agent পদ্ধতি নিয়ে আলোচনা করে। একটি story প্রস্তুত হলে Build-এ গিয়ে তা পেস্ট করুন, প্রতি বার্তায় একটি story। প্রতিটির পর /test preview-তে ক্লিক করে flow যাচাই করতে পারে, আর কোনো reply ভুল পথে গেলে Revert to this point দিয়ে তা উল্টে ফেলতে পারেন। Docs-এ কার্যকর prompt দেখুন, আর আমাদের AI app builder-এর জন্য prompt কীভাবে লিখবেন গাইডটিও।
User story checklist
- একটি নির্দিষ্ট ধরনের ব্যবহারকারীর নাম আছে
- একটি প্রয়োজন বর্ণনা করে, design নয়
- একটি বাস্তব "so that" কারণ আছে
- তিন থেকে ছয়টি পরীক্ষাযোগ্য acceptance criteria আছে
- অন্তত একটি edge case বা ত্রুটি ঢাকে
- কী scope-এর বাইরে তা বলা আছে
- একবারে বানানো ও পরীক্ষা করার মতো ছোট
- বানানোর পর প্রতিটি criterion একে একে যাচাই করা হয়েছে
প্রশ্নোত্তর
User story-র কাঠামো কী?
প্রচলিত টেমপ্লেট হলো: As a [ধরনের ব্যবহারকারী], I want [কোনো লক্ষ্য] so that [কোনো কারণ]। এর পরে আসে acceptance criteria, অর্থাৎ story সম্পন্ন বলে গণ্য হওয়ার জন্য যে শর্তগুলো সত্য হতে হবে তার একটি ছোট তালিকা।
Acceptance criteria কী?
Acceptance criteria হলো নির্দিষ্ট, পরীক্ষাযোগ্য শর্ত যা নির্ধারণ করে কখন একটি user story সম্পূর্ণ। এগুলো প্রায়ই Given / When / Then আকারে লেখা হয়: একটি শুরুর অবস্থা ধরে নিলে, ব্যবহারকারী কিছু করলে, তখন একটি নির্দিষ্ট ফল ঘটে।
User story কত বড় হওয়া উচিত?
এতটা ছোট যাতে একবারে বানিয়ে পরীক্ষা করা যায়, আবার নিজে থেকেই মূল্যবান থাকে। কোনো story-তে পাঁচ-ছয়টির বেশি acceptance criteria থাকলে বা কয়েকটি screen ছুঁলে, ব্যবহারকারীর ভূমিকা, flow-র ধাপ, বা আগে সহজ ক্ষেত্র এবং পরে edge case — এভাবে ভাগ করুন।
AI দিয়ে বানানোর সময় কি user story কাজে আসে?
হ্যাঁ। Acceptance criteria-সহ একটি user story প্রায় আদর্শ prompt-এর কাছাকাছি: এটি বলে feature টি কার জন্য, তাদের কী দরকার, আর কাজ করছে কি না তা ঠিক কীভাবে যাচাই করতে হবে। প্রতি বার্তায় একটি story পাঠালে AI-র পরিবর্তনও ছোট ও সহজে পরীক্ষাযোগ্য থাকে।