Tổng quan về Scrum (Phần 2)

Ở phần trước, mình đã giới thiệu với các bạn những khái niệm cơ bản về tính chất cũng như các vai trò trong một Scrum team (nhóm scrum). Trong phần này, chúng ta sẽ tiếp tục tìm hiểu về Scrum events ( các sự kiện scrum), Scrum artifacts ( các tạo tác trong scrum) và Definition of "done" (định nghĩa "hoàn thành").

Các sự kiện được quy định trong scrum tạo ra sự đều đặn, giảm tối đa các cuộc họp không được định nghĩa trong scrum. Tất cả sự kiện đều quy định khung thời gian rõ ràng, tức là đã quy định khoảng thời gian tối đa cho mỗi sự kiện. Khi một sprint bắt đầu, khoảng thời gian của nó đã được cố định sẵn, không thể rút ngắn lại hoặc kéo dài hơn. Các sự kiện còn lại có thể kết thúc bất cứ khi nào đạt được mục đích của sự kiện, đảm bảo sử dụng một lượng thời gian thích hợp mà không lãng phí. Một sprint bao gồm tất cả các sự kiện khác. Mỗi sự kiện trong scrum là cơ hội chính thức để thực hiện việc kiểm tra và điều chỉnh lại. Các sự kiện này được thiết kế một cách đặc biệt nhằm đảm bảo sự thanh tra và tính minh bạch. Nếu không diễn ra các sự kiện này, không chỉ tính minh bạch sẽ bị giảm mà còn mất đi cơ hội để thanh kiểm tra và điều chỉnh.

5.1 Sprint

Trái tim của Scrum là sprint. Mỗi Sprint có một khung thời gian nhất định kéo dài 1 tháng hoặc ít hơn ( thường từ 2 đến 4 tuần) mà trong đó một phần tăng trưởng của sản phầm đã hoàn thành, có thể sử dụng và bàn giao được. Trong suốt quá trình phát triển, khung thời gian của mỗi sprint là nhất quán. Một sprint mới bắt đầu ngay lập tức khi một sprint kết thúc.

Một sprint chứa các cuộc họp: Lên kế hoạch cho sprint (Sprint planning meeting), họp hàng ngày ( Daily meeting), họp đánh giá sprint ( Sprint review meeting) và cuộc họp cải tiến (Sprint retropective meeting).

Trong suốt một sprint

• Không được thực hiện bất kỳ thay đổi gì làm ảnh hưởng xấu đến mục tiêu của sprint
• Mục tiêu về chất lượng không được giảm
• Phạm vi có thể được làm rõ ràng và thương lượng lại giữa Product owner và Development team (Nhóm phát triển dự án) Mỗi Sprint có thể được coi như là một dự án nhỏ kéo dài không quá một tháng. Giống như các dự án, các sprint đều cần hoàn thành một cái gì đó. Mỗi sprint cần có mục tiêu rõ ràng là xây dựng cái gì, một bản thiết kế và kế hoạch linh hoạt sẽ xây dựng nó, công việc và kết quả sản phẩm.

Một sprint được giới hạn không quá 1 tháng. Khi một sprint quá dài, định nghĩa về xây dựng một cái gì đó có thể thay đổi, khi đó sự phức tạp và tính rủi ro có thể sẽ tăng lên. Sprint cho phép dự đoán trước được bằng việc đảm bảo sự thanh kiểm tra và điều chỉnh, thích ứng trong quá trình tiến tới mục tiếu của sprint ít nhất là trong mỗi tháng. Sprint cũng giới hạn chi phí rủi ro trong một tháng.

Hủy một sprint

Một sprint được hủy trước khi hết thúc khung thời gian của sprint. Chỉ Product Owner mới có quyền hủy một sprint, mặc dù Product Owner làm vậy dưới sự ảnh hưởng của các bên liên quan, Scrum team (Nhóm phát triển) hoặc Scrum master ( Chuyên gia scrum).

