Mở đầu — vì sao bài này quan trọng
Ở ba bài trước, bạn đã hiểu BA là ai, rèn kỹ năng communication và analytical thinking, rồi học cách gom yêu cầu (requirements gathering). Nhưng có một sự thật phũ phàng mà nhiều bạn mới ra trường không nhận ra: thu thập được yêu cầu chưa đủ để trở thành một BA. Nếu bạn nghe khách hàng nói xong rồi giữ hết trong đầu, hoặc ghi vội vài dòng vào điện thoại, thì bạn mới chỉ làm một nửa công việc. Nửa còn lại — và cũng là phần quyết định người ta có tuyển bạn hay không — là biến những gì bạn nghe được thành tài liệu mà dev, tester, designer và sếp đều đọc hiểu và làm theo được.
Trong thực tế đi làm, không ai nhìn thấy bạn "phân tích" trong đầu như thế nào. Cái người ta nhìn thấy là deliverable — sản phẩm bạn giao ra. Với một BA fresher, deliverable đầu tiên và quan trọng nhất chính là User Story và bộ tài liệu BA cơ bản. Đây là "ngôn ngữ chung" giữa business (bên muốn có phần mềm) và technical (bên xây phần mềm). Viết được User Story rõ ràng, bạn đã có thứ để đưa vào CV, để nói trong phỏng vấn, và quan trọng hơn — để làm việc thật ngay từ ngày đầu.
Bài này sẽ dạy bạn viết User Story đúng chuẩn, hiểu Acceptance Criteria ở mức nền tảng, và tạo ra tài liệu BA đầu tiên của đời mình. Đây không phải lý thuyết suông — cuối bài bạn sẽ có một document thật để bỏ vào portfolio.
Khái niệm cốt lõi
User Story là gì?
User Story là một câu mô tả ngắn gọn một tính năng phần mềm, viết từ góc nhìn của người dùng cuối. Nó không phải bản đặc tả kỹ thuật dài dòng, mà là một lời nhắc ngắn để cả team cùng thảo luận. Công thức kinh điển mà bạn sẽ dùng suốt sự nghiệp là:
> As a [loại người dùng], I want [muốn làm gì], so that [để đạt được lợi ích gì].
Tạm dịch: Là một [ai đó], tôi muốn [làm gì đó], để [đạt được điều gì].
Ba mảnh này không thừa mảnh nào. "As a" cho biết ai đang dùng — CEO và nhân viên kho có nhu cầu khác hẳn nhau. "I want" là hành động cụ thể. "So that" là lý do — phần mà fresher hay bỏ quên nhất, nhưng lại quan trọng nhất, vì nó cho dev hiểu mục đích để đề xuất giải pháp tốt hơn.
Ví dụ một User Story tốt cho ứng dụng đặt đồ ăn:
> Là một khách hàng đang đói, tôi muốn lọc quán ăn theo thời gian giao dưới 30 phút, để tôi chọn được quán giao nhanh mà không phải mở từng quán.
So với một câu tệ: "Làm chức năng lọc quán ăn." Câu tệ không cho biết ai lọc, lọc theo gì, và để làm gì — dev sẽ phải đoán, và đoán sai là chuyện thường.
INVEST — thước đo một User Story tốt
Cộng đồng Agile dùng bộ tiêu chí INVEST để kiểm tra chất lượng User Story. Bạn nên thuộc lòng:
- Independent — độc lập, không phụ thuộc chằng chịt vào story khác.
- Negotiable — có thể thương lượng, không phải hợp đồng đóng cứng.
- Valuable — mang lại giá trị rõ ràng cho người dùng hoặc business.
- Estimable — team ước lượng được công sức làm.
- Small — đủ nhỏ để làm xong trong một sprint.
- Testable — kiểm thử được, tức là có tiêu chí để biết "xong hay chưa".
Acceptance Criteria — điều kiện "được nghiệm thu"
User Story cho biết cái gì và tại sao, nhưng nó cố tình mơ hồ về chi tiết. Acceptance Criteria (AC) là danh sách điều kiện cụ thể để xác định khi nào story được coi là hoàn thành. Không có AC, bạn và dev sẽ cãi nhau vô tận về "thế nào là xong".
Có hai cách viết AC phổ biến:
Cách 1 — Danh sách checklist: liệt kê từng điều kiện.
- Người dùng nhập số điện thoại 10 chữ số mới cho bấm nút Đăng ký.
- Nếu số điện thoại đã tồn tại, hiện thông báo "Số này đã được đăng ký".
Gherkin đặc biệt mạnh vì tester có thể dịch thẳng nó thành test case. Là fresher, bạn nên tập cả hai, nhưng ưu tiên Gherkin khi kịch bản có nhiều bước.
Bộ tài liệu BA cơ bản bạn cần biết
Ngoài User Story, một BA fresher cần làm quen với vài loại tài liệu nền tảng. Ở bài này ta chỉ cần hiểu ở mức để tạo ra được tài liệu đầu tiên — chi tiết sâu về SRS/BRD/FRS sẽ có bài riêng sau. Ba thứ bạn sẽ chạm tay ngay:
- Product Backlog — danh sách các User Story được sắp xếp theo độ ưu tiên.
- Story với AC — mỗi mục backlog kèm điều kiện nghiệm thu.
- Mockup/mô tả bổ trợ — vài dòng hoặc hình vẽ tay giải thích story trực quan hơn.
Tình huống thực tế
Ví dụ 1 — Startup giao đồ ăn "AhaEat" và bài học "so that"
Giả định một startup giao đồ ăn tên AhaEat tại TP.HCM đang xây tính năng đánh giá quán. Bạn — BA fresher — nhận yêu cầu từ chị Product Owner: "Cho khách chấm sao quán ăn." Bạn hí hửng viết:
> Là khách hàng, tôi muốn chấm sao cho quán, để đánh giá quán.
Chị PO đọc và hỏi lại: "Đánh giá để làm gì? Cho khách khác tham khảo, hay cho quán tự cải thiện, hay cho AhaEat lọc quán kém?" Bạn ngớ người. Ba mục đích đó dẫn tới ba thiết kế hoàn toàn khác nhau. Sau khi hỏi lại, bạn viết lại:
> Là một khách hàng vừa nhận đơn, tôi muốn chấm sao và viết nhận xét về quán, để những khách hàng sau tham khảo trước khi đặt.
Với "so that" rõ ràng, dev quyết định hiển thị đánh giá công khai trên trang quán và sắp xếp quán nhiều sao lên đầu. Bài học: phần "so that" không phải trang trí — nó là chiếc la bàn định hướng giải pháp. Bỏ nó đi, cả team đi lạc.
Ví dụ 2 — Ngân hàng số và sức mạnh của Acceptance Criteria
Một ngân hàng số (giả định tên VBank Digital) làm tính năng chuyển tiền nhanh. BA fresher viết story:
> Là chủ tài khoản, tôi muốn chuyển tiền cho số tài khoản khác, để thanh toán cho người khác.
Story ổn, nhưng dev làm xong thì tester báo lỗi tùm lum: chuyển được số tiền âm, chuyển 0 đồng vẫn thành công, chuyển vượt số dư vẫn qua. Vì sao? Vì story không có AC. Sau sự cố, bạn bổ sung:
> - Given tài khoản có số dư 500.000đ, When người dùng nhập số tiền lớn hơn 500.000đ, Then hệ thống báo "Số dư không đủ" và chặn giao dịch. > - Số tiền chuyển tối thiểu là 10.000đ; nhập nhỏ hơn thì báo lỗi. > - Không cho nhập số âm hoặc chữ. > - Sau khi chuyển thành công, hiện màn hình xác nhận kèm mã giao dịch.
Lần này dev và tester có checklist rõ ràng, số lỗi giảm hẳn. Bài học: trong domain nhạy cảm như ngân hàng, AC không phải tùy chọn — nó là tấm khiên bảo vệ khỏi rủi ro tiền bạc. Một BA fresher biết viết AC đầy đủ được đánh giá cao hơn hẳn người chỉ viết story trơn.
Ví dụ 3 — Bạn sinh viên tận dụng nền tảng cũ để viết story
Bạn Minh, sinh viên năm cuối ngành Quản trị kinh doanh, từng làm thêm ở một cửa hàng thời trang và hiểu rõ quy trình bán hàng. Khi tập viết User Story cho một web bán hàng để làm portfolio, Minh không hề bí ý tưởng — vì cậu đã trải nghiệm vai trò người dùng thật. Cậu viết:
> Là nhân viên bán hàng, tôi muốn tìm sản phẩm theo mã vạch, để tính tiền cho khách nhanh vào giờ cao điểm.
Story này rất "đời" vì Minh biết giờ cao điểm quầy đông thế nào. Bài học quan trọng cho fresher: background cũ của bạn — dù là bán hàng, gia sư, làm kho, hay chạy sự kiện — chính là mỏ vàng góc nhìn người dùng. BA giỏi không phải người biết nhiều công nghệ, mà là người hiểu sâu nhu cầu con người. Đừng coi thường kinh nghiệm đời thường của mình; hãy dùng nó để viết những User Story chân thật.
Hướng dẫn từng bước
Đây là quy trình để bạn tạo ra tài liệu BA đầu tiên — một mini backlog cho một tính năng nhỏ.
Bước 1 — Chọn một tính năng nhỏ, quen thuộc. Đừng chọn "cả một app ngân hàng". Hãy chọn thứ bạn hiểu: "đăng nhập", "giỏ hàng", "đặt lịch hẹn". Nhỏ để bạn tập trung vào cách viết, không sa đà vào phạm vi.
Bước 2 — Liệt kê các loại người dùng (actor). Ai sẽ dùng tính năng này? Khách hàng? Admin? Nhân viên? Viết ra tất cả. Mỗi actor thường sinh ra story riêng.
Bước 3 — Viết User Story theo công thức. Với mỗi nhu cầu, điền vào ba ô: As a… / I want… / So that…. Cố gắng đừng bỏ trống "so that". Nếu bạn không nghĩ ra lợi ích, có thể nhu cầu đó không thật sự cần thiết.
Bước 4 — Kiểm tra bằng INVEST. Đọc lại từng story: nó có nhỏ không? Có testable không? Có giá trị không? Story nào quá to, hãy tách đôi. Ví dụ "quản lý tài khoản" nên tách thành "đăng ký", "đăng nhập", "đổi mật khẩu".
Bước 5 — Viết Acceptance Criteria cho mỗi story. Tự hỏi: "Làm sao tôi biết story này xong?" Liệt kê các điều kiện, gồm cả trường hợp thành công (happy path) và trường hợp lỗi (edge case: nhập sai, để trống, vượt giới hạn). Ưu tiên Given–When–Then cho kịch bản phức tạp.
Bước 6 — Sắp thứ tự ưu tiên. Story nào quan trọng nhất, làm trước? Dùng một cách đơn giản: đánh dấu Cao / Trung / Thấp. Đây là bản Product Backlog sơ khai của bạn.
Bước 7 — Trình bày gọn gàng. Bỏ tất cả vào một file (Google Docs, Notion, hoặc Excel). Tiêu đề rõ ràng, mỗi story một khối, kèm AC bên dưới. File này chính là deliverable đầu tiên để bạn khoe trong portfolio và phỏng vấn.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết story kiểu "chỉ đạo kỹ thuật". Fresher hay viết "Tôi muốn hệ thống dùng API POST để lưu dữ liệu vào bảng users". Sai! User Story mô tả nhu cầu người dùng, không phải cách dev cài đặt. Hãy để dev quyết định giải pháp kỹ thuật. Mẹo: nếu story của bạn chứa từ như "database", "API", "button màu xanh" ở phần "I want", hãy viết lại.
Lỗi 2 — Story quá to. "Là admin, tôi muốn quản lý toàn bộ hệ thống" — không ai làm xong nổi trong một sprint và cũng không testable. Mẹo: nếu bạn không ước lượng được thời gian làm, story đang quá to, hãy tách nhỏ.
Lỗi 3 — Bỏ qua edge case trong AC. Chỉ viết trường hợp thành công. Người dùng thật sẽ nhập sai, để trống, bấm hai lần. Mẹo: với mỗi input, luôn hỏi "nếu để trống thì sao? nếu nhập quá dài thì sao? nếu bấm liên tục thì sao?".
Lỗi 4 — Quên phần "so that". Như ví dụ AhaEat đã chỉ ra, thiếu lý do khiến cả team đoán mò. Mẹo: coi "so that" là bắt buộc, không phải tùy chọn.
Lỗi 5 — Nhồi nhiều nhu cầu vào một story. "Tôi muốn đăng nhập và xem lịch sử đơn và đổi mật khẩu" là ba story bị gộp. Mẹo: một story = một mục tiêu.
Mẹo vàng: Đọc to User Story của bạn cho một người không rành công nghệ (bạn cùng phòng, người thân) nghe. Nếu họ hiểu được ngay, story của bạn đạt. Nếu họ nhíu mày, bạn cần viết lại. User Story sinh ra để ai cũng đọc hiểu — đó là toàn bộ giá trị của nó.
Bài tập thực hành
Bài tập 1 — Sửa story hỏng. Cho story sau, hãy viết lại cho đúng chuẩn và bổ sung phần "so that": > "Làm chức năng tìm kiếm sản phẩm."
Bài tập 2 — Viết mini backlog. Chọn tính năng "đặt lịch khám bệnh online". Hãy:
- Liệt kê ít nhất 2 actor (ví dụ: bệnh nhân, lễ tân).
- Viết 4 User Story theo công thức As a / I want / So that.
- Kiểm tra 4 story bằng INVEST, ghi chú story nào cần tách nhỏ.
Hãy viết ít nhất 4 Acceptance Criteria theo định dạng Given–When–Then, trong đó có tối thiểu 2 edge case (ví dụ: hủy lịch đã quá giờ, hủy lịch không tồn tại).
Bài tập 4 — Tạo deliverable portfolio. Gom kết quả của Bài tập 2 và 3 vào một file Google Docs hoặc Notion trình bày gọn gàng, đặt tên "Backlog mẫu — Đặt lịch khám online". Đây là tài liệu BA đầu tiên bạn có thể đưa vào portfolio và mang đi phỏng vấn.
Tóm tắt
User Story là "ngôn ngữ chung" giữa business và technical, viết theo công thức As a / I want / So that — trong đó phần "so that" là la bàn định hướng giải pháp, đừng bao giờ bỏ. Kiểm tra chất lượng story bằng bộ INVEST: độc lập, thương lượng được, có giá trị, ước lượng được, đủ nhỏ, testable. Mỗi story cần đi kèm Acceptance Criteria — điều kiện nghiệm thu cụ thể, viết theo checklist hoặc Given–When–Then, và luôn bao gồm cả edge case chứ không chỉ trường hợp thành công.
Qua các ví dụ AhaEat, VBank Digital và bạn Minh, bạn thấy rằng: thiếu "so that" khiến team đi lạc, thiếu AC khiến sản phẩm đầy lỗi, và background đời thường của bạn chính là mỏ vàng để viết story chân thật. Deliverable đầu tiên của bạn — một mini backlog gồm story kèm AC được sắp ưu tiên — không chỉ là bài tập, mà là vũ khí thật để bỏ vào portfolio và tỏa sáng khi phỏng vấn BA fresher. Hãy hoàn thành bốn bài tập ở trên; bạn sẽ có tài liệu BA đầu tiên của đời mình trong tay.