Use case আর user story — acceptance criteria, INVEST আর Given-When-Then

১ · Requirement থেকে ব্যবহারকারীর গল্প

পর্ব ২০-এ দেখেছেন stakeholder খুঁজে কীভাবে তাঁদের কাছ থেকে চাহিদা বের করা হয় (elicitation), আর পর্ব ২১-এ দেখেছেন functional আর non-functional requirement কীভাবে মাপা যায় এমন বাক্যে লেখা হয়। কিন্তু “system অমুক কাজ করবে” ধরনের বাক্যের একটি লম্বা তালিকা পড়ে প্রায়ই বোঝা যায় না, একজন মানুষ আসলে কোন ক্রমে কী করবেন, আর মাঝপথে কিছু ভুল হলে কী হবে।

এই ফাঁক পূরণের দুটি জনপ্রিয় উপায় এই পর্বের বিষয়। Use case একটি লক্ষ্যকে কেন্দ্র করে পুরো কথোপকথন লেখে — সফল পথ আর ব্যর্থতার পথসহ। User story খুব ছোট একটি চাহিদা লেখে, যার বিস্তারিত আসে আলাপ আর acceptance criteria থেকে। দুটিই ব্যবহারকারীর চোখ দিয়ে system দেখে; পার্থক্য বিস্তারে আর ব্যবহারের সময়ে।

পুরো পর্বে একটি কাল্পনিক মোবাইল ওয়ালেট অ্যাপ ধরে এগোব। গ্রাহক অ্যাপে টাকা রাখেন, যেকোনো prepaid নম্বরে রিচার্জ (top-up) করেন, লেনদেনের তালিকা দেখেন। কোনো বাস্তব প্রতিষ্ঠানের নিয়ম বা সংখ্যা এখানে নেওয়া হয়নি; সব সীমা আর নিয়ম উদাহরণের জন্য বানানো।

২ · Use case — actor, লক্ষ্য, scope আর level

Use case-এর কেন্দ্রে একটি বাক্য: একজন actor একটি লক্ষ্য পূরণ করতে চান। বাকি সব এই লক্ষ্যকে ঘিরে।

• Actor: system-এর বাইরের কেউ, যে system-এর সাথে কাজ করে — মানুষ, অন্য software বা যন্ত্র। Actor একটি ভূমিকা, নির্দিষ্ট মানুষ নয়: একই রহিম সাহেব কখনো “গ্রাহক”, কখনো “এজেন্ট”। যাঁর লক্ষ্য পূরণে use case লেখা, তিনি primary actor; যে বাইরের system সেবা দেয় (যেমন অপারেটরের top-up সেবা, SMS সেবা), সে supporting actor.
• লক্ষ্য (goal): actor-এর চোখে কী অর্জন হবে — “মোবাইল রিচার্জ করা”, “PIN বদলানো”। Use case-এর নাম সাধারণত ক্রিয়া দিয়ে লেখা লক্ষ্যটিই।
• Scope: কোন system-এর সীমানা ধরে লেখা — পুরো প্রতিষ্ঠান (মানুষের কাজসহ), শুধু software system, নাকি তার একটি অংশ (component). সীমানা না বললে “system যাচাই করে” বাক্যে system কোনটি, তা অস্পষ্ট থাকে।
• Level: লক্ষ্যটি কত উঁচু স্তরের। Cockburn তিনটি প্রধান স্তর দেন, সমুদ্রের ছবি দিয়ে।

সবচেয়ে কাজের স্তর user-goal. নতুনরা প্রায়ই subfunction-কে use case বানান (“Login”, “ডেটা সেভ করা”) — কেউ লগইন করার জন্য অ্যাপ খোলেন না, কিছু করার জন্য খোলেন। Cockburn-এর পরামর্শ: system-এর বেশিরভাগ use case user-goal স্তরে লিখুন, কয়েকটি summary use case দিয়ে বড় ছবি দেখান, আর subfunction শুধু তখনই আলাদা করুন যখন একাধিক use case একই ধাপগুলো ব্যবহার করে।

৩ · একটি পূর্ণ use case লেখা

Cockburn দুই ধরনের রূপ বলেন: casual — কয়েক অনুচ্ছেদের সরল গদ্য, আর fully dressed — নির্দিষ্ট শিরোনামসহ পূর্ণ ছাঁচ। শুরুর দিকে casual যথেষ্ট; ঝুঁকি বা দলের দূরত্ব বেশি হলে fully dressed. ছাঁচের অংশগুলো:

এবার ওয়ালেটের রিচার্জ use case ধাপে ধাপে লিখি — আগে মূল পথ, তারপর দুটি extension.