Sprint bị hủy nếu Mục tiêu của Sprint trở nên lỗi thời. Điều này có thể xảy ra khi công ty thay đổi hướng kinh doanh hoặc do điều kiện thị trường hoặc công nghệ thay đổi. Tuy nhiên, do một Sprint có khoảng thời gian ngắn nên việc hủy bỏ hiếm khi có ý nghĩa.

Khi Sprint bị hủy, các mục đã hoàn thành của Product Backlog sẽ được xem xét. Nếu một phần của công việc có thể bàn giao được, Product Owner thường sẽ chấp nhận nó. Tất cả các hạng mục của Product Backlog mà chưa hoàn thành sẽ được ước lượng lại và được đưa trở lại Product Backlog.

Hủy bỏ Sprint gây lãng phí tài nguyên, vì mọi người tập hợp lại vào một buổi họp lập kế hoạch Sprint khác để bắt đầu một Sprint mới. Do đó, việc hủy bỏ Sprint thường gây ảnh hưởng đến Scrum team và rất ít khi sảy ra.

5.2 Sprint Planning meeting (Họp lập kế hoạch cho sprint)

Công việc được thực hiện trong Sprint sẽ được lên kế hoạch trong buổi họp Sprint Planning. Kế hoạch này được tạo ra bởi sự tham gia của toàn bộ thành viên trong Scrum team.

Lập kế hoạch Sprint được quy định khung thời gian tối đa là tám giờ cho một Sprint một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn. Scrum Master đảm bảo rằng sự kiện diễn ra và những người tham dự hiểu mục đích của nó. Scrum Master sẽ điều phối, hướng dẫn cho Scrum Team đảm bảo buổi họp trong khoảng thời gian quy định.

Sprint Planning trả lời những câu hỏi sau đây: Những gì có thể được bàn giao trong Sprint tới? Cần làm những gì để đạt được mục tiêu bàn giao?

Chủ đề Một: Cần hoàn thành những gì trong Sprint này?

Scrum team hoạt động để dự báo chức năng sẽ được phát triển trong Sprint. Product owner thảo luận về mục tiêu mà Sprint sẽ đạt được và các hạng mục Product Backlog, nếu được hoàn thành trong Sprint, sẽ đạt được Mục tiêu Sprint. Toàn bộ Scrum team cùng làm việc để tìm hiểu công việc của Sprint.

Đầu vào cho cuộc họp này là Product Backlog, sản phẩm mới nhất đã bàn giao, dự kiến khả năng của Development team (Nhóm phát triển) trong Sprint và hiệu suất trước đây của Development team. Số lượng các mục được chọn từ Product Backlog cho Sprint do Development team quyết định. Chỉ Development team mới có thể đánh giá những gì mà họ có thể đạt được trong Sprint sắp tới.

Trong suốt quá trình lập kế hoạch cho Sprint, Nhóm Scrum cũng thực hiện một mục tiêu Sprint (Sprint Goal). Mục tiêu Sprint là mục tiêu sẽ được đáp ứng trong Sprint thông qua việc triển khai Product Backlog và chính mục tiêu này cũng hướng dẫn cho Nhóm phát triển không đi chệch hướng.

Chủ đề Hai: Làm thế nào để công việc được chọn có thể hoàn thành?

Sau khi đặt ra mục tiêu Sprint và chọn các mục trong Product Backlog cho Sprint, Nhóm phát triển quyết định cách xây dựng chức năng này thành sản phẩm "Đã hoàn thành" trong Sprint. Các hạng mục Product Backlog được chọn cho Sprint này cộng với kế hoạch bàn giao được gọi là Sprint Backlog.

