SCRUM GUIDE - KEN SCHWABER VÀ JEFF SUTHERLAND

Scrum
Guide

Tác giả: Ken Schwaber và
Jeff Sutherland

Dịch: Dương Trọng Tấn

Lời nói đầu

(cho bản dịch )

Với yêu cầu về mặt phương pháp phát triển phần mềm phải đảm bảo sự gọn nhẹ, linh hoạt nhưng hiệu
quả, từ đầu những năm 1990, hàng loạt các phương pháp phát triển phần mềm linh hoạt (agile software
development, còn gọi tắt là Agile) ra đời nhằm đáp ứng yêu cầu ngày càng đa dạng và phức tạp của thực
tiễn phát triển phần mềm trên thế giới. Scrum được phát triển tương đối sớm bởi hai tác giả của nó là Ken
Schwaber và Jeff Sutherland, và sớm trở thành một trong các phương pháp thành công nhất trong các
phương pháp phát triển linh hoạt do sự đơn giản, hiệu quả và thú vị mà nó mang lại. Người dùng Scrum
không chỉ ấn tượng với năng suất cực cao mà còn cảm nhận rõ ràng sự thay đổi trong cách làm việc: trách
nhiệm hơn, hiệu quả hơn, và thú vị hơn.

Vài năm trở lại đây Scrum đã được du nhập vào Việt Nam, trước hết thông qua các cơng ty có yếu tố nước
ngồi, sau đó đã xuất hiện chủ động ngày càng nhiều ở các cơng ty làm phần mềm suốt từ Nam chí Bắc.
Nhu cầu về cơng việc và học tập Scrum vì thế tăng lên đáng kể trong một hai năm gần đây. Tuy vậy, chưa
có tổ chức giáo dục đào tạo nào đưa Scrum vào đào tạo chính quy, cũng như chưa có tài liệu chính quy nào
bằng tiếng Việt được cung cấp cho người dùng và người học Scrum để rút ngắn thời gian tiếp cận với
phương pháp làm việc vô cùng hiệu quả và hấp dẫn này. Trước tình hình đó, một nhóm những người thực
hành Scrum đã tập hợp lại dưới hình thức nhóm những người sử dụng Agile và Scrum để cùng chia sẻ kinh
nghiệm tại Hà Nội (www.HanoiScrum.net ) và Thành phố Hồ Chí Minh (www.AgileVietnam.org). Cùng
chung nỗ lực với cộng đồng, người dịch tài liệu này mong muốn kiến thức về Scrum được giới thiệu tới
người quan tâm đến Scrum bằng chính ngơn ngữ mẹ đẻ - tiếng Việt hòng giúp cho việc học tập và sử dụng

Scrum trở nên hệ thống và có bài bản hơn. Đây là tài liệu dịch từ bản Scrum Guide xuất bản năm 2010 của
chính Ken Schwaber và Jeff Sutherland, cơng bố trên Scrum.org; và nó sẽ được cập nhật khi bản gốc có sự
chỉnh sửa.

Do đây là một trong số những tài liệu căn bản đầu tiên bằng tiếng Việt về Scrum nên có nhiều thuật ngữ
vẫn chưa được Việt hóa tốt, và vì vậy bạn đọc có thể thấy nhiều chỗ người dịch để cả thuật ngữ tiếng Anh
bên cạnh tiếng Việt. Trong quá trình dịch, người dịch cố gắng bám sát ý nghĩa và văn phong của tác giả.
Đồng thời, để cung cấp thêm thông tin cho người mới tiếp cận Scrum lần đầu, người dịch có chú giải thêm
một số thuật ngữ, và cung cấp phần phụ lục “Thuật ngữ Scrum” để bạn đọc tiện tra cứu. Sử dụng triết lý
tăng trưởng và tiến hóa của Scrum, các thuật ngữ này sẽ sớm được cập nhật dựa theo thực tiễn và sự
chấp nhận rộng rãi của cộng đồng sử dụng Scrum. Tài liệu tuy ngắn nhưng do khách quan hoặc trình độ
của người dịch, bản dịch có thể cịn nhiều lỗi hoặc nhiều chỗ có thể cải tiến cho tốt hơn; mọi đóng góp quý
báu về tài liệu này, xin vui lòng gửi về hộp thư để người dịch có cơ hội cải tiến
bản dịch ngày càng hoàn thiện hơn, cung cấp thêm giá trị cho người học và sử dụng Scrum.

Cuối cùng, người dịch xin trân trọng cảm ơn hai bạn đồng nghiệp, cũng là hai người thực hành Scrum,
Nguyễn Việt Khoa và Nguyễn Ngọc Tú đã bỏ công đọc và cung cấp nhiều góp ý quan trọng cho tài liệu này.

2 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Mục lục

Lời nói đầu .............................................................................................................................................. 2
Giới thiệu ................................................................................................................................................ 4

Tổng quan ........................................................................................................................................... 4
Con người ........................................................................................................................................... 4
Lược sử ............................................................................................................................................... 4
Mục đích ............................................................................................................................................. 4

Lý thuyết Scrum...................................................................................................................................... 5
Tính minh bạch ................................................................................................................................... 5
Việc thanh tra...................................................................................................................................... 5
Sự thích nghi....................................................................................................................................... 5
Nội dung Scrum ...................................................................................................................................... 6
Vai trị trong Nhóm Scrum .................................................................................................................. 7
ScrumMaster ...................................................................................................................................... 8
Product Owner - Chủ Sản phẩm .......................................................................................................... 9
Đội sản xuất - Team ............................................................................................................................ 9
Các Hộp Thời gian (Time-Box) .......................................................................................................... 10
Họp Kế hoạch phát hành - Release Planning Meeting ....................................................................... 10
Sprint – Phân đoạn nước rút ............................................................................................................. 12
Họp Kế hoạch Sprint - Sprint Planning Meeting ................................................................................ 13
Họp Sơ kết Sprint - Sprint Review ..................................................................................................... 15
Họp Cải tiến Sprint - Sprint Retrospective ......................................................................................... 15
Họp Scrum hằng ngày - Daily Scrum ................................................................................................. 16
Đồ nghề Scrum (Scrum Artifacts)...........................................................................................................17
Product Backlog và Release Burndown ..............................................................................................17
Sprint Backlog và Sprint Burndown................................................................................................... 19
Hoàn thành (hay Xong - Done) .......................................................................................................... 20
Lời cuối ................................................................................................................................................. 21
Phụ lục – Thuật ngữ Scrum ................................................................................................................... 23

3 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Giới thiệu

Tổng quan

Scrum được xây dựng trên các phương pháp thực hành đã được chấp nhận rộng
rãi qua hàng thập kỉ qua. Sau đó nó được coi như là lý thuyết quản lý thực
nghiệm (empirical process theory). Jim Coplien có lần đã nhấn mạnh với Jeff “tất
cả mọi người sẽ thích Scrum; nó thực sự là những gì mà chúng ta sẽ làm khi bị dồn
đến chân tường”.