UC-07  মোবাইল রিচার্জ করা
Primary actor:  গ্রাহক
Scope:          ওয়ালেট system (অ্যাপ + server), black box
Level:          user-goal (এক বসায় শেষ হয়)
Supporting:     অপারেটরের top-up সেবা, SMS সেবা

Stakeholder ও স্বার্থ:
  গ্রাহক — সঠিক নম্বরে দ্রুত রিচার্জ; টাকা কাটলে রিচার্জ নিশ্চিত
  ওয়ালেট প্রতিষ্ঠান — প্রতিটি লেনদেনের নির্ভুল হিসাব, প্রতারণা রোধ
Precondition:  গ্রাহক লগইন করা আছেন, অ্যাকাউন্ট সক্রিয়
Trigger:       গ্রাহক রিচার্জের অপশন বেছে নেন

1. গ্রাহক মোবাইল নম্বর দেন
2. System নম্বর যাচাই করে অপারেটর চিনে দেখায়
3. গ্রাহক টাকার পরিমাণ দেন
4. System ব্যালান্স ও সীমা যাচাই করে সারাংশ দেখায়
5. গ্রাহক PIN দিয়ে নিশ্চিত করেন
6. System PIN যাচাই করে টাকা আটকে রাখে, অপারেটরকে অনুরোধ পাঠায়
7. অপারেটরের সেবা সফলতা জানায়
8. System লেনদেন চূড়ান্ত করে, রসিদ দেখায়, SMS পাঠায়

4a. ব্যালান্স পরিমাণের চেয়ে কম:
    4a1. System বর্তমান ব্যালান্স আর ঘাটতি দেখায়
    4a2. গ্রাহক কম পরিমাণ দেন → ধাপ 4-এ ফেরে
         অথবা বাতিল করেন → use case ব্যর্থভাবে শেষ,
         কোনো টাকা কাটা হয়নি

5a. PIN ভুল:
    5a1. System জানায় PIN ভুল, বাকি চেষ্টার সংখ্যা দেখায়
    5a2. গ্রাহক আবার PIN দেন → ধাপ 5-এ ফেরে
    5a3. পরপর তিনবার ভুল হলে System অ্যাকাউন্ট
         সাময়িক আটকে দেয়, গ্রাহককে জানায়
         → use case ব্যর্থভাবে শেষ

Minimal guarantee (যেকোনো অবস্থায়):
  টাকা আটকানো হলে হয় রিচার্জ সফল, নয়তো টাকা ফেরত;
  প্রতিটি চেষ্টার রেকর্ড থাকে
Success guarantee (সফল হলে):
  নম্বরে রিচার্জ হয়েছে, ব্যালান্স ঠিক ততটাই কমেছে,
  রসিদ দেখানো আর SMS পাঠানো হয়েছে

বাকি extension যোগ করলে পূর্ণ use case দাঁড়ায় এমন (একটি বাস্তব দল আরও কিছু যোগ করবে, যেমন দৈনিক সীমা):

UC-07  মোবাইল রিচার্জ করা
Primary actor: গ্রাহক      Scope: ওয়ালেট system (black box)      Level: user-goal
Supporting actors: অপারেটরের top-up সেবা, SMS সেবা
Stakeholders: গ্রাহক — সঠিক নম্বরে দ্রুত রিচার্জ, টাকা কাটলে রিচার্জ নিশ্চিত
              ওয়ালেট প্রতিষ্ঠান — নির্ভুল হিসাব, প্রতারণা রোধ, অভিযোগের রেকর্ড
Precondition: গ্রাহক লগইন করা আছেন, অ্যাকাউন্ট সক্রিয়
Trigger: গ্রাহক রিচার্জের অপশন বেছে নেন
Main success scenario:
  1. গ্রাহক মোবাইল নম্বর দেন
  2. System নম্বর যাচাই করে অপারেটর চিনে দেখায়
  3. গ্রাহক টাকার পরিমাণ দেন
  4. System ব্যালান্স ও সীমা যাচাই করে সারাংশ দেখায়
  5. গ্রাহক PIN দিয়ে নিশ্চিত করেন
  6. System PIN যাচাই করে টাকা আটকে রাখে, অপারেটরকে অনুরোধ পাঠায়
  7. অপারেটরের সেবা সফলতা জানায়
  8. System লেনদেন চূড়ান্ত করে, রসিদ দেখায়, SMS পাঠায়
