Backlog, Increment, User Story và mấy thuật ngữ quản lý việc

Ba Artifacts của Scrum

Artifact là thông tin hoặc sản phẩm được tạo ra và quản lý trong Scrum. Có 3 cái, mỗi cái đi kèm một commitment:

Artifact Commitment Ý nghĩa
Product Backlog Product Goal Mục tiêu dài hạn của sản phẩm
Sprint Backlog Sprint Goal Mục tiêu của Sprint
Increment Definition of Done (DoD) Tiêu chuẩn chất lượng để coi là hoàn thành

Ba cái này giúp mọi thứ minh bạch hơn và có cơ sở để kiểm tra kết quả thật.

Product Backlog

Danh sách có thứ tự các việc cần làm để cải thiện sản phẩm. Nó không phải danh sách chốt cứng từ đầu dự án rồi để nguyên đến cuối. Nó đổi liên tục khi team có thêm thông tin, nhận phản hồi và hiểu sản phẩm hơn.

Ví dụ minh họa thứ tự ưu tiên:

  • P0 (cao): Login, Product Detail, Checkout
  • P1: Search, Filter, Wishlist
  • P2 (thấp hơn): AI Chatbot, Recommendation

P0, P1, P2 chỉ là cách minh họa cho dễ hiểu, không phải cấu trúc bắt buộc của Scrum.

Sprint Backlog

Gồm 3 thứ: Sprint Goal, các Product Backlog Item được chọn cho Sprint, và kế hoạch hành động để làm ra Increment.

Phân biệt: Product Backlog là toàn bộ việc có thể cần cho sản phẩm. Từ đó team chọn một phần cho Sprint, phần đó thành Sprint Backlog.

Ví dụ Product Backlog có Login, Register, Search, Filter, Cart, Payment, AI, Analytics. Team chọn cho Sprint 1: Login, Register, Forgot password. Sprint Backlog thuộc quyền quản lý của Developers và được cập nhật suốt Sprint khi team hiểu việc hơn.

Increment

Phần gia tăng của sản phẩm, là một bước tiến cụ thể hướng tới Product Goal. Increment phải đạt Definition of Done.

Ví dụ Sprint 1 làm Login, Register, Forgot password. Nếu mấy chức năng này đạt DoD và tích hợp ổn với các Increment trước đó thì mới thành Increment. Increment phải dùng được và đạt chuẩn chất lượng đã thống nhất. Nên không phải cứ code xong một task là tự nhiên có Increment hoàn chỉnh.

Definition of Done (DoD)

Mô tả chính thức về mức chất lượng mà Increment phải đạt. Ví dụ checklist team E-commerce có thể đặt:

  • Code đã hoàn thành
  • Đã Code Review
  • Đã qua các bài test cần thiết
  • Đáp ứng Acceptance Criteria
  • Không còn lỗi nghiêm trọng chưa xử lý
  • Đã tích hợp vào hệ thống
  • Đáp ứng các tiêu chuẩn chất lượng chung

Đây chỉ là ví dụ, mỗi team tự điều chỉnh theo sản phẩm. Mục đích là cả team cùng hiểu “xong” nghĩa là gì.

Product Goal và Sprint Goal

  • Product Goal: trạng thái tương lai mà sản phẩm hướng tới. Ví dụ: xây nền tảng bán giày online cho khách tìm kiếm, chọn và mua sản phẩm thuận tiện.
  • Sprint Goal: mục tiêu thống nhất của một Sprint. Ví dụ: giúp khách tìm kiếm và lọc sản phẩm theo tên và thương hiệu.

Hình dung là Product Goal ở xa, mỗi Sprint Goal là một bước đưa team tiến gần hơn. Sprint Goal không phải danh sách task, nó là mục đích chung của Sprint và giúp Developers linh hoạt chỉnh kế hoạch khi cần.

Một yêu cầu đi xuyên Scrum thế nào?

Giả sử PO nói: “Tao muốn khách hàng đăng nhập bằng Google.” Không có nghĩa dev lao vào code ngay. Yêu cầu cần được làm rõ trước. Luồng minh họa:

Idea → Requirement → User Story → Acceptance Criteria → Product Backlog → sắp xếp ưu tiên → Sprint Planning → Sprint Backlog → Development → Testing → Increment → Sprint Review → Feedback → chỉnh lại Backlog.