Con người
Hàng nghìn người đã góp cơng xây dựng Scrum, chúng tơi chỉ là những người
thử nghiệm nó trong khoảng mươi năm đầu. Những người có thể kể đến gồm
Jeff Sutherland, cùng vời Jeff McKenna, Ken Schwaber cùng với Mike Smith và
Chris Martin. Scrum lần đầu được trình bày chính thức tại OOPSLA 1995. Trong
khoảng năm năm tiếp theo, Mike Beedle và Martine Devos đã có thêm nhiều
đóng góp quan trọng. Và sau đó, rất nhiều người khác đã cùng nhau cải tiến để
Scrum hồn thiện như hơm nay chúng ta thấy.

Lược sử
Scrum có một lịch sử tương đối dài trong thế giới phần mềm. Những nơi đầu tiên
áp dụng Scrum có thể kể đến Individual, Inc., Fidelity Investments, và IDX (bây
giờ là GE Medical).

Mục đích
Ngay từ những năm 1990, Scrum đã được dùng để phát triển các sản phẩm phức
tạp. Tài liệu này mô tả cách sử dụng Scrum để làm ra các sản phẩm phần mềm.
Scrum không phải là một quy trình hay một kĩ thuật để làm ra sản phẩm, mà là
một khung làm việc (framework) bao gồm nhiều quy trình và kĩ thuật khác.
Scrum có khả năng phát lộ tính hiệu quả của các hoạt động phát triển phần mềm
để từ đó bạn có thể cải tiến chúng trong khi cung cấp một khung làm việc để
phát triển các sản phẩm phức tạp.

4 Scrum Guide – Ken Schwaber và Jeff Sutherland

Bản Việt hóa này đang ở trạng thái beta

Lý thuyết Scrum
Scrum là một lý thuyết kiểm soát tiến trình thực nghiệm (emprical process
control), sử dụng cách tiếp cận lặp (iterative) và tăng trưởng (incremental) để tối
ưu hóa khả năng dự báo (predictability) và kiểm soát rủi ro. Ba giá trị cốt lõi (còn
gọi là Ba chân của Scrum) làm nên q trình kiểm sốt tiến trình thực nghiệm
bao gồm: tính minh bạch, việc thanh tra và sự thích nghi.

Tính minh bạch
Sự minh bạch đảm bảo tất cả các yếu tố của q trình có ảnh hưởng đến kết quả
được cơng khai cho tất cả những người có trách nhiệm với dự án. Khơng chỉ các
yếu tố đó được cơng khai, mà tất cả những gì đang được quan sát cũng phải
thơng suốt tới các bên. Điều đó có nghĩa là khi một người khảo sát một quy trình
tin rằng có việc gì đó được hồn thành, thì nó phải thỏa mãn tất cả các yêu cầu
trong định nghĩa thế nào là hoàn thành (“Definition of done”).

Việc thanh tra
Rất nhiều yếu tố trong quy trình cần phải được thanh tra thường xuyên để đảm
bảo tất cả các sai sót trong quy trình sớm được phát hiện. Tần suất thanh tra
được xác định sao cho các yếu tố của quy trình phát triển có thể thay đổi được
sau khi thanh tra, từ đó mở đường cho khả năng thích nghi của quy trình. Có vẻ
như càng thanh tra nhiều thì vấn đề càng phát sinh lắm. Nhưng may thay, điều
đó không đúng trong việc phát triển phần mềm. Chất lượng thanh tra khơng
hồn tồn do tần suất thanh tra quyết định, mà còn do các yếu tố khác nữa, như
kĩ năng thanh tra hay mức độ cần cù và tỉ mỉ của người thực hiện cơng tác thanh
tra.

Sự thích nghi
Nếu người thực hiện công tác thanh tra thấy rằng một vài chỗ trong quy trình là

bất thường, và hậu quả của nó có thể là khơng thể chập nhận được, thì quy trình
hoặc các yếu tố liên quan cần phải được điều chỉnh cho phù hợp. Việc điều chỉnh
phải kịp thời để giảm thiểu các lệch lạc khác có thể xảy ra.

Trong Scrum có ba thời điểm quan trọng cho việc thanh tra và thích nghi. Thứ
nhất là cuộc họp Daily Scrum, được dùng để rà sốt tiến độ cơng việc trong một

5 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Sprint, đồng thời có các hành động thích nghi để tối ưu hóa giá trị của các ngày là
việc tiếp theo. Thứ hai, buổi Họp Sơ kết Sprint (Sprint Review) và Họp kế hoạch
Sprint (Sprint Planning) được dùng để thanh tra tiến trình hướng đến Mục tiêu
Phát hành (Realease Goal) và có các hành động thích ứng để tối ưu hóa Sprint
tiếp theo. Cuối cùng, Buổi họp Cải tiến (Sprint Retrospective) được dùng để khảo
sát kĩ càng Sprint vừa diễn ra và xác định các biện pháp thích ứng cho Sprint kế
tiếp thêm năng suất, hoàn thiện và thú vị.

Nội dung Scrum
Khung làm việc Scrum bao gồm Nhóm Scrum (Scrum Team) với các vai trò được
định nghĩa rõ ràng; các Hộp thời gian (Time-Box), Đồ nghề (Artifact), và các Quy
tắc.

Nhóm Scrum được thiết kế để tối ưu hóa tính linh hoạt và năng suất lao động.
Để làm được điều đó, Nhóm Scrum thực hiện cơ chế tự quản, cơ cấu liên chức
năng (cross-functional) và làm việc tập trung trong các phân đoạn (iteration) lặp
đi lặp lại trong suốt dự án. Mỗi Nhóm Scrum có ba vai trị: một là ScrumMaster –
người chịu trách nhiệm cho các quy trình của dự án, hai là Product Owner (chủ
sản phẩm) – người chịu trách nhiệm cho giá trị của cơng việc mà Nhóm Scrum
làm, và ba là Đội sản xuất (Team) gồm những người trực tiếp làm ra phần mềm.

Đội sản xuất bao gồm các nhà phát triển (developer) với tất cả các kĩ năng cần
thiết để chuyển đổi yêu cầu của Product Owner thành các gói phần mềm hồn
chỉnh ở cuối mỗi Sprint.

Scrum sử dụng khái niệm Hộp thời gian (Time-Box) để thiết lập quy tắc cho
nhóm. Trong Scrum, các thành tố được đóng hộp (timeboxed) bao gồm buổi Họp
kế hoạch Phát hành (Release Planning Meeting), Họp Kế hoạch Sprint (Sprint
Planning Meeting), Sprint, Họp Scrum hằng ngày (Daily Scrum), Họp Sơ kết
Sprint (Sprint Review) và Họp Cải tiến Sprint (Sprint Retrospective). Trái tim của
Scrum chính là Sprint – một phân đoạn phát triển diễn ra trong phạm vi ít hơn
một tháng. Tất cả các Sprint trong cùng một dự án sử dụng cùng một khung làm
việc Scrum, Sprint nọ tiếp nối ngay sau Sprint kia và mỗi Sprint đều có kết quả