Extensions:
  *a. গ্রাহক যেকোনো সময় বাতিল করেন: ধাপ 6-এর আগে হলে কিছুই বদলায় না
  2a. নম্বর বৈধ নয় (১১ অঙ্ক নয়, বা অচেনা অপারেটর): System কারণ দেখায় → ধাপ 1
  4a. ব্যালান্স কম: System ঘাটতি দেখায়; গ্রাহক পরিমাণ বদলান → ধাপ 4, বা বাতিল
  4b. পরিমাণ সীমার বাইরে (১০ টাকার কম বা ১০০০ টাকার বেশি): System সীমা জানায় → ধাপ 3
  5a. PIN ভুল: System বাকি চেষ্টা জানায় → ধাপ 5; পরপর তিনবার ভুল হলে অ্যাকাউন্ট সাময়িক আটকায়
  7a. অপারেটর সময়মতো সাড়া দেয় না বা ব্যর্থ জানায়:
      7a1. System আটকে রাখা টাকা ফেরত দেয়, গ্রাহককে জানায়; use case ব্যর্থভাবে শেষ
Minimal guarantee: টাকা আটকানো হলে হয় রিচার্জ সফল, নয়তো টাকা ফেরত; প্রতিটি চেষ্টার রেকর্ড থাকে
Success guarantee: রিচার্জ হয়েছে, ব্যালান্স ঠিক ততটাই কমেছে, রসিদ ও SMS গেছে
Variations: 1. নম্বর হাতে লেখা বা contact তালিকা থেকে বাছা যায়
Open question: অপারেটর দেরিতে সফলতা জানালে (টাকা ফেরতের পরে) কী হবে?

Include আর extend — সংক্ষেপে

অনেক use case একই ধাপ ব্যবহার করে — রিচার্জ, টাকা পাঠানো, বিল পরিশোধ সবই “PIN দিয়ে নিশ্চিত করা” চায়। এই ভাগ করা অংশ আলাদা subfunction use case হতে পারে, আর মূল use case তাকে প্রতিবার ব্যবহার করে — UML-এ এটি «include» সম্পর্ক, ড্যাশ তীর মূল use case থেকে ভাগ করা use case-এর দিকে। আবার কিছু আচরণ শুধু নির্দিষ্ট শর্তে আরেকটি use case-এর একটি নির্দিষ্ট জায়গায় যোগ হয় — যেমন রিচার্জ শেষে গ্রাহক চাইলে নম্বরটি প্রিয় তালিকায় রাখা। এটি «extend», তীর বাড়তি use case থেকে মূলটির দিকে, আর মূল use case জানেই না কে তাকে বাড়াচ্ছে। Cockburn-সহ অনেকে সতর্ক করেন, এই সম্পর্কের জটিল জাল বানানো সময় নষ্ট; লেখা use case-এ সাধারণ extension-ই যথেষ্ট। Diagram-এ এগুলো কীভাবে আঁকতে হয়, actor আর system boundary-সহ, তা পর্ব ২৩-এ।

৪ · User story — কার্ড, আলাপ আর নিশ্চিতকরণ

As a <role>, I want <goal>, so that <benefit>.

As a prepaid customer, I want to top up any mobile number from my wallet,
so that I can recharge my family's phones without visiting a shop.

তিনটি অংশেরই কাজ আছে। Role বলে কার জন্য — “As a user” লিখলে কিছুই বলা হয় না; গ্রাহক, এজেন্ট, হিসাবরক্ষক আলাদা মানুষ, আলাদা চাহিদা। অনেক দল নির্দিষ্ট persona ব্যবহার করে, যেমন “রিনা, যিনি গ্রামে মা-বাবার ফোনে রিচার্জ পাঠান”। Goal বলে কী চান, সমাধান কী হবে তা নয়। আর benefit বলে কেন — এটিই সবচেয়ে বেশি বাদ পড়ে, অথচ এটি থেকেই বোঝা যায় কোন সমাধান যথেষ্ট আর কোনটি বাড়াবাড়ি।

তিনটি C

এই ৩টি C (Ron Jeffries, ২০০১) মনে রাখলে একটি সাধারণ ভুল এড়ানো যায়: story-কে ছোট SRS ভেবে কার্ডে সব লিখে ফেলা, অথবা উল্টো, শুধু কার্ড লিখে আলাপ না করেই কাজ শুরু করা। Story backlog-এ কীভাবে থাকে আর refinement-এ কীভাবে বড় item ভাঙা হয়, তা পর্ব ০৫-এ দেখেছেন; এখানে আমরা story-র মান নিয়ে কথা বলছি।

INVEST — ভালো story-র ছয় গুণ

২০০৩ সালে Bill Wake একটি লেখায় ভালো story-র গুণ মনে রাখার জন্য INVEST সংক্ষিপ্ত রূপটি দেন:

“দ্রুত” শব্দটি testable করতে হলে মাপ লাগে — যেমন “৯৫% রিচার্জে নিশ্চিতকরণ ৩ সেকেন্ডের মধ্যে” — আর এমন মাপ আসলে non-functional requirement, যা পর্ব ২১-এর বিষয়। অনেক দল এমন শর্ত আলাদা story না বানিয়ে সব story-র ওপর প্রযোজ্য constraint বা Definition of Done-এ রাখে।

INVEST বিচার মানুষের কাজ, কিন্তু কিছু লক্ষণ যান্ত্রিকভাবেও ধরা যায়। নিচের প্রোগ্রাম কাল্পনিক ওয়ালেটের পাঁচটি story-তে কয়েকটি সরল নিয়ম (heuristic) চালায়: নির্ভরতা আছে কি না, সমাধানের শব্দ (database, button) আছে কি না, “so that” আছে কি না, point দেওয়া হয়েছে কি না আর ৮-এর বেশি কি না, অস্পষ্ট শব্দ আছে কি না, acceptance criteria আছে কি না।

// Heuristic INVEST check of fictional mobile-wallet stories (a helper, not a judge).
const stories = [
  { id: "S1", text: "As a customer, I want to top up any prepaid number, so that I can recharge without visiting a shop", points: 3, dependsOn: [], ac: 3 },
  { id: "S2", text: "As a customer, I want to save frequent numbers", points: 2, dependsOn: ["S1"], ac: 2 },
  { id: "S3", text: "As a developer, I want a recharge table in the database, so that the API can store data", points: 2, dependsOn: [], ac: 0 },
  { id: "S4", text: "As a customer, I want top-up to be fast and easy, so that I enjoy the app", points: null, dependsOn: [], ac: 0 },
  { id: "S5", text: "As a customer, I want to pay all my utility bills, so that I never miss a due date", points: 21, dependsOn: [], ac: 1 },
];
const MAX_POINTS = 8;                                  // team rule: bigger than this = split it
const VAGUE = ["fast", "easy", "user-friendly", "all", "etc"];
const DESIGN = ["database", "table", "api", "button", "dropdown"];
function check(s) {
  const issues = [];
  const words = s.text.toLowerCase().split(/[^a-z-]+/);
  if (s.dependsOn.length) issues.push("I: depends on " + s.dependsOn.join(", "));
  const design = DESIGN.filter(w => words.includes(w));
  if (design.length) issues.push("N: fixes the solution (" + design.join(", ") + ")");
  if (!/so that/i.test(s.text)) issues.push("V: no 'so that' - benefit unclear");
  if (/^as a developer/i.test(s.text)) issues.push("V: role is the team, not a user");
  if (s.points === null) issues.push("E: not estimated yet");
  else if (s.points > MAX_POINTS) issues.push("S: " + s.points + " points > " + MAX_POINTS);
  const vague = VAGUE.filter(w => words.includes(w));
  if (vague.length) issues.push("T: vague words (" + vague.join(", ") + ")");
  if (s.ac === 0) issues.push("T: no acceptance criteria");
  return issues;
}

let ok = 0;
for (const s of stories) {
  const issues = check(s);
  if (issues.length === 0) ok++;
  console.log(s.id + (issues.length ? " needs work" : " looks OK"));
  issues.forEach(i => console.log("   " + i));
}
console.log(ok + " of " + stories.length + " pass the heuristic; people still decide.");

S1 looks OK
S2 needs work
   I: depends on S1
   V: no 'so that' - benefit unclear
S3 needs work
   N: fixes the solution (database, table, api)
   V: role is the team, not a user
   T: no acceptance criteria
S4 needs work
   E: not estimated yet
   T: vague words (fast, easy)
   T: no acceptance criteria
S5 needs work
   S: 21 points > 8
   T: vague words (all)
1 of 5 pass the heuristic; people still decide.

৫ · Acceptance criteria আর Given-When-Then

Acceptance criteria হলো story-র “Confirmation”: কোন শর্তগুলো মিললে Product Owner কাজটি গ্রহণ করবেন। দুটি প্রচলিত রূপ আছে।

Given-When-Then ছাঁচটি behaviour-driven development (BDD) থেকে এসেছে; Dan North ২০০৬ সালের একটি লেখায় BDD-র পরিচয় দেন, আর ছাঁচটির উদ্ভবে Chris Matts-এর ভূমিকার কথাও তিনি উল্লেখ করেন। এই উদাহরণ লেখার সবচেয়ে প্রচলিত ভাষা Gherkin, যা Cucumber (২০০৮-এর দিকে Aslak Hellesøy-এর শুরু করা) আর তার মতো আরও tool পড়তে পারে।