Nhóm phát triển thường bắt đầu bằng cách thiết kế hệ thống và nhũng công việc cần thiết để đưa Product Backlog thành sản phẩm hoạt động được. Công việc có thể có mức độ khó dễ hoặc khối lượng công việc khác nhau. Tuy nhiên, trong quá trình lập kế hoạch nhóm phát triển lên kế hoạch đủ công việc cho sprint để dự đoán những gì họ tin rằng nó có thể làm trong Sprint sắp tới. Công việc lập kế hoạch cho những ngày đầu tiên của Sprint bởi Nhóm phát triển được tách rời vào cuối cuộc họp này, thường là các đơn vị trong một ngày hoặc ít hơn. Nhóm phát triển tự tổ chức thực hiện công việc trong Sprint Backlog, cả trong khi lập kế hoạch Sprint và khi cần thiết trong suốt Sprint.

Product owner có thể giúp làm rõ các hạng mục Product Backlog đã chọn. Nếu Nhóm phát triển xác định nó có quá nhiều hoặc quá ít công việc, Nhóm có thể thương lượng lại các hạng mục Product Backlog đã chọn với Product owner. Nhóm phát triển cũng có thể mời những người khác tham dự để tư vấn về kỹ thuật hoặc lĩnh vực dịch vụ.

Đến cuối Kế hoạch Sprint, Nhóm phát triển sẽ có thể giải thích cho Product owner và Scrum Master cách mà nhóm dự định làm việc như một nhóm tự tổ chức để hoàn thành Mục tiêu Sprint.

Mục tiêu của Sprint (Sprint Goal)

Mục tiêu Sprint là một bộ mục tiêu cho Sprint có thể thực hiện được thông qua việc triển khai Product Backlog. Mục tiêu Sprint cung cấp cho Nhóm phát triển tính linh hoạt liên quan đến chức năng được triển khai trong Sprint. Các mục được chọn trong Product Backlog cung cấp một chức năng rõ ràng, có thể là Mục tiêu Sprint. Mục tiêu Sprint có thể là bất kỳ sự kết hợp khiến cho Nhóm phát triển làm việc cùng nhau thay vì làm việc riêng biệt.

Khi Nhóm phát triển làm việc, Nhóm luôn ghi nhớ Mục tiêu Sprint. Để đáp ứng Mục tiêu Sprint, nhóm thực hiện chức năng và công nghệ. Nếu công việc khác với những gì Nhóm phát triển mong muốn, họ sẽ nói chuyện với Product owner để thương lượng về phạm vi của Sprint Backlog trong Sprint.

5.3 Daily Scrum meeting (cuộc họp hàng ngày)

The Daily Scrum là sự kiện có khung thời gian 15 phút cho Nhóm phát triển. Daily Scrum được tổ chức mỗi ngày của Sprint. Tại đó, Nhóm phát triển dự định làm việc trong 24 giờ tới. Điều này tối ưu hóa sự tương tác và hiệu xuất làm việc của nhóm bằng cách thanh kiểm tra công việc từ hôm trước và kế hoạch công việc sắp tới của Sprint. Daily Scrum được tổ chức cùng một thời gian và địa điểm mỗi ngày để giảm sự phức tạp.

Nhóm phát triển sử dụng Daily Scrum để kiểm tra tiến trình hướng tới Mục tiêu Sprint và để kiểm tra xem tiến trình có xu hướng hướng tới việc hoàn thành công việc trong Backlog Sprint như thế nào. Daily Scrum tối ưu hóa xác suất mà Nhóm phát triển sẽ đáp ứng Mục tiêu Sprint. Mỗi ngày, Nhóm phát triển nên hiểu cách dự định hợp tác với nhau như một nhóm tự tổ chức để hoàn thành Mục tiêu Sprint và tạo ra Sự tăng trưởng sản phẩm được mong đợi vào cuối Sprint.

Cấu trúc của cuộc họp được thiết lập bởi Nhóm phát triển và có thể được tiến hành theo nhiều cách khác nhau nếu nó tập trung vào tiến trình hướng tới Mục tiêu Sprint. Một số nhóm phát triển sẽ sử dụng câu hỏi, một số sẽ có nhiều thảo luận hơn. Dưới đây là ví dụ về những gì có thể được sử dụng:

Hôm qua tôi làm gì để giúp Nhóm phát triển đạt được Mục tiêu Sprint? Hôm nay tôi sẽ làm gì để giúp Nhóm phát triển đạt được Mục tiêu Sprint? Tôi có thấy bất kỳ trở ngại, khó khăn nào không? Nhóm phát triển hoặc các thành viên nhóm thường gặp ngay sau Daily Scrum để thảo luận chi tiết, hoặc để thích ứng hoặc thay thế.

Scrum Master đảm bảo rằng Nhóm phát triển có cuộc họp, nhưng Nhóm phát triển chịu trách nhiệm tiến hành họp Daily Scrum. Scrum Master hướng dẫn Nhóm phát triển duy trì họp hàng ngày trong khoảng thời gian 15 phút.

Daily Scrum là một cuộc họp nội bộ cho Nhóm phát triển. Nếu những người khác có mặt, Scrum Master cần đảm bảo rằng họ không làm ảnh hưởng đến cuộc họp.

Daily scrum giúp cải thiện thông tin liên lạc, loại bỏ các cuộc họp khác, xác định các trở ngại đến sự phát triển để loại bỏ, đánh dấu và thúc đẩy việc ra quyết định nhanh chóng và nâng cao trình độ kiến thức của Nhóm phát triển. Đây là một cuộc họp thanh kiểm tra và điều chỉnh chính.

5.4 Review meeting (Họp Đánh giá Sprint)

Sprint Review meeting được tổ chức vào cuối Sprint để kiểm tra sự Tăng trưởng và điều chỉnh Product Backlog nếu cần. Trong cuộc họp đánh giá Sprint, Nhóm Scrum và các bên liên quan trao đổi về những gì đã được thực hiện trong Sprint. Dựa trên đó và bất kỳ thay đổi nào đối với Product Backlog trong Sprint, những người tham dự thảo luận xem những gì tiếp theo có thể được thực hiện để tối ưu hóa giá trị. Đây là một cuộc họp không chính thức, không phải là một cuộc họp về tình trạng, phần trình bày về sản phẩm Tăng trưởng nhằm mục đích tiếp nhận sự phản hồi từ khách hàng và thúc đẩy sự cộng tác.

Đây là cuộc họp kéo dài bốn giờ cho Sprints một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn. Scrum Master đảm bảo rằng sự kiện diễn ra và những người tham dự hiểu mục đích của nó. Scrum Master sẽ hướng dẫn mọi người liên quan để giữ cho cuộc họp diễn ra trong đúng khung thời gian.

Đánh giá Sprint bao gồm các yếu tố sau:

• Những người tham dự bao gồm Nhóm Scrum (Product owner, scum master, development team) và các bên liên quan chính được Product owner mời;
• Scum master giải thích các mục nào trong Product Backlog đã được "hoàn thành" và những gì chưa được "hoàn thành";
• Nhóm phát triển thảo luận về những gì diễn ra tốt đẹp trong Sprint, những vấn đề mà gặp phải và cách giải quyết các vấn đề đó;
• Nhóm phát triển tập trung trình bày những công việc đã "hoàn thành" và trả lời các câu hỏi về phần tăng trưởng trong sprint này;
• Product owner thảo luận về Product Backlog, đặt kế hoạch về mục tiêu và ngày bàn giao có thể dựa trên tiến độ hện tại (nếu cần);
• Toàn bộ nhóm bàn bạc về những việc cần làm tiếp theo, cuộc họp đánh giá cung cấp đầu vào có giá trị cho Kế hoạch của Sprint tiếp theo;
• Xem lại thị trường hoặc khả năng sử dụng sản phẩm có thể đã thay đổi như thế nào? Điều gì có giá trị nhất để làm tiếp theo; và,
• Xem lại thời gian, ngân sách, năng lực và thị trường cho các bản phát hành dự kiến tiếp theo về chức năng hoặc khả năng của sản phẩm. Kết quả của buổi họp Đánh giá Sprint là Product Backlog đã được sửa đổi - xác định các hạng mục trong Product backlog có thể xảy ra cho Sprint tiếp theo. Product Backlog cũng có thể được điều chỉnh tổng thể để đáp ứng những cơ hội mới.