6 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

cuối cùng là các gói phần mềm hồn chỉnh chuyển giao được (potentially
shippable product increment).

Scrum sử dụng bốn “đồ nghề” (artifact) cơ bản bao gồm Product Backlog, Sprint

Backlog, Release Burndown và Sprint Burndown. Product Backlog chứa danh

sách ưu tiên các yêu cầu của dự án.

Sprint Backlog là danh sách công Mẹo

việc cần làm để biến Product Nếu không tìm thấy hướng dẫn từ các quy tắc
Backlog trong mỗi Sprint thành một Scrum, bạn phải tự xác định mình sẽ phải làm
gói phần mềm hồn chỉnh có thể những gì để cơng việc tiến triển. Do điều kiện

chuyển giao ngay. Release thực tiễn luôn thay đổi khôn lường, nên bạn
Burndown đo phần hạng mục còn lại đừng cố gắng tìm kiếm một giải pháp hoàn hảo.
trong Product Backlog trong một Kế Thay vì đó, hãy thử một phương án và xem nó
hoạch Phát hành. Cịn Sprint làm việc ra sao. Hãy để cơ chế thanh tra – thích
nghi (inspect-adapt) trong Scrum hướng dẫn bạn

Burndown đo các thời gian (ước đi tiếp như thế nào.

tính) cần thiết cịn lại để hồn tất các

tác vụ trong một Sprint.

Các quy tắc của Scrum gắn kết các yếu tố Hộp thời gian, Vai trò và Đồ nghề
(artifact) lại với nhau để Scrum phát huy tác dụng. Chúng ta sẽ dần tìm hiểu các
quy tắc của Scrum trong suốt tài liệu này. Ví dụ, Scrum có đặt ra quy tắc là chỉ
thành viên của Đội sản xuất – tức người có trách nhiệm với việc biến từng hạng
mục trong Product Backlog thành mỗi gói phần mềm (increment) – có thể nói
trong Daily Scrum. Trong tài liệu này, có nhiều gợi ý hữu ích cho việc triển khai
Scrum nhưng không phải là quy tắc của Scrum; chúng được mô tả trong các hộp
văn bản với các tiêu đề “Mẹo”.

Vai trị trong Nhóm Scrum

Nhóm Scrum bao gồm ScrumMaster, Product Owner và Đội sản xuất. Các thành
viên Nhóm Scrum được gọi là các chú “lợn”. Chủ Sản phẩm (Product Owner) là
“lợn” của Product Backlog. Đội sản xuất là “lợn” của các công việc trong Sprint.
ScrumMaster là “lợn” của tiến trình Scrum. Những người khác nếu có tham gia
vào dự án thì đều là “gà”. Gà khơng thể chỉ cho lợn biết phải làm việc ra sao. Hai
vai trò “lợn” và “gà” ở đây thực ra có xuất xứ từ một câu chuyện vui như sau:

7 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

“Một chị gà mái và một chú lợn cùng ở Mẹo
với nhau khi chú gà gợi ý: “Ta cùng mở
một nhà hàng nhé!”. ScrumMaster làm việc với khách hàng và bộ phận
quản lý để thiết lập một Chủ sản phẩm (Product
Chú lợn nghĩ một lúc và nói: “Ta sẽ gọi Owner). ScrumMaster sẽ dạy cho Product Owner
tên nhà hàng này là gì nhỉ?” cách làm việc trong nhóm. Product Owner sẽ học
được cách quản lý và tối ưu hóa giá trị khi dùng
Chị gà đáp lại: “Nhà hàng Thịt lợn và Scrum. Nếu Product Owner không làm được việc
Trứng gà!” của mình, ScrumMaster sẽ là người chịu trách
nhiệm.

Chú lợn kêu lên: “Ồ khơng, tơi thì bị

thịt cịn chị thì chỉ tham gia có thế thơi

ư?”. Mẹo

ScrumMaster Một thành viên, có thể là một lập trình viên,
ScrumMaster chịu trách nhiệm đảm trong Đội sản xuất có thể giữ vai trị

bảo tồn bộ Nhóm Scrum tuân thủ và ScrumMaster. Tuy nhiên, điều này thường dẫn
được hưởng lợi từ các giá trị của đến một số xung đột khi ScrumMaster phải lựa
Scrum, các kĩ thuật cũng như các quy chọn giữa việc “loại bỏ trở lực” hay thực thi
tắc của Scrum. ScrumMaster giúp đỡ nhiệm vụ đã chọn trong Sprint. ScrumMaster
khơng được phép làm Product Owner.

Nhóm Scrum cũng như một tổ chức

áp dụng được Scrum vào trong công việc của họ. ScrumMaster dạy cho Nhóm

Scrum bằng cách huấn luyện và dẫn dắt Nhóm để đạt được năng suất cao và làm

ra sản phẩm có chất lượng tốt. ScrumMaster giúp đỡ Nhóm Scrum hiểu và sử

dụng cơ chế tự tổ chức (self-organization) cũng như cơ cấu liên chức năng (cross-

functional) trong nhóm. ScrumMaster cũng giúp đỡ Nhóm Scrum phát huy tối đa

khả năng trong môi trường chưa được tổ chức tốt để vẫn có thể hiệu quả trong

các dự án phức tạp. Các cơng việc trợ giúp của ScrumMaster có đặc trưng cơ bản

là “loại bỏ trở lực” (removing impediment). ScrumMaster vừa là người lãnh đạo

vừa là đầy tớ của Nhóm Scrum.

8 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Product Owner - Chủ Sản phẩm
Product Owner là người duy nhất chịu trách nhiệm cho việc quản lý Product
Backlog và đảm bảo các giá trị cho Đội sản xuất làm việc. Product Owner duy trì
Product Backlog và đảm bảo Product Backlog được hiển thị cho tất cả mọi người.
Mọi người cần phải biết đâu là phần có độ ưu tiên cao hơn, để biết cần phải làm
việc với cái gì.

Chủ Sản phẩm là cá nhân, không phải là một ủy ban. Một ủy ban nào đó có thể
được thành lập để gợi ý hoặc tạo ảnh hưởng tới Product Owner, nhưng quyết
định cuối cùng liên quan đến việc thay đổi Product backlog là của Product Owner.
Các công ty sử dụng Scrum có thể có các cách thức khác nhau để thiết lập các độ
ưu tiên và yêu cầu theo thời gian.

