User Story đó phải được code bởi một Developer duy nhất.

User Story đó có thể được phát triển, kiểm thử và release mà không phụ thuộc chặt chẽ vào việc hoàn thành các Story khác, giúp linh hoạt thay đổi thứ tự ưu tiên.

User Story đó không cần liên kết với Epic nào.

User Story đó không cần dữ liệu đầu vào từ hệ thống khác.

Chia theo lớp kỹ thuật: Sprint 1 làm Database, Sprint 2 làm API, Sprint 3 làm Giao diện.

Chia theo giá trị nghiệp vụ end-to-end: Slice 1 "Vay cho khách hàng lương chuyển khoản (đơn giản)"; Slice 2 "Vay cho khách hàng tự doanh (phức tạp)".

Chia theo người làm: Sprint 1 cho BA viết tài liệu, Sprint 2 cho Dev code.

Chia theo màn hình: Sprint 1 làm màn hình 1, Sprint 2 làm màn hình 2.

Mô tả hành động của người dùng.

Mô tả kết quả mong đợi sau khi thực hiện hành động.

Mô tả trạng thái ban đầu hoặc điều kiện tiên quyết (Pre-condition) của hệ thống trước khi người dùng tương tác. (Đúng)

Mô tả dữ liệu đầu ra của hệ thống.

Vì Dev cần NFR để chọn kiến trúc hệ thống (Architecture) phù hợp ngay từ đầu, tránh việc phải đập đi xây lại khi hệ thống không chịu tải nổi. (Đúng)

Vì NFR giúp giao diện đẹp hơn.

Vì NFR là phần dễ nhất để viết.

Vì Tester không thể test chức năng nếu thiếu NFR.

Use Case A là một biến thể tùy chọn của Use Case B.

Hành vi của Use Case B luôn được thực hiện (bắt buộc) như một phần trong luồng sự kiện của Use Case A (Ví dụ: "Chuyển tiền" include "Xác thực đăng nhập"). (Đúng)

Use Case A mở rộng chức năng của Use Case B trong một số điều kiện nhất định.

Use Case A và Use Case B chạy song song không liên quan nhau.

Khi chỉ cần mô tả logic code if-else đơn giản cho Dev.

Khi cần mô tả quy trình nghiệp vụ phức tạp, liên quan đến nhiều phòng ban (Swimlanes), có luồng song song và cần chuẩn hóa để Business và Tech cùng hiểu. (Đúng)

Khi muốn vẽ giao diện người dùng.

Khi cần mô tả cấu trúc dữ liệu database.

Xác nhận rằng Story đã hoàn thành việc code và test.

Xác nhận rằng Story đã đủ thông tin (FR/NFR/AC/Design) để Dev có thể bắt đầu làm mà không bị block bởi sự thiếu rõ ràng.

Xác nhận rằng Product Owner đã trả tiền cho dự án.

Xác nhận rằng User Story đã được deploy lên Production.

Vì dãy số này đẹp mắt.

Để phản ánh sự không chắc chắn (Uncertainty) tăng dần theo cấp số nhân khi kích thước công việc lớn hơn, giúp team tránh rơi vào bẫy ước lượng quá chính xác cho những thứ phức tạp.

Để Dev dễ cộng điểm.

Để hạn chế số lượng Story trong một Sprint.

Alternate Flow là luồng lỗi; Exception Flow là luồng thành công.

Alternate Flow là một cách khác để đạt được mục tiêu thành công (Ví dụ: Chuyển tiền bằng thẻ thay vì tài khoản); Exception Flow là khi gặp lỗi và không đạt được mục tiêu (Ví dụ: Hết số dư).

Hai khái niệm này là một.

Exception Flow luôn dẫn đến việc hệ thống bị sập (Crash).