5.5 Sprint Retrospective meeting (Họp cải tiến)

Sprint retrospective là một cơ hội cho Nhóm Scrum tự kiểm tra chính mình, những gì đã làm tốt và những gì làm chưa tốt trong sprint vừa rồi và đưa ra kế hoạch cải tiến trong Sprint tiếp theo.

Cuộc họp này diễn ra sau khi đánh giá Sprint (Review meeting) và trước buổi lên Kế hoạch cho Sprint tiếp theo. Đây là cuộc họp kéo dài ba giờ cho Sprints một tháng. Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn. Scrum Master đảm bảo rằng sự kiện diễn ra và những người tham dự hiểu mục đích của nó.

Scrum Master đảm bảo rằng cuộc họp diễn ra tích cực và hiệu quả. Scrum master hướng dẫn nhóm để giữ cho cuộc họp diễn ra đúng trong khung thời gian. Scrum Master tham gia với tư cách là thành viên nhóm trong cuộc họp chịu trách nhiệm về quy trình của Scrum.

Mục đích của Sprint Retrospective là:

• Kiểm tra xem nhóm đã làm việc như thế nào trong Sprint vừa rồi (con người, mối quan hệ, quy trình và công cụ);
• Xác định và sắp xếp xem nhóm đã làm tốt những gì và những điều gì có khả năng đã được cải thiện;
• Tạo bản kế hoạch để thực hiện các cải tiến cách làm việc của nhóm để đạt kết quả tốt trong các sprint sau.

Scrum Master khuyến khích Nhóm Scrum cải tiến, trong khuôn khổ quy trình Scrum, và thực hiện phát triển để làm cho nó hiệu quả hơn và thú vị hơn cho Sprint tiếp theo. Trong mỗi lần xem lại Sprint, Nhóm Scrum có kế hoạch để tăng chất lượng sản phẩm bằng cách cải thiện quy trình làm việc hoặc điều chỉnh định nghĩa "Hoàn Thành", nếu thích hợp và không xung đột với tiêu chuẩn của sản phẩm hoặc tổ chức.

Vào cuối Bản tóm tắt Sprint, Nhóm Scrum cần phải xác định những cải tiến mà nó sẽ thực hiện trong Sprint tiếp theo. Việc thực hiện những cải tiến này trong Sprint tiếp theo là sự điều chỉnh, thích ứng (adaptation) với sự kiểm tra (inspection) của Nhóm Scrum. Mặc dù các cải tiến có thể được thực hiện bất kỳ lúc nào, Bản tóm tắt Sprint cung cấp một cơ hội chính thức để tập trung vào kiểm tra và thích ứng.

Các tạo tác của Scrum đại diện cho công việc hoặc giá trị để cung cấp sự minh bạch và cơ hội để kiểm tra và điều chỉnh. Các tạo phẩm được định nghĩa bởi Scrum được thiết kế đặc biệt để tối đa hóa tính minh bạch của thông tin quan trọng để mọi người đều có cùng hiểu biết về sản phẩm.

6.1 Product Backlog

Product Backlog là một danh sách theo thứ tự ưu tiên cần thiết trong sản phẩm. Đây là nguồn yêu cầu duy nhất cho bất kỳ thay đổi nào được thực hiện cho sản phẩm. Product owner chịu trách nhiệm về Product Backlog, bao gồm nội dung, tính khả dụng và thứ tự ưu tiên.

Một Product Backlog không bao giờ hoàn thành. Bản đầu tiên đưa ra các yêu cầu ban đầu. Product Backlog phát triển như sản phẩm và môi trường mà nó sẽ được sử dụng để phát triển. Product Backlog là động; nó liên tục thay đổi để xác định những gì sản phẩm cần phải phù hợp, cạnh tranh và hữu ích. Nếu một sản phẩm tồn tại, Product Backlog của nó cũng tồn tại.