Để đảm bảo thành công cho Product Owner, mọi người trong tổ chức cần phải
tôn trọng quyết định của người đảm nhiệm vai trị này. Khơng ai khác được
quyền áp đặt cách làm việc cho Đội sản xuất thông qua các bộ ưu tiên khác, và
Đội sản xuất bắt buộc phải lờ đi các áp đặt kiểu như vậy. Quyết định của Product
Owner luôn luôn minh bạch trong nội dung cũng như trong các mức độ ưu tiên.
Sự minh bạch này đòi hỏi Product Owner phải nỗ lực tối đa, và điều đó khiến cho
vai trị Product Owner vừa là yêu cầu, nhưng cũng là phần thưởng cho người
nắm giữ nó.

Đội sản xuất - Team

Đây là nhóm các nhà phát triển với mục tiêu chuyển đổi các yêu cầu trong

Product Backlog thành các gói sản phẩm sẵn sàng chuyển giao ở cuối mỗi Sprint.

Giống như Nhóm Scrum, Đội sản xuất cũng liên chức năng; các thành viên phải

có đầy đủ các kĩ năng cần thiết để

hồn thành các cơng việc phát triển. Mẹo

Thành viên Đội sản xuất thường có Product Owner có thể là một trong số các thành
một số kĩ năng chuyên biệt như lập viên đội phát triển. Trách nhiệm này có thể làm
trình, quản lý chất lượng, phân tích giảm khả năng làm việc với các bên liên quan.

nghiệp vụ, thiết kế, làm giao diện, Product Owner không thể làm ScrumMaster.

hoặc thiết kế cơ sở dữ liệu. Tuy

9 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

nhiên, bộ kĩ năng mà thành viên Đội sản xuất chia sẻ (đó là cách để hiểu yêu cầu
khách hàng và tiến hành chuyển đổi chúng thành sản phảm dùng được) sẽ trở
nên quan trọng hơn các kĩ năng còn lại. Trong Đội sản xuất, kiến trúc sư phần
mềm phải viết code. Khơng cịn các chức danh trong Đội sản xuất, chỉ có nhà
phát triển – developer, khơng có ngoại lệ. Một Đội sản xuất cũng khơng có các
phân đội chuyên biệt kiểu như đội kiểm thử hay đội phân tích thiết kế, chỉ có một
đội duy nhất – Đội sản xuất.

Đội sản xuất tự tổ chức lấy các hoạt động của mình. Khơng một ai, kể cả
ScrumMaster – phải chỉ cho nhóm biết phải làm gì để chuyển đổi yêu cầu thành
sản phẩm dùng được. Nhóm sẽ phải tự chịu trách nhiệm tìm ra giải pháp để làm
việc đó. Mỗi thành viên của nhóm sẽ phải áp dụng các chun mơn của mình để
giải quyết tất cả các vấn đề gặp phải. Sự hợp lực (synergy) sẽ mang lại kết quả
cuối cùng cũng như tăng độ hiệu quả của nhóm.

Độ lớn tối ưu cho một Đội sản xuất là bảy người, cộng trừ hai. Khi có ít hơn năm
người trong nhóm, sẽ có ít tương tác hơn và đem lại năng suất thấp hơn. Nếu lớn
hơn, nhóm sẽ gặp nhiều trở lực hơn trong Sprint và giảm khả năng hồn thành
cơng việc đúng hẹn trong mỗi Sprint. Nếu nhóm có nhiều hơn chín người, q
trình hợp nhất rất khó khăn, và cần nhiều nỗ lực hơn để quản lý cơng việc. Tuy
nhiên, trong thực tiễn vẫn có các nhóm lớn mà hiệu quả. Lưu ý là trong khi tính số
lượng thành viên của Đội sản xuất, ta khơng tính Product Owner và ScrumMaster
trừ khi bản thân họ tham gia Đội sản xuất , tức họ có tham gia vào quá trình thực

hiện các nhiệm vụ trong Sprint Backlog bên cạnh việc giữ các vai trò như Product
Owner hay ScrumMaster.

Cấu trúc nhóm có thể thay đổi khi Sprint kết thúc. Khi đó, mối quan hệ trong
nhóm thay đổi, và năng suất từ q trình tự tổ chức có thể giảm xuống. Hãy cẩn
thận với các thay đổi kiểu này.

Các Hộp Thời gian (Time-Box)

Họp Kế hoạch phát hành - Release Planning Meeting

10 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Mục đích của buổi họp lập kế hoạch cho phiên bản là tạo ra mục đích cũng như
một bản kế hoạch để cả Nhóm Scrum (bao gồm Product Owner, ScrumMaster và
Đội sản xuất) và phần còn lại của tổ chức có thể hiểu và giao tiếp với nhau. Cơng
tác lập kế hoạch bao gồm việc trả lời một số câu hỏi căn bản như “Làm sao để
biến tầm nhìn (vision) về sản phẩm thành sản phẩm thực sự theo cách khả thi
nhất?”, “Làm sao để đạt được hoặc làm tốt hơn sự mong đợi và thỏa mãn của
khách hàng cũng như về mặt hiệu quả đầu tư (ROI – Return on Investment)?”.
Bản Kế hoạch phát hành xác lập mục tiêu cho bản phát hành (release), độ ưu tiên
cao nhất cho Product Backlog, các rủi ro căn bản, và các tính năng mà phiên bản
phần mềm sẽ có. Bản kế hoạch đó cịn chứa ngày dự định phát hành, chi phí đầu
tư nếu khơng có gì thay đổi. Tổ chức có thể khảo sát tiến trình phát triển và thay
đổi bản kế hoạch này giữa các Sprint.

Việc lập Kế hoạch phát hành là khơng bắt buộc. Nếu Nhóm Scrum bắt đầu cơng
việc mà khơng họp lập kế hoạch phát hành, thì sự thiếu vắng kế hoạch đó có thể
coi như một trở ngại cần được loại bỏ (bằng cách nào đó) trong quá trình triển

khai Sprint sắp tới.

Các sản phẩm được xây dựng theo từng phân đoạn trong Scrum, ở đó mỗi Sprint
tạo ra một phần tăng trưởng cho sản phẩm, bắt đầu từ các phần có giá trị cao
nhất và ít rủi ro nhất. Cứ sau mỗi Sprint, sản phẩm sẽ lớn dần lên. Và các phần
tăng trưởng đóp góp cho sự hồn thiện của sản phẩm đó phải ln ln ở trạng
thái có thể chuyển giao được khi Sprint kết thúc. Khi nào có đủ các phần tăng
trưởng cần thiết, và đáp ứng được yêu cầu của các nhà đầu tư thì sản phẩm sẽ
được phát hành (released) tới người dùng.

Hầu hết các tổ chức hiện nay đều có quy trình lập kế hoạch phát hành sản phẩm
của mình, mà trong hầu hết các quy trình này thì phần lập kế hoạch hồn tất
trước khi bắt đầu quy trình sản xuất và khơng thay đổi gì sau đó. Trong Scrum,
buổi Họp kế hoạch Phát hành xác lập mục tiêu căn bản và đầu ra khả thi cho quy
trình. Phần này thường chỉ chiếm khoảng 15-20% thời gian so với thời gian mà
một tổ chức dành ra để lập kế hoạch theo kiểu truyền thống. Scrum thực hiện cơ
chế lập kế hoạch thời gian thực (just-in-time planning) thông qua các hộp thời

