User Story là điểm giao tiếp trực tiếp nhất giữa BA và Developer — viết mơ hồ dẫn tới xây sai tính năng, phải làm lại tốn thời gian cả team. Nhà tuyển dụng dùng bài tập viết User Story thực tế ngay trong buổi phỏng vấn khá phổ biến.
Format quen thuộc "As a [role], I want [feature], so that [benefit]" chỉ là khung sườn — phần quan trọng thực sự nằm ở lý do (so that). Nhiều ứng viên viết User Story chỉ có "what" mà bỏ qua "why", khiến Developer không hiểu được mục đích để tự đưa ra quyết định hợp lý khi gặp tình huống chưa lường trước trong lúc code.
"Acceptance Criteria khác User Story ở điểm nào?" — User Story mô tả nhu cầu ở mức khái quát, Acceptance Criteria định nghĩa CHÍNH XÁC khi nào tính năng được coi là "hoàn thành đúng" — bao gồm cả trường hợp thành công (happy path) và các trường hợp ngoại lệ (edge case, error case).
"Given-When-Then (Gherkin syntax) là gì, tại sao nhiều BA dùng?" — Given (điều kiện tiền đề) - When (hành động) - Then (kết quả mong đợi) — cấu trúc này giúp Acceptance Criteria rõ ràng, dễ chuyển thành test case tự động (BDD - Behavior Driven Development), và giảm mơ hồ hơn nhiều so với viết văn xuôi tự do.
"Viết User Story cho tính năng 'quên mật khẩu' của 1 ứng dụng." — Câu trả lời tốt không chỉ viết 1 story chung chung mà chia nhỏ theo các bước trong luồng (yêu cầu reset, nhận email, đặt mật khẩu mới), mỗi bước có Acceptance Criteria riêng bao gồm cả trường hợp lỗi (email không tồn tại, link hết hạn, mật khẩu mới không đủ mạnh).
Viết User Story quá lớn (không thể hoàn thành trong 1 sprint — cần chia nhỏ/splitting), thiếu Acceptance Criteria cho trường hợp lỗi (chỉ mô tả happy path), hoặc viết theo góc nhìn hệ thống thay vì góc nhìn người dùng ("Hệ thống sẽ lưu dữ liệu vào database" thay vì "Người dùng muốn dữ liệu của họ được lưu lại an toàn").
Khi được yêu cầu viết User Story trong buổi phỏng vấn, hãy hỏi lại làm rõ ngữ cảnh trước khi viết (ai là user, mục tiêu kinh doanh là gì) — thể hiện tư duy phân tích thật, không chỉ áp dụng công thức máy móc.