Product Backlog liệt kê tất cả các tính năng, chức năng, yêu cầu, cải tiến và các bản sửa lỗi cho sản phẩm trong các bản phát hành trong tương lai. Các mục trongn Product Backlog có các thuộc tính như mô tả, thứ tự, ước tính và giá trị. Các mục Product Backlog thường bao gồm các mô tả kiểm thử sẽ chứng minh tính hoàn chỉnh của nó khi "Hoàn thành".

Là một sản phẩm được sử dụng và tăng giá trị, và thị trường cung cấp phản hồi, Product Backlog trở thành một danh sách lớn hơn và đầy đủ hơn. Yêu cầu không bao giờ ngừng thay đổi, do đó, Product Backlog là một tạo phẩm sống động. Những thay đổi về yêu cầu kinh doanh, điều kiện thị trường hoặc công nghệ có thể gây ra những thay đổi trong Product Backlog.

Nhiều Nhóm Scrum thường làm việc cùng nhau trên cùng một sản phẩm. Một Product Backlog được sử dụng để mô tả công việc sắp tới trên sản phẩm. Một thuộc tính Backlog sản phẩm nhóm các mục sau đó có thể được sử dụng.

Điều chỉnh Product Backlog là hành động thêm chi tiết, ước lượng và đánh giá thứ tự ưu tiên trong các mục của Product Backlog. Đây là một quá trình liên tục trong đó Product owner và Nhóm phát triển thảo luận trên các chi tiết của các mục Product Backlog. Trong quá trình sàng lọc Product Backlog, các mục được xem xét và sửa đổi. Nhóm Scrum quyết định cách thức và thời điểm sàng lọc được thực hiện. Sàng lọc thường tiêu thụ không quá 10% công suất của Nhóm phát triển. Tuy nhiên, các mục Product Backlog có thể được cập nhật bất kỳ lúc nào bởi Product owner hoặc theo quyết định của Product owner.

Các mục trong Product Backlog có thứ tự ưu tiên cao hơn thường rõ ràng hơn và chi tiết hơn so với các mục có độ ưu tiên thấp. Các ước tính chính xác hơn được thực hiện dựa trên sự rõ ràng và chi tiết hơn; thứ tự thấp hơn, chi tiết càng ít. Các mục trong Product Backlog được Nhóm phát triển chọn cho Sprint sắp tới sẽ được tinh chỉnh sao cho bất kỳ một mục nào có thể được "hoàn thành" hợp lý trong khung thời gian của Sprint. Các mục trong Product Backlog có thể được "Hoàn thành" bởi Nhóm phát triển trong một Sprint được coi là "Sẵn sàng" để lựa chọn trong Lập kế hoạch Sprint. Các mục Product Backlog thường có được mức độ minh bạch này thông qua các hoạt động tinh chỉnh được mô tả ở trên.

Nhóm phát triển chịu trách nhiệm cho tất cả các ước tính. Product owner có thể gây ảnh hưởng đến Nhóm phát triển bằng cách giúp họ hiểu và lựa chọn, nhưngnhóm phát triển cần đưa ra ước tính cuối cùng.

Giám sát tiến độ hướng tới mục tiêu Tại bất kỳ thời điểm nào, tổng số công việc còn lại để đạt được mục tiêu có thể tổng kết được. Product owner theo dõi tổng số công việc còn lại ít nhất mỗi buổi đánh giá Sprint (Review meeting). Product owner so sánh số lượng công việc còn lại tại buổi Đánh giá Sprint trước đó để đánh giá tiến độ hướng tới hoàn thành công việc theo thời gian và mục tiêu mong muốn. Thông tin này được thực hiện minh bạch cho tất cả các bên liên quan.