11 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

gian khác như Họp Sơ kết Sprint (Sprint Review), Họp Kế hoạch Sprint (Sprint

Planning), hay việc lập các kế hoạch chi tiết trong các buổi họp Daily Scrum. Về

tổng thể, Scrum có thể mất nhiều thì giờ hơn để lập kế hoạch phát hành so với

phương pháp truyền thống. Việc lập kế hoạch này bao gồm cả việc ước lượng và

sắp thứ tự ưu tiên cho các hạng mục trong Product Backlog cho bản phát hành

sắp tới. Có nhiều kĩ thuật để thực hiện

việc ước lượng này, Scrum không loại Mẹo

trừ bất kì phương pháp nào mà bạn biết,

miễn là nó hữu ích cho dự án. Nếu Đội sản xuất cảm thấy quá tải, có thể

Sprint – Phân đoạn nước rút gặp Product Owner để giảm bớt số yêu cầu
cần triển khai. Nếu nhóm thấy mình cịn dư

Mỗi Sprint là một phân đoạn (iteration) thời gian, có thể trao đổi với Product Owner
để chọn thêm hạng mục trong Product

trong quá trình phát triển phần mềm. Backlog để triển khai tiếp trong Sprint.

Các Sprint được đóng hộp thời gian.

Trong suốt Sprint, ScrumMaster cần đảm bảo khơng có sự thay đổi nào ảnh

hưởng đến mục tiêu của Sprint. Cả cấu trúc của Đội sản xuất và tiêu chuẩn về

chất lượng cũng không được thay đổi trong suốt Sprint. Sprint bao gồm buổi

Họp lập kế hoạch, Các công việc được thực hiện trong Sprint, Họp Sơ kết Sprint

và Họp Cải tiến Sprint (Sprint Retrospective). Các Sprint nối tiếp nhau, khơng có

thời gian ngừng nghỉ.

Một dự án thường có một mục đích xác định; trong việc phát triển phần mềm,
mục đích là tạo nên một sản phẩm hay một hệ thống. Mọi dự án đều xác định rõ
những thứ phải làm ra, kế hoạch để làm chúng, các công việc phải làm theo kế
hoạch đã vạch ra, và sản phẩm cuối cùng. Mỗi dự án đều có một tầm nhìn để tạo
một khung thời gian cho dự án. Nếu tầm nhìn quá xa, các mục tiêu có thể thay
đổi, và rất nhiều yếu tố gây nhiễu khác có thể khiến rủi ro có thể trở nên khơng
thể kiểm sốt nổi. Scrum là một khung làm việc cho một án có tầm nhìn khơng
dài hơn một tháng, vì nếu kéo dài hơn một tháng, độ phức tạp và rủi ro sẽ tăng
lên. Khả năng dự tính của dự án cần được kiểm sốt ít nhất mỗi lần trong tháng
để tránh khả năng các yếu tố rủi ro có thể vượt khỏi tầm kiểm soát.

12 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Sprint có thể bị hủy bỏ trước khi vượt khỏi hộp thời gian của Sprint. Chỉ có
Product Owner mới có đủ thẩm quyền để hủy bỏ một Sprint, mặc dù người đó
khơng chịu sức ép của bất kì ai như các bên liên quan, Đội sản xuất, hoặc
ScrumMaster. Câu hỏi đặt ra là: trong tình cảnh nào thì Sprint cần phải bị hủy bỏ?
Có thể là khi các hồn cảnh về thị trường hay công nghệ thay đổi, khiến cho Mục
tiêu Sprint trở nên lỗi thời. Nói chung, Sprint nên bị hủy nếu như nó khơng có ý
nghĩa gì trong hồn cảnh đó. Tuy nhiên, do mỗi Sprint chỉ diễn ra trong thời gian
ngắn nên ít khi ta phải làm như vậy.

Khi một Sprint bị hủy, các hạng mục đã hoàn tất được xem xét lại. Chúng sẽ được

chấp nhận nếu như chúng là một gói tăng trưởng có thể chuyển giao được. Tất

cả các hạng mục trong Product Backlog khác được đặt ngược trở lại trong

Product Backlog với ước lượng ban đầu của chúng. Các phần cơng việc hồn tất

liên quan đến các hạng mục này coi như mất. Tài nguyên sẽ bị lãng phí khi Sprint

bị dừng, và mọi người phải họp lại để lập kế hoạch và bắt đầu một Sprint mới.

Việc hủy Sprint thường khiến Đội sản

xuất bị sốc, nhưng rất ít khi nhóm phải Mẹo

trải nghiệm điều này.

Khi bắt đầu với Scrum, Đội sản xuất có thể

Họp Kế hoạch Sprint - Sprint chọn Sprint hai tuần để giảm bớt khả năng sa
Planning Meeting lầy vào sự bất định. Sprint kiểu này có thể
được đồng bộ hóa với các nhóm khác để cùng

Các cuộc họp Kế hoạch Sprint xảy ra khi làm ra hai gói tăng trưởng khác nhau.

ta lập kế hoạch cho một phân đoạn. Đó

là thời gian đóng hộp đến tám giờ cho một Sprint một tháng. Với các Sprint ngắn

hơn, phân bổ thời gian ít hơn cho việc lập kế hoạch Sprint (ví dụ, Sprint hai tuần

chỉ cần bốn giờ cho họp lập kế hoạch Sprint). Họp kế hoạch Sprint bao gồm hai

phần. Phần đầu tiên để lựa chọn các hạng mục cần hoàn thành trong Sprint. Phần

thứ hai (kéo dài bốn giờ cho một Sprint một tháng) xác định các hành động cần

thiết trong Sprint để xây dựng các phần tăng trưởng cho sản phẩm.

Có thể phân cuộc Họp kế hoạch Sprint thành hai phần đặc trưng: phần “Cái gì” và
phần “Thế nào”. Một số Nhóm Scrum gộp hai phần này làm một. Ở phần đầu
tiên, Nhóm Scrum trả lời cho câu hỏi “Cái gì?”. Ở đây, Product Owner trình bày

13 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

phần ưu tiên trong Product Backlog cho Đội sản xuất hiểu. Họ cùng hợp tác để
xác định các chức năng cần phải phát triển trong Sprint sắp tới. Đầu vào cho cuộc
họp này chính là Product Backlog và năng lực hiện có của Đội sản xuất. Lượng
Product Backlog mà Đội sản xuất lựa chọn hồn tồn phụ thuộc vào nhóm với
năng lực xác định của nó. Chỉ Đội sản xuất mới có thể xác định nó có khả năng
làm được những gì trong Sprint sắp tới.