Đây chỉ là luồng minh họa. Thực tế việc làm rõ, test, lấy feedback có thể diễn ra xuyên suốt Sprint chứ không phải lúc nào cũng tuần tự từng bước.

User Story

Cách phổ biến để mô tả nhu cầu người dùng dưới góc nhìn của chính họ. Format hay gặp:

As a [user], I want [something], so that [benefit].

Tức là: tôi là ai, tôi muốn gì, để làm gì.

Acceptance Criteria

Các điều kiện cụ thể để xác định một yêu cầu đã đáp ứng mong đợi hay chưa. Cách viết phổ biến là Given – When – Then:

  • Given: điều kiện ban đầu
  • When: khi có một hành động
  • Then: kết quả mong đợi

Ví dụ với User Story tìm kiếm sản phẩm: Given user đang ở trang Product, When user nhập “Nike”, Then hệ thống chỉ hiển thị những sản phẩm phù hợp.

Mấy điều kiện khác có thể thêm: không có kết quả thì hiện empty state, search không phân biệt hoa thường, có thể xóa keyword, kết quả trả về trong thời gian hợp lý.

Đừng nhầm với DoD nha:

  • Acceptance Criteria: điều kiện cho một yêu cầu cụ thể
  • Definition of Done: tiêu chuẩn chất lượng chung cho mọi Increment

Epic, Feature, Task, Bug

Thuật ngữ Là gì Ví dụ
Epic Nhóm chức năng lớn, cần nhiều phần nhỏ để xong Authentication
Feature Một chức năng cụ thể của sản phẩm Đăng nhập bằng Google
User Story Mô tả nhu cầu người dùng Khách muốn đăng nhập nhanh bằng Google
Task Việc cụ thể cần làm Tạo Google OAuth callback
Bug Lỗi khiến phần mềm chạy sai mong đợi Đăng nhập Google lỗi khi callback

Mấy thuật ngữ này hay gặp trong Jira và nhiều công cụ quản lý dự án. Nhưng không có cấu trúc phân cấp Epic → Feature → User Story → Task nào bắt buộc cho mọi team, mỗi nơi tổ chức một kiểu.

Bài viết khác

Test Automation(Kiểm thử tự động)

1.Test Automation (Kiểm thử tự động) là gì? Trong các dự án phát triển phần mềm truyền thống trước đây, toàn bộ quy trình kiểm thử (Testing) đều được thực hiện thủ công (Manual Testing) bởi con người. Các kiểm thử viên trực tiếp thao tác trên giao diện, nhập dữ liệu, kiểm tra kết […]

Logging – Monitoring – CI/CD

Logging, Monitoring và CI/CD là gì? Vai trò trong phát triển Backend 1. Tổng quan Khi xây dựng một ứng dụng Backend, viết code và chạy được chương trình mới chỉ là bước đầu. Khi ứng dụng được đưa vào sử dụng, lập trình viên còn cần biết ứng dụng đang hoạt động như thế […]

Redis & Caching là gì?

Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]

Background Jobs & Queues

1. Background Jobs & Queues là gì? Trong một ứng dụng backend, không phải công việc nào cũng cần hoàn thành ngay trong lúc xử lý HTTP request. Ví dụ, khi người dùng đăng ký tài khoản, hệ thống có thể cần: Lưu thông tin người dùng vào database. Gửi email xác nhận. Gửi thông […]

Saga Pattern

Saga Pattern là gì? Quản lý Transaction trong kiến trúc Microservices 1. Saga Pattern là gì? Saga Pattern là một mẫu thiết kế được sử dụng để quản lý các nghiệp vụ phân tán gồm nhiều bước xử lý, trong đó mỗi bước có thể thực hiện một local transaction tại một service hoặc Database […]

Two-Phase Locking (2PL)

Two-Phase Locking (2PL) là gì? Cơ chế khóa hai pha trong Database 1. Two-Phase Locking (2PL) là gì? Two-Phase Locking (2PL — khóa hai pha) là một giao thức quản lý khóa trong Database, quy định cách một transaction được phép lấy và giải phóng lock trong quá trình thực thi. Khi nhiều transaction cùng […]

Leave a Reply

Your email address will not be published. Required fields are marked *