Các phương pháp dự báo khác nhau theo xu hướng đã được sử dụng để dự báo tiến độ, như biểu đồ burn-downs, burn-ups, hoặc cumulative flows. Chúng đã được chứng minh là hữu ích. Tuy nhiên, những điều này không thay thế tầm quan trọng của thực nghiệm. Trong môi trường phức tạp, không thể biết trước được điều gì sẽ sảy ra. Chỉ những gì đã xảy ra mới có thể được sử dụng cho việc đưa ra quyết định tương lai.

6.2 Sprint backlog

Sprint Backlog là tập hợp các mục Product Backlog được chọn cho Sprint, cộng với một bản kế hoạch bàn giao sản phẩm và thực hiện Mục tiêu Sprint. Sprint Backlog là dự báo của Nhóm phát triển về chức năng nào sẽ được thực hiện tiếp theo và công việc cần thiết để có thể bàn giao được chức năng đó thành một phần tăng trưởng.

Sprint Backlog hiển thị tất cả công việc mà Nhóm phát triển xác định là cần thiết để đáp ứng Mục tiêu Sprint. Để đảm bảo cải tiến liên tục, nó bao gồm ít nhất một cải tiến quy trình có mức độ ưu tiên cao đã được xác định trong cuộc họp cải tiến (Retrospective meeting) trước đó.

Sprint Backlog là kế hoạch đủ chi tiết mà tiến độ thay đổi có thể nhận thấy trong Daily Scrum. Nhóm phát triển sửa đổi Sprint Backlog trong suốt Sprint, và Sprint Backlog được cập nhật trong Sprint. Sự xuất hiện này xảy ra khi Nhóm phát triển làm việc thông qua kế hoạch và tìm hiểu thêm về công việc cần thiết để đạt được Mục tiêu Sprint.

Khi có một công việc mới bắt buộc, Nhóm phát triển thêm nó vào Sprint Backlog. Khi công việc được thực hiện hoặc hoàn thành, công việc còn lại sẽ được ước tính và cập nhật. Khi các yếu tố của kế hoạch được coi là không cần thiết, chúng sẽ bị xóa. Chỉ Nhóm phát triển mới có thể thay đổi Sprint Backlog của mình trong Sprint. Sprint Backlog là một hình ảnh thời gian thực rất rõ ràng về công việc mà Nhóm phát triển dự định thực hiện trong Sprint và nó chỉ thuộc về Nhóm phát triển.

Giám sát tiến trình Sprint Tại bất kỳ thời điểm nào trong Sprint, tổng số công việc còn lại trong Sprint Backlog có thể được tính toán. Nhóm phát triển theo dõi tổng số công việc còn lại ít nhất là cho mỗi buổi Daily Scrum (họp Scrum hàng ngày) hàng ngày để dự đoán khả năng đạt được Mục tiêu Sprint. Bằng cách theo dõi công việc còn lại trong suốt Sprint, Nhóm phát triển có thể quản lý tiến độ của nó.

6.3 Sự tăng trưởng (Increment)

Sự tăng trưởng là tổng của tất cả các hạng mục Product Backlog được hoàn thành trong Sprint và giá trị gia tăng của tất cả các Sprint trước đó. Vào cuối Sprint, Phần tăng trưởng mới phải "Hoàn thành", nghĩa là phải sử dụng được và đáp ứng định nghĩa "Hoàn thành" của Nhóm Scrum. Sự tăng trưởng là thực thể có thể kiểm tra, thực hiện công việc hỗ trợ thực nghiệm vào cuối Sprint. Mức tăng là một bước hướng tới tầm nhìn hoặc mục tiêu. Số gia tăng phải ở trong điều kiện có thể sử dụng bất kể Product owner có quyết định phát hành nó hay không.

Scrum dựa trên tính minh bạch. Các quyết định để tối ưu hóa giá trị và kiểm soát rủi ro được thực hiện dựa trên trạng thái nhận thức của các tạo tác. Trong chừng mực sự minh bạch hoàn tất, các quyết định này có cơ sở vững chắc. Trong phạm vi mà các tạo tác không minh bạch hoàn toàn, các quyết định này có thể bị thiếu sót, giá trị có thể giảm đi và rủi ro có thể tăng lên.