Sau khi lựa chọn được các hạng mục trong Product Backlog, Mục tiêu Sprint
(Sprint Goal) sẽ được hình thành. Mục tiêu này sẽ đóng vai trò như kim chỉ nam
để Đội sản xuất làm ra các gói tăng trưởng cho dự án. Mục tiêu Sprint chính là
một phần của Mục tiêu Phát hành (Release Goal). Ví dụ như một mục tiêu cho
Sprint có thể được phát biểu như:” Tự động hóa việc chỉnh sửa tài khoản của
khách hàng thông qua một middleware với khả năng giao dịch an toàn”. Khi làm
việc, Đội sản xuất cần ghi nhớ mục tiêu này và thực hiện các công việc kĩ thuật
cần thiết để đạt được nó. Nếu cơng việc khó khăn hơn nhóm dự tính, thì Nhóm
cần hợp tác với Product Owner để phát triển một phần của mục tiêu đó.

Trong phần hai của Họp kế hoạch Sprint, nhóm trả lời câu hỏi “Thế nào?”. Nhóm
sẽ phải chỉ ra làm sao để biến các hạng mục đã được lựa chọn từ Product Backlog

trong phần trước của Họp kế hoạch Sprint thành ra các phần tăng trưởng của dự
án. Đội phát triển thường bắt đầu với việc thiết kế các công việc phải làm. Khi
thiết kế, Đội phát triển sẽ nhận biết các tác vụ phải thực hiện trong suốt Sprint
đó. Các tác vụ này chính là các cơng việc cụ thể cần thiết để biến Product Backlog
thành ra phần mềm chạy được. Tác vụ cần đủ nhỏ để chúng có thể được hồn tất
trong vịng một ngày. Danh sách cơng việc này được gọi là Sprint Backlog.
Nhóm sẽ tự tổ chức để thực hiện các công việc trong Sprint Backlog, cả khi họp
kế hoạch Sprint và khi làm việc trong Sprint.

Product Owner phải hiện diện trong phần hai của Họp kế hoạch Sprint để làm rõ
Product Backlog và giúp đỡ Đội phát triển đưa ra các quyết định tối ưu. Nếu
Nhóm phát triển phát hiện ra có quá ít hay q nhiều cơng việc, thì nhóm có thể
thương thảo lại với Product Owner về Product Backlog. Đội sản xuất có thể mời
một số người khác tham gia để cung cấp các trợ giúp về chuyên môn hay công

14 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

nghệ nếu thấy cần thiết. Một nhóm mới thường nhận thấy họ có thể bơi hay chết
chìm ngay trong buổi họp đầu tiên này. Nhóm sẽ sớm nhận ra rằng họ phải tự lực
cánh sinh. Và khi biết được điều đó, nhóm sẽ bắt đầu tự tổ chức với đặc thù và
hành động của một nhóm hiệu quả thực sự.

Họp Sơ kết Sprint - Sprint Review
Nhóm tổ chức một buổi họp Sơ kết Sprint (Sprint Review). Đây là một buổi họp
được đóng hộp trong bốn tiếng đối với Sprint một tháng. Với các Sprint ngắn
hơn, thời gian cho Sơ kết có thể rút ngắn lại (ví dụ, với Sprint hai tuần, có thể ta
chỉ cần khung thời gian hai giờ là đủ). Khi Sơ kết, Nhóm Scrum và những người
có liên quan cùng trao đổi về những thứ vừa hoàn thành trong Sprint vừa rồi.
Dựa trên cơ sở đó, cùng với các thay đổi trong Product Backlog khi Sprint diễn ra,

họ có thể cùng hợp tác để xác định những thứ cần phải hoàn tất trong Sprint tiếp
theo. Đây là một buổi họp khơng trang trọng, nên việc thuyết trình về các chức
năng vừa hoàn tất chỉ để phục vụ cho việc bàn bạc về những gì sẽ làm trong
Sprint tới chứ không phải để báo cáo như các buổi tổng kết thường thấy.

Cuộc họp cần phải có ít nhất các yếu tố sau đây để đảm bảo thành công. Product
Owner nhận biết được những gì đã hồn thành, những gì chưa. Đội sản xuất thảo
luận những gì đã thành cơng trong Sprint và có những vấn đề nào phát sinh, và
làm sao để giải quyết các vấn đề đó. Đội sản xuất trình diễn các cơng việc họ đã
hồn tất và trả lời các câu hỏi từ những người tham dự cuộc họp. Product Owner
sau đó thảo luận về Product Backlog, ngày dự kiến hoàn thành với nhiều giả định
về tốc độ phát triển của dự án. Toàn bộ nhóm sẽ hợp tác để cùng thấy hiện trạng
của dự án và xác định những công việc cần phải làm trong Sprint tới. Sprint
Review sẽ cung cấp các dữ liệu đầu vào vô cùng quan trọng cho buổi Họp kế
hoạch Sprint (Sprint Planning) tiếp theo.

Họp Cải tiến Sprint - Sprint Retrospective
Ngay sau khi Sơ kết Sprint, và trước khi buổi Họp kế hoạch cho Sprint tiếp theo,
Nhóm Scrum họp Sprint Retrospective. Buổi họp này đóng hộp trong khoảng
thời gian ba giờ đồng hồ cho một Sprint một tháng (phân bổ thời gian hợp lý cho
các Sprint ngắn hơn). Trong cuộc họp này, ScrumMaster khuyến khích Nhóm

15 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Scrum chỉnh sửa lại quy trình trong khn khổ của khung làm việc Scrum nhằm
cải tiến quy trình, khiến cho quy trình trở nên hiệu quả hơn và thú vị hơn vào
Sprint sau. Bạn có thể tham khảo rất nhiều tài liệu và sách vở đã được xuất bản
đề cập đến các kĩ thuật hữu ích để thực hiện cơng tác Retrospective.

Mục đích của Retrospective là để khảo sát kĩ lưỡng tất cả các yếu tố tham gia vào
quy trình trong Sprint vừa qua, bao gồm con người, các mối quan hệ, quy trình và
cơng cụ. Q trình khảo sát này cần phải nhận ra và ưu tiên hóa các điểm tốt và
những thứ có thể tốt hơn. Các thứ cần cải tiến gồm cấu trúc của Nhóm Scrum,
việc họp hành, các cơng cụ, định nghĩa “hồn thành”, cách thức giao tiếp, và các
quy trình phát triển để chuyển đổi các Product Backlog thành các công việc được
đánh dấu là “hồn thành”. Kết thúc buổi Sprint Retrospective, Nhóm Scrum phải
xác định được các hành động cải tiến lượng hóa được để tiến hành trong Sprint
sau. Những thay đổi này sẽ trở thành sự thích nghi cho q trình khảo sát thực
nghiệm (empirical inspection) vừa hoàn tất.

Họp Scrum hằng ngày - Daily Scrum