এবার রিচার্জ story-র নিয়মের তালিকা থেকে ধাপে ধাপে Gherkin উদাহরণ বানাই। সীমাগুলো এই কাল্পনিক অ্যাপের: প্রতি রিচার্জে ন্যূনতম ১০, সর্বোচ্চ ১০০০ টাকা।

As a prepaid customer, I want to top up any mobile number,
so that I can recharge my family's phones without a shop.

☐ পরিমাণ ন্যূনতম ১০, সর্বোচ্চ ১০০০ টাকা
☐ ব্যালান্সের বেশি হলে রিচার্জ হবে না, টাকা কাটবে না
☐ নম্বর ১১ অঙ্কের, 01 দিয়ে শুরু
☐ সফল হলে রসিদ দেখাবে, ব্যালান্স কমবে

Scenario: Not enough balance
  Given my wallet balance is 50 taka
  When I top up 100 taka to a prepaid number
  Then I should see "Not enough money"
  And my balance should be 50 taka

Scenario: Successful top-up
  Given my wallet balance is 500 taka
  When I top up 100 taka to a prepaid number
  Then I should see "Top-up successful"
  And my balance should be 400 taka
  But no SMS should be sent before the operator confirms

amount 9     → "Minimum is 10"       balance 2000 থাকে
amount 10    → "Top-up successful"   balance 1990
amount 1000  → "Top-up successful"   balance 1000
amount 1001  → "Maximum is 1000"     balance 2000 থাকে
+ আগের দুটি scenario = ৬টি প্রায় একই scenario

Feature: Mobile top-up
  Background:
    Given I am logged in as a prepaid customer
  Scenario Outline: Amount and balance rules
    Given my wallet balance is <balance> taka
    When I top up <amount> taka to a prepaid number
    Then I should see "<message>"
    And my balance should be <after> taka
    Examples:
      | balance | amount | message           | after |
      | 2000    | 9      | Minimum is 10     | 2000  |
      | 2000    | 10     | Top-up successful | 1990  |
      | 2000    | 1000   | Top-up successful | 1000  |
      | 2000    | 1001   | Maximum is 1000   | 2000  |
      | 500     | 100    | Top-up successful | 400   |
      | 50      | 100    | Not enough money  | 50    |
  Scenario: Invalid number
    When I top up 100 taka to "0170"
    Then I should see "Enter an 11-digit number"

Tool কীভাবে Outline থেকে আসল scenario বানায়? নিচের ছোট প্রোগ্রামটি একটি Outline পড়ে, প্রতিটি <placeholder>-কে Examples-এর সেই কলামের মান দিয়ে বদলে দেয়। এটি আসল Gherkin parser নয় — Background, Rule, একাধিক Outline বা টেবিলে | escape সামলায় না — শুধু মূল ধারণা দেখায়।

// A tiny Gherkin reader: expand one Scenario Outline + Examples into concrete scenarios.
const feature = `Feature: Mobile top-up
  Scenario Outline: Top-up amount rules
    Given my wallet balance is <balance> taka
    When I top up <amount> taka to a prepaid number
    Then I should see "<message>"
    And my balance should be <after> taka

    Examples:
      | balance | amount | message           | after |
      | 500     | 100    | Top-up successful | 400   |
      | 500     | 5      | Minimum is 10     | 500   |
      | 50      | 100    | Not enough money  | 50    |`;

const lines = feature.split("\n").map(l => l.trim()).filter(l => l !== "");
let title = "", header = null;
const steps = [], rows = [];
for (const line of lines) {
  if (line.startsWith("Scenario Outline:")) title = line.slice(17).trim();
  else if (/^(Given|When|Then|And|But) /.test(line)) steps.push(line);
  else if (line.startsWith("|")) {
    const cells = line.split("|").slice(1, -1).map(c => c.trim());
    if (header === null) header = cells; else rows.push(cells);
  }
}

rows.forEach((row, i) => {
  console.log("Scenario: " + title + " #" + (i + 1));
  for (const step of steps) {
    const filled = step.replace(/<([^>]+)>/g, (m, name) => row[header.indexOf(name)]);
    console.log("  " + filled);
  }
});
console.log(steps.length + " steps x " + rows.length + " rows -> " + rows.length + " scenarios");

Scenario: Top-up amount rules #1
  Given my wallet balance is 500 taka
  When I top up 100 taka to a prepaid number
  Then I should see "Top-up successful"
  And my balance should be 400 taka