Scrum Master phải làm việc với Product owner, Nhóm phát triển và các bên liên quan khác để hiểu xem các tạo tác có hoàn toàn minh bạch hay không. Có những cách để đối phó với tính minh bạch không đầy đủ; Scrum master phải giúp mọi người áp dụng các cách thực hành phù hợp nhất trong trường hợp không có sự minh bạch hoàn toàn. Một Scrum Master có thể phát hiện sự không minh bạch bằng cách kiểm tra các tạo tác, lắng nghe kỹ những gì đang được nói, và phát hiện sự khác biệt giữa kết quả mong đợi và thực tế.

Công việc của Scrum Master là làm việc với Nhóm Scrum và tổ chức để tăng tính minh bạch của các tạo tác. Công việc này thường liên quan đến việc học tập, thuyết phục và thay đổi. Tính minh bạch không thể xảy ra trong một sớm một chiều mà là cả một hành trình.

Definitio of "Done" - Định nghĩa của "Hoàn thành"

Khi một mục Product Backlog hoặc Increment được mô tả là "Hoàn thành", mọi người phải hiểu "Hoàn thành" nghĩa là gì. Mặc dù điều này có thể thay đổi đáng kể cho mỗi Nhóm Scrum, các thành viên phải có sự hiểu biết chung về ý nghĩa của công việc để hoàn thành, để đảm bảo tính minh bạch. Đây là định nghĩa về "Hoàn Thành" cho Nhóm Scrum và được sử dụng để đánh giá khi công việc hoàn thành trên sự tăng trưởng của sản phẩm.

Định nghĩa tương tự sẽ hướng dẫn Nhóm phát triển biết được có bao nhiêu mục Product Backlog mà nó có thể chọn trong khi lập kế hoạch Sprint. Mục đích của mỗi Sprint là cung cấp các phần tăng trưởng của chức năng có khả năng bàn giao tuân thủ định nghĩa hiện tại của Nhóm Scrum là "Hoàn thành".

Các nhóm phát triển cung cấp sự tăng trưởng chức năng sản phẩm cho mỗi Sprint. Sự tăng trưởng này có thể sử dụng được, do đó Product owner có thể chọn ngay lập tức phát hành nó. Nếu định nghĩa "Hoàn thành" cho một phần tăng trưởng là một phần của các quy ước, tiêu chuẩn hoặc hướng dẫn của tổ chức phát triển, tất cả các Nhóm Scrum phải tuân thủ theo mức tối thiểu.

Nếu định nghĩa "Hoàn thành" không phải là quy ước của tổ chức phát triển, Nhóm phát triển của Nhóm Scrum phải xác định định nghĩa "Hoàn thành" thích hợp cho sản phẩm. Nếu có nhiều Nhóm Scrum làm việc trên hệ thống hoặc bản phát hành sản phẩm, Nhóm phát triển trên tất cả các Nhóm Scrum phải xác định được định nghĩa "Hoàn thành" một cách thống nhất.

Mỗi phần tăng trưởng được thêm vào tất cả các lần tăng trưởng trước và được kiểm tra kỹ lưỡng, đảm bảo rằng tất cả các lần tăng trưởng đều hoạt động cùng nhau.

Khi các nhóm Scrum càng trưởng thành, dự kiến định nghĩa của họ về "Hoàn thành" sẽ mở rộng để bao gồm các tiêu chí nghiêm ngặt hơn cho chất lượng cao hơn. Bất kỳ một sản phẩm hoặc hệ thống nào cũng cần phải có định nghĩa "Hoàn thành" là tiêu chuẩn cho bất kỳ công việc nào được thực hiện trên đó.

Trên đây, mình đã giới thiệu xong phần 2 cũng là phần cuối cùng tổng quan về Scrum. Hi vọng rằng qua 2 bài viết, các bạn có cái nhìn tổng thể về scrum và có thể vận dụng vào dự án của mình.