Đội sản xuất sẽ Họp Scrum hằng ngày (Daily Scrum) trong vòng mười lăm phút
mỗi ngày để triển khai kĩ thuật thanh tra-thích nghi cho các cơng việc hằng ngày
của mình. Daily Scrum diễn ra ngay tại nơi nhóm làm việc hằng ngày với ba câu
hỏi cho các thành viên của nhóm:

1. Bạn đã làm được những gì kể từ buổi họp trước đến giờ;
2. Bạn sẽ làm gì trước buổi họp tới đây; và
3. Bạn đã gặp phải những trở ngại nào trong khi làm việc.

Daily Scrum sẽ cải thiện sự giao tiếp, giảm thiểu thời gian họp hành khác không
cần thiết, nhận biết và loại bỏ các rắc rối trong q trình phát tiển, nhấn mạnh và
khuyến khích các quyết định nhanh chóng, và tăng mức độ hiểu biết của tất cả
mọi người về dự án.

ScrumMaster tạo điều kiện để Đội sản xuất họp Daily Scrum thật hiệu quả. Còn
Đội sản xuất phải chịu trách nhiệm về Daily Scrum. ScrumMaster phải dạy cho
Đội sản xuất giữ được sự nhanh gọn của Daily Scrum bằng các quy tắc cần thiết

16 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

và đảm bảo mọi người nói vắn tắt đủ hiểu. ScrumMaster cũng phải áp dụng các
quy tắc cho “các chú gà” để đảm bảo chúng không kêu quang quác khiến cuộc
họp bị gián đoạn (Quy tắc: “gà không được kêu”).

Daily Scrum không phải là buổi họp báo cáo trạng thái cơng việc. Nó khơng dành

cho ai khác ngồi những người chịu trách nhiệm việc biến đổi Product Backlog

thành ra các gói phần mềm dùng được

(tức Đội sản xuất). Đội sản xuất cần phải Mẹo

bám sát Mục tiêu Sprint (Sprint Goal) và Các Nhóm Scrum thường bỏ ra 10% thời gian
Product Backlog để làm việc. Daily mỗi Sprint cho việc làm mịn Product Backlog
Scrum là phần thanh tra (inspection) trên để đạt tiêu chuẩn của một Product Backlog
tiến trình tiến tới Mục tiêu Sprint. Mục tốt. Khi làm mịn, hạng mục Product Backlog

đích của nó là để tận dụng các khả năng thuộc phần trên (có độ ưu tiên cao nhất, có
mà Đội sản xuất có thể đạt được mục giá trị nhất) được tách ra để có thể thực hiện
tiêu. Đây là chìa khóa của buổi họp thanh trong phạm vi một Sprint. Chúng có thể được
tra-thích nghi (tức Daily Scrum) trong phân tích kĩ càng hơn trong quá trình làm mịn
đó. Cho tới khi họp Kế hoạch Sprint, các hạng

quy trình thực nghiệm (empirical mục ưu tiên này đã đủ rõ ràng và dễ dàng
process) Scrum. được lựa chọn để đưa vào phát triển.

Đồ nghề Scrum (Scrum Mẹo
Artifacts)
Trong một số tổ chức, có nhiều phần việc
Các đồ nghề (artifacts) được dùng trong được thêm vào backlog hơn là các phần việc
Scrum gồm có Product Backlog, đã hồn thành. Điều này có thể dẫn đến
Release Burndown, Sprint Backlog và đường biểu diễn xu hướng trong Burndown đi
Sprint Burndown. lên thay vì đi xuống như thường thấy. Để giải
quyết trường hợp này và để đảm bảo tính
Product Backlog và Release minh bạch, sàn (floor) mới được thiết lập khi
Burndown thêm hoặc bớt công việc phải làm. Sàn mới
Yêu cầu của khách hàng được liệt kê này cần phải thêm vào hoặc bớt đi các thay
trong Product Backlog. Product Owner đổi quan trọng, và cần được tài liệu hóa cẩn
chịu trách nhiệm tạo lập, quản lý và ưu thận để tất cả mọi người nắm được.
tiên hóa (prioritization) cho các hạng

17 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

mục trong Product Backlog. Product Backlog không bao giờ là đầy đủ. Theo đó,

các lát cắt ban đầu của nó được đem đi phát triển thường là phần rõ ràng hơn cả.

Product Backlog sẽ tiến hóa trong q

trình phát triển sản phẩm và theo kịp sự Mẹo

thay đổi của tình hình thực tiễn.

Product Backlog là một thực thể động, Kiểm thử chấp nhận (Acceptance Test)

nó biến đổi liên tục để thể hiện cho thường là một trong số các thuộc tính quan
được điều gì thực sự là cần thiết, phù trọng được mô tả trong mỗi hạng mục
hợp, có tính cạnh tranh và hữu ích. Product Backlog. Chúng cho biết chi tiết về
Product Backlog còn tồn tại chừng nào việc sản phẩm phải đạt được tiêu chí gì để
sản phẩm tồn tại. người dùng chấp nhận khi chức năng (hay
sản phẩm) được hoàn tất.

Product Backlog chứa tất cả những thứ
cần thiết phải phát triển và tạo thành một sản phẩm thành cơng. Nó chứa danh
sách tất cả các tính năng, chức năng, cơng nghệ, các cải tiến, sửa lỗi cần phải
thực hiện để làm thành sản phẩm trong lần phát hành (release) tới đây. Các hạng
mục (Product Backlog item) trong Product Backlog thường được viết ra với các
thuộc tính như: mơ tả, độ ưu tiên và ước lượng. Độ ưu tiên được xác định dựa
trên các yếu tố như rủi ro, giá trị, và mức độ cần thiết của yêu cầu. Ta có thể dùng
nhiều kĩ thuật để đánh giá các thuộc tính này.

Product Backlog được sắp xếp dựa trên mức ưu tiên (priority). Phần ưu tiên cao
nhất trong Product Backlog sẽ trực tiếp được đưa vào quá trình phát triển. Càng
có độ ưu tiên cao hơn thì mức độ quan tâm tới phần Product Backlog đó càng
phải khẩn trương và kĩ càng hơn; cũng như độ nhất trí về giá trị của phần đó sẽ
cao hơn. Các hạng mục có độ ưu tiên cao thì rõ ràng và được mô tả chi tiết hơn so
với các mục có độ ưu tiên thấp. Khi đó, việc ước lượng đối với các hạng mục này
sẽ chính xác hơn. Đối với các hạng mục ưu tiên thấp, thì thơng tin sẽ ít hơn, cho
tới khi bạn bỏ cơng tìm hiểu kĩ hơn về chúng.

Khi sản phẩm được đem ra sử dụng, giá trị của nó sẽ tăng lên, và khi thị trường
có những phản hồi đối với sản phẩm, thì các hạng mục trong Product Backlog sẽ
tăng dần. Yêu cầu thì khơng ngừng thay đổi. Product Backlog là một tài liệu sống
do nó liên tục được cập nhật để phản ánh các thay đổi trong yêu cầu nghiệp vụ,
điều kiện thị trường, công nghệ hay thay đổi nhân sự trong dự án. Để giảm thiểu