Scenario: Top-up amount rules #2
  Given my wallet balance is 500 taka
  When I top up 5 taka to a prepaid number
  Then I should see "Minimum is 10"
  And my balance should be 500 taka
Scenario: Top-up amount rules #3
  Given my wallet balance is 50 taka
  When I top up 100 taka to a prepaid number
  Then I should see "Not enough money"
  And my balance should be 50 taka
4 steps x 3 rows -> 3 scenarios

Definition of Ready বনাম Definition of Done

Definition of Ready সাহায্য করে, কিন্তু সাবধান: একে কঠোর দরজা বানালে (“সব খুঁটিনাটি লেখা না হলে নেব না”) আবার ছোট waterfall ফিরে আসে, আর আলাপের জায়গা হারায়। অনেক অভিজ্ঞ coach তাই একে একটি নির্দেশিকা হিসেবে রাখার পরামর্শ দেন, চুক্তি হিসেবে নয়। Definition of Done-এর বিস্তারিত পর্ব ০৫-এ।

৬ · Epic থেকে story থেকে task — ভাঙার কৌশল

সংক্ষেপে: epic হলো এমন বড় চাহিদা, যা এক Sprint-এ হয় না; story এক Sprint-এর ভেতরে শেষ হয় আর নিজে ব্যবহারকারীর কাছে মূল্য দেয়; task হলো story শেষ করার কারিগরি কাজ (table বানানো, API লেখা, test লেখা), সাধারণত এক দিন বা কম। Bill Wake একই ২০০৩ সালের লেখায় task-এর জন্য SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) গুণের কথা বলেন। Epic আর task-এর মধ্যে কত স্তর থাকবে (theme, feature, initiative…), তা tool আর প্রতিষ্ঠান-ভেদে আলাদা; কোনো সার্বজনীন নিয়ম নেই।

উল্লম্ব ভাগ, স্তর ধরে নয়

বড় story ভাঙার সবচেয়ে সাধারণ ভুল হলো কারিগরি স্তর ধরে ভাগ: “UI story”, “API story”, “database story”. কোনো একটি টুকরো একা ব্যবহারকারীর কাজে লাগে না, আর শেষে জোড়া দেওয়ার সময় ঝুঁকি একসাথে ফাটে। ভালো story splitting কেকের মতো উল্লম্বভাবে কাটে — প্রতিটি টুকরোয় সব স্তরের একটু করে, কিন্তু শুরু থেকে শেষ পর্যন্ত কাজ করে। কোন রেখা ধরে কাটবেন, তার কিছু প্রচলিত pattern আছে; Richard Lawrence-এর “Patterns for Splitting User Stories” (২০০৯-এর দিকের লেখা, পরে Humanizing Work-এর নির্দেশিকা) এবং Mike Cohn-এর SPIDR (Spike, Path, Interface, Data, Rules) এগুলোর জনপ্রিয় সংকলন — নাম আর সংখ্যা উৎস-ভেদে একটু আলাদা।

এবার একটি epic ধাপে ধাপে ভাঙি। পর্ব ০৫-এর refinement উদাহরণে workflow আর ধরন দিয়ে ভাঙা দেখেছেন; এখানে একাধিক pattern একসাথে, আর শেষে INVEST দিয়ে যাচাই।

E-3  As a customer, I want to pay my utility bills from the wallet,
     so that I don't have to stand in a queue at the bank.
     মোটা অনুমান: ~34 point → এক Sprint-এ হবে না

B1  পোস্টপেইড বিদ্যুৎ বিল: হিসাব নম্বর লিখে পুরো বকেয়া
    পরিশোধ, স্ক্রিনে রসিদ
B8  SMS-এ রসিদ
E-3 (বাকি): অন্য বিল, নিয়ম, ব্যর্থতা, বিলদাতা সেভ

B1  পোস্টপেইড বিদ্যুৎ (সরলতম পথ)
B4  গ্যাস বিল
B5  পানির বিল
B6  প্রিপেইড বিদ্যুৎ মিটার (টোকেন কেনা)
B8  SMS-এ রসিদ
E-3 (বাকি): নিয়ম, ব্যর্থতা, বিলদাতা সেভ

B3  due date পার হলে বিলম্ব ফি-সহ বকেয়া দেখানো
    (B1-এ আপাতত due date-এর আগের বিলই)
E-3 (বাকি): ব্যর্থতা, বিলদাতা সেভ

B2  বিলদাতা সাড়া না দিলে টাকা ফেরত ও গ্রাহককে জানানো
B7  বিলদাতা সেভ করা, নাম বদলানো, মুছে ফেলা