việc phải làm lại các thứ đã mất cơng tạo ra, chỉ các mục có độ ưu tiên cao nhất

18 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

được đem ra phân tích kĩ. Cịn lại, các hạng mục mà ta dự định sẽ triển khai trong
các Sprint sau này sẽ được phân tách kĩ sao cho mỗi hạng mục có thể được hồn
thành trong phạm vi một Sprint.

Nhóm Scrum thường chỉ làm việc trên cùng một sản phẩm. Mỗi Product Backlog
được dùng để mô tả công việc sắp tới cho sản phẩm đó. Căn cứ trên tính chất của
các hạng mục trong Product Backlog mà ta có thể nhóm chúng lại với nhau. Việc
phân loại này có thể căn cứ theo tập các tính năng, cơng nghệ, kiến trúc. Đó cũng
là cách mà các Nhóm Scrum dùng để tổ chức cơng việc của mình.

Biểu đồ Release Burndown ghi lại tổng số nỗ lực (effort) ước tính cho các hạng
mục còn lại trong Product Backlog qua thời gian. Các nỗ lực được ước lượng có
thể được đo bằng nhiều loại đơn vị khác nhau tùy quyết định từng Nhóm Scrum
hoặc tổ chức. Đơn vị về thời gian thường chỉ dùng cho các Sprint.

Ước tính (estimate) cho các hạng mục trong Product Backlog được tính tốn lần

đầu trong Release Planning (Họp kế hoạch Phát hành) khi Product Backlog được

tạo ra. Sau đó, các mục này thường xuyên được đánh giá lại (thao tác này gọi là

Product Backlog grooming – làm mịn Product Backlog). Do đó, các ước lượng này

sẽ thường xuyên được cập nhật trong dự án. Đội sản xuất chịu trách nhiệm cho

việc thực hiện ước tính cho tất cả các hạng mục trong quá trình làm việc. Product

Owner chỉ có thể gây ảnh hưởng lên nhóm bằng cách giúp họ hiểu thêm và lựa

chọn các phương án tối ưu phù hợp với thực tiễn, còn quyết định cuối cùng về

các giá trị ước lượng hoàn toàn phụ

thuộc vào Đội sản xuất. Product Owner Mẹo

cần phải đảm bảo cho chi tiết về việc cập

nhật Product Backlog hay Release Đường vẽ xu hướng có thể khơng đáng tin

Backlog Burndown luôn luôn được công cậy lắm trong một hai Sprint đầu tiên, trừ khi
khai tại mọi thời điểm. Một đồ thị biểu Nhóm đã làm việc với nhau từ trước, hiểu
diễn xu hướng của dự án dựa trên sự biết tốt về sản phẩm và tường tận công nghệ
thay đổi về lượng công việc còn lại phải được sử dụng.

làm có thể được vẽ ra để mọi người tiện

theo dõi tiến độ của dự án.

Sprint Backlog và Sprint Burndown

19 Scrum Guide – Ken Schwaber và Jeff Sutherland
Bản Việt hóa này đang ở trạng thái beta

Sprint Backlog chứa danh sách các công việc mà Đội sản xuất cần thực hiện để
chuyển đổi các hạng mục Product Backlog thành phần tăng trưởng được xác

nhận là “hoàn thành”. Rất nhiều các tác vụ đó được thiết lập ngay trong buổi Họp
kế hoạch Sprint. Sprint Backlog chính là tất cả các công việc mà Đội sản xuất phải
làm việc trong suốt Sprint đó để đạt đến Mục tiêu Sprint. Công việc được liệt kê
trong Sprint Backlog phải được tách nhỏ để tiện theo dõi sự thay đổi trong q
trình làm việc (ví dụ để báo cáo và theo dõi trong Daily Scrum). Công việc sau khi
phân tách nên có ước lượng khơng nên dài q một ngày.

Đội sản xuất chỉnh sửa Sprint Backlog trong suốt Sprint. Khi một thành viên Đội
sản xuất lựa chọn nhiệm vụ để thực hiện, thành viên đó có thể nhận thấy mình
phải làm nhiều tác vụ khác, hoặc thời gian cần thiết có thể nhiều hơn dự tính ban
đầu. Khi có tác vụ mới, nhóm thêm nó vào trong Product Backlog. Khi có ai đó
chọn một việc để làm, thì trạng thái của nó (đang làm hay đã hồn tất) và thời
gian ước tính cịn lại (estimated remaining work) phải được cập nhật liên tục. Khi
có tác vụ nào đó là khơng cần thiết nữa, Nhóm có thể loại bỏ nó khỏi danh sách
cơng việc. Chỉ có Đội sản xuất mới có quyền chỉnh sửa Sprint Backlog trong khi
Sprint diễn ra. Chỉ có họ mới đủ quyền để cập nhật các ước lượng trong đó.
Sprint Backlog cần phải được cơng khai. Nó là bản kế hoạch thời gian thực về
cơng việc mà nhóm làm việc trong Sprint, và nó chỉ thuộc về Đội sản xuất.
Sprint Burndown là biểu đồ thể hiện lượng công việc còn lại trong một Sprint
qua thời gian. Để tạo biểu đồ này, ta tính tổng các ước lượng cho mỗi công việc
hằng ngày trong Sprint. Các số liệu về ước lượng đó được lấy từ Sprint Backlog.
Hằng ngày ta tính lại các số liệu và cập nhật lại đồ thị để thấy được lượng cơng
việc cịn lại qua thời gian. Dựa vào đó, ta có thể quản lý tiến độ công việc trong
Sprint. Trong Scrum, thời gian đã bỏ ra khi làm việc khơng được quan tâm.Thay
vì đó, Scrum chỉ để ý tới lượng cơng việc cịn lại và bao nhiêu ngày còn lại để làm
việc.
Một trong những quy tắc để đảm phải mục đích của mỗi Sprint là việc tuân thủ
Định nghĩa về “Hoàn thành”. Tất cả các mục được đánh dấu là “hoàn thành” đều
phải phù hợp tiêu chuẩn được định nghĩa từ trước.

Hoàn thành (hay Xong - Done)

Scrum yêu cầu các nhóm phải làm ra các phần tăng trưởng (increment) hoàn
chỉnh của sản phẩm ở cuối mỗi Sprint. Đây là gói có thể chuyển giao được
(shippable) cho Chủ sản phẩm (Product Owner). Muốn vậy, mỗi phần đó phải
thực sự là một phần của sản phẩm cuối cùng. Chúng phải thỏa mãn định nghĩa

20 Scrum Guide – Ken Schwaber và Jeff Sutherland

Bản Việt hóa này đang ở trạng thái beta