SP1 Spike: প্রিপেইড মিটারের API বোঝা — timebox ২ দিন
B1  পোস্টপেইড বিদ্যুৎ, পুরো বকেয়া, স্ক্রিনে রসিদ   5
B2  বিলদাতা সাড়া না দিলে টাকা ফেরত              3
B3  বিলম্ব ফি-সহ বকেয়া                          3
B4  গ্যাস বিল                                  3
B5  পানির বিল                                  3
B6  প্রিপেইড মিটার (SP1-এর পরে)                  5
B7  বিলদাতা সেভ / বদল / মুছে ফেলা                3
B8  SMS-এ রসিদ                                 2
                                       মোট 27

৭ · Story map — backbone, walking skeleton আর release slice

সাধারণ backlog একটি লম্বা এক-মাত্রিক তালিকা। সেখানে ২০০টি story থাকলে বোঝা কঠিন, কোনগুলো মিলে ব্যবহারকারী শুরু থেকে শেষ পর্যন্ত একটি কাজ করতে পারবেন। Jeff Patton এই সমস্যার উত্তরে story map জনপ্রিয় করেন (তাঁর ২০০৫ সালের দিকের লেখা থেকে, আর ২০১৪ সালের বই User Story Mapping-এ পূর্ণ রূপে)।

• Backbone: ওপরের সারিতে ব্যবহারকারীর প্রধান কাজ (activity), বাঁ থেকে ডানে তাঁর যাত্রার ক্রমে।
• Story: প্রতিটি activity-র নিচে তার story, ওপরে বেশি জরুরি, নিচে কম।
• Release slice: আড়াআড়ি রেখা টেনে ভাগ; রেখার ওপরের সব story মিলে একটি release.
• Walking skeleton: প্রথম slice — প্রতিটি activity-র অন্তত একটি সবচেয়ে সরল story, যাতে পুরো যাত্রা অন্তত কোনোভাবে চলে। শব্দটি Alistair Cockburn-এর লেখায় প্রচলিত হয়।

খেয়াল করুন, walking skeleton-এ PIN নেই — এটি বাস্তব গ্রাহকের হাতে দেওয়ার জন্য নয়, দলের ভেতরে প্রমাণ করার জন্য যে পুরো পথ (নিবন্ধন থেকে লেনদেন দেখা পর্যন্ত) সব স্তর পেরিয়ে চলে। গ্রাহকের হাতে যাবে Release 1 (MVP), যেখানে PIN যোগ হয়েছে। এভাবে শুরুতেই integration-এর ঝুঁকি ধরা পড়ে, শেষের দিকে নয়। নিচের প্রোগ্রাম ঠিক এই নিয়মে map কাটে: প্রতিটি backbone ধাপের সবচেয়ে বেশি অগ্রাধিকারের প্রথম story যায় walking skeleton-এ, বাকি story অগ্রাধিকার (১ must, ২ should, ৩ could) অনুযায়ী পরের slice-এ।

// Story map slicer: backbone steps + prioritised stories -> walking skeleton, then releases.
const backbone = ["Sign up", "Add money", "Top up", "History"];
const stories = [   // pri: 1 must, 2 should, 3 could; pts = story points
  { step: "Sign up",   text: "Register with phone + OTP",        pri: 1, pts: 3 },
  { step: "Sign up",   text: "Set a PIN",                        pri: 1, pts: 2 },
  { step: "Sign up",   text: "Verify identity with ID photo",    pri: 2, pts: 5 },
  { step: "Add money", text: "Cash in at an agent",              pri: 1, pts: 3 },
  { step: "Add money", text: "Add money from a bank account",    pri: 2, pts: 8 },
  { step: "Top up",    text: "Top up any number, fixed amounts", pri: 1, pts: 3 },
  { step: "Top up",    text: "Detect the operator",              pri: 2, pts: 3 },
  { step: "Top up",    text: "Save favourite numbers",           pri: 3, pts: 2 },
  { step: "History",   text: "List last 10 transactions",        pri: 1, pts: 2 },
  { step: "History",   text: "Download a PDF statement",         pri: 3, pts: 3 },
];
const slices = { "Walking skeleton": [], "Release 1 (MVP)": [], "Release 2": [], "Later": [] };
for (const step of backbone) {
  const col = stories.filter(s => s.step === step).sort((a, b) => a.pri - b.pri);
  if (col.length === 0) { console.log("WARNING: no story for step " + step); continue; }
  slices["Walking skeleton"].push(col[0]);           // thinnest end-to-end path
  for (const s of col.slice(1)) {
    const name = s.pri === 1 ? "Release 1 (MVP)" : s.pri === 2 ? "Release 2" : "Later";
    slices[name].push(s);
  }
}
let total = 0;
for (const [name, list] of Object.entries(slices)) {
  const pts = list.reduce((a, s) => a + s.pts, 0);
  total += pts;
  console.log(name + " - " + list.length + (list.length === 1 ? " story, " : " stories, ") + pts + " points, total so far " + total);
  list.forEach(s => console.log("   [" + s.step + "] " + s.text));
}

Walking skeleton - 4 stories, 11 points, total so far 11
   [Sign up] Register with phone + OTP
   [Add money] Cash in at an agent
   [Top up] Top up any number, fixed amounts
   [History] List last 10 transactions
Release 1 (MVP) - 1 story, 2 points, total so far 13
   [Sign up] Set a PIN
Release 2 - 3 stories, 16 points, total so far 29
   [Sign up] Verify identity with ID photo
   [Add money] Add money from a bank account
   [Top up] Detect the operator
Later - 2 stories, 5 points, total so far 34
   [Top up] Save favourite numbers
   [History] Download a PDF statement

৮ · Use case বনাম user story, আর job story

বাস্তবে দুটি একসাথেও চলে। অনেক দল জটিল লক্ষ্যের জন্য একটি হালকা use case লিখে প্রসঙ্গ আর extension ধরে রাখে, তারপর তার main success scenario আর extension থেকে story বানায় — যেমন অংশ ৬-এর B2 আসলে একটি extension-এর রূপ। Jacobson নিজেও ২০১১ সালে সহলেখকদের সাথে “Use-Case 2.0” নামে একটি নির্দেশিকা প্রকাশ করেন, যেখানে use case-কে ছোট “slice”-এ কেটে backlog item বানানোর পদ্ধতি দেওয়া আছে।

Job story — ভূমিকার বদলে পরিস্থিতি

When <situation>, I want to <motivation>, so I can <expected outcome>.

When my mother's phone runs out of balance late at night,
I want to send her a top-up in under a minute,
so I can be sure she can call me if she needs to.

Job story ছাঁচটি ২০১৩ সালের দিকে Intercom নামের একটি software প্রতিষ্ঠানের product দলের লেখায় আসে, পরে Alan Klement-এর লেখায় বিস্তৃত হয় বলে প্রচলিত; ভিত্তি Clayton Christensen-এর “jobs to be done” ধারণা। যুক্তি: একই ভূমিকার (গ্রাহক) দুজন মানুষের পরিস্থিতি একেবারে আলাদা হতে পারে, আর পরিস্থিতিই ঠিক করে কোন সমাধান কাজের। “রাত, তাড়া, মায়ের ফোন” পড়লেই বোঝা যায় এখানে প্রিয় নম্বর আর দ্রুত পথ গুরুত্বপূর্ণ। যেখানে ভূমিকা সত্যিই ফারাক তৈরি করে (যেমন এজেন্ট আর গ্রাহকের অনুমতি আলাদা), সেখানে user story-ই পরিষ্কার। কোনোটিই নিয়ম নয়; দলগুলো প্রয়োজনমতো মেশায়।

৯ · AI-এর যুগে use case আর user story

AI কয়েক সেকেন্ডে পঞ্চাশটি user story আর শ-খানেক Gherkin scenario লিখে দিতে পারে। দেখতে নিখুঁত, কিন্তু সেগুলো আপনার ব্যবহারকারীর সাথে কোনো আলাপ থেকে আসেনি — ৩টি C-এর মাঝের C-টিই বাদ। তাই AI-এর লেখা story-কে খসড়া ধরুন, আর stakeholder-এর সাথে মিলিয়ে নিন।

Software engineering-এ AI ব্যবহারের চেকলিস্ট

• AI-এর লেখা প্রতিটি story-র role, benefit আর acceptance criteria-র সংখ্যা ও নিয়ম একজন আসল stakeholder-এর সাথে মিলিয়েছি
• AI-এর Gherkin থেকে বানানো test সত্যিই ভুল ধরে কি না, ইচ্ছা করে ভুল কোডে চালিয়ে দেখেছি — যে test কখনো ব্যর্থ হয় না, সে কিছুই যাচাই করে না
• AI-এর বলা লেখক, বই, সাল বা মানদণ্ডের সংস্করণ মূল উৎসে মিলিয়েছি
• AI যে Git command দিয়েছে (বিশেষ করে reset --hard বা push --force), তা আগে একটি আলাদা clone-এ চালিয়েছি আর git help পড়েছি
• Prompt-এ কোনো গ্রাহকের ব্যক্তিগত তথ্য, password বা key দিইনি, আর AI-এর দেওয়া কোড বা টেমপ্লেটের license যাচাই করেছি