Sprint Backlog Là Gì | Câu Hỏi Thường Gặp

Sự khác biệt giữa Product Backlog và Sprint Backlog

Product Backlog là một danh sách ưu tiên các yêu cầu (requirements), chức năng (features), sửa lỗi (bug fixes) và cải tiến (improvements) của sản phẩm cần phát triển. Đây là một phần quan trọng trong Scrum và Agile development, giúp đảm bảo rằng sản phẩm được phát triển đáp ứng nhu cầu của khách hàng. Product Backlog được lập bởi Product Owner, với sự hỗ trợ từ các thành viên khác trong Scrum Team.

Product Backlog và Sprint Backlog đều là các danh sách quan trọng trong quá trình phát triển phần mềm Scrum, tuy nhiên chúng có những điểm khác nhau về tính chất, quy trình, và mục đích sử dụng như sau:

Xem thêm: Agile là gì? Scrum là gì?

Tầm quan trọng của Sprint Backlog trong Phát triển Agile

Sprint backlog phục vụ một số mục đích quan trọng trong quá trình phát triển Agile:

1. Hướng dẫn Nhóm phát triển : Sprint backlog cung cấp một kế hoạch rõ ràng cho nhóm, phác thảo các nhiệm vụ và câu chuyện của người dùng mà họ cần tập trung vào trong quá trình chạy nước rút. Nó hoạt động như một điểm tham chiếu, đảm bảo rằng mọi người đều được liên kết và làm việc hướng tới cùng một mục tiêu.
2. Tính minh bạch : Bằng cách chia sẻ sprint backlog với các bên liên quan, nhóm phát triển có thể cung cấp thông tin rõ ràng về tiến trình đang được thực hiện và quản lý kỳ vọng một cách hiệu quả. Các bên liên quan có thể theo dõi quá trình hoàn thành câu chuyện của người dùng và hiểu cách giải quyết các ưu tiên của họ.
3. Trao quyền cho khả năng tự tổ chức : Sprint backlog cho phép nhóm phát triển nắm quyền sở hữu công việc của họ. Họ có thể linh hoạt quyết định cách chia câu chuyện của người dùng thành các nhiệm vụ và chọn nhiệm vụ nào họ sẽ thực hiện dựa trên kỹ năng và tính khả dụng của họ.
4. Tạo điều kiện hợp tác : Sprint backlog thúc đẩy Quy trình phối hợp giữa các phòng ban trong nhóm phát triển. Bằng cách chia các câu chuyện của người dùng thành các nhiệm vụ nhỏ hơn, các thành viên trong nhóm có thể làm việc cùng nhau, chia sẻ trách nhiệm và giúp đỡ lẫn nhau khi cần.
5. Tập trung vào các mục tiêu ngắn hạn : Sprint backlog giúp nhóm tập trung vào các mục tiêu ngắn hạn phù hợp với thời gian chạy nước rút. Điều này đảm bảo rằng nhóm vẫn linh hoạt và có thể thích ứng với những thay đổi dễ dàng hơn.

Viindoo Sprint Backlogs – theo dõi tiến độ và tập trung vào các mục tiêu ngắn hạn

Vai trò của Sprint Backlog trong Scrum

Sprint Backlog có một vai trò rất quan trọng đối với Development Team nói riêng và Scrum Team nói chung:

Đối với Development Team

• Sprint backlog giúp Development Team hiểu rõ các yêu cầu của khách hàng và ước tính được thời gian cần thiết để hoàn thành các user story trong một Sprint.
• Giúp Development Team tổ chức và phân bổ các công việc cụ thể, từ đó giúp họ hoàn thành các user story một cách hiệu quả hơn.
• Cung cấp cho Development Team một mục tiêu rõ ràng và giúp họ đạt được mục tiêu đó trong thời gian của Sprint.
• Sprint backlog giúp các thành viên trong nhóm có thể theo dõi tiến độ của Sprint.

Đối với Scrum Team

• Sprint backlog giúp Scrum Master và Product Owner đánh giá tiến độ của các user story và các công việc tương ứng trong Sprint.
• Sprint backlog cung cấp cho Scrum Team một cơ chế để quản lý và theo dõi các công việc cần được hoàn thành trong Sprint, giúp họ đạt được mục tiêu của Sprint một cách hiệu quả.
• Sprint backlog cũng giúp Scrum Team thực hiện việc phân tích và đánh giá kết quả của Sprint, từ đó cải thiện quy trình phát triển phần mềm trong tương lai.

Một Sprint Backlog hoàn hảo bao gồm những gì?

Sprint Backlog không nên chỉ có các câu chuyện của người dùng được chọn cho sprint. Sprint Backlog giống như một kế hoạch tổng thể cho Sprint. Vì vậy, nó phải bao gồm các nhiệm vụ và cách để theo dõi tiến độ thực hiện các nhiệm vụ đó.

Để quản lý công việc tốt nhất, Sprint Backlog nên gồm các nội dung sau:

• Câu chuyện của người dùng được chọn từ các Product Backlog
• Các nhiệm vụ được chia theo câu chuyện của người dùng
• Cấu trúc dạng bảng để ghi lại tiến trình thực hiện các nhiệm vụ đó

Sprint Backlog cần được tạo ra trước khi bắt đầu mỗi Sprint. Thông thường, Sprint Backlog có thể được tạo ra bằng phần mềm quản lý Scrum hoặc bảng tính. Khối lượng công việc tích lũy trong Sprint, có thể được hiển thị dưới dạng biểu đồ Sprint Burndown. Bằng cách theo dõi phần còn lại của công việc trong Sprint backlog, nhóm phát triển có thể quản lý tiến độ của nó.

Trên đây, Got It đã cung cấp cho các bạn một bức tranh tổng quan về Sprint Backlog. Hy vọng bài viết này sẽ giúp các bạn hiểu rõ hơn về khái niệm Sprint Backlog là gì và vai trò của nó trong một Scrum. Sprint Backlog đơn giản chỉ là một bảng phân công các công việc cần thực hiện trong một Sprint. Sau khi hiểu Sprint Backlog là gì, các bạn hãy áp dụng nó để quản lý các công việc hàng ngày một cách hiệu quả nhé!

Tóm tắt nội dung

• 1 Sprint Backlog là gì?
• 2 Các thành phần của Sprint backlog
• 3 Vai trò của Sprint Backlog trong Scrum
• 4 Quá trình tạo Sprint backlog
• 5 Làm sao để Sprint Backlog diễn ra hiệu quả?
• 6 Sự khác biệt giữa Product Backlog và Sprint Backlog
• 7 Những lưu ý khi tạo Sprint backlog

Trong phương pháp Agile Scrum, Sprint backlog là một phần quan trọng của quá trình phát triển phần mềm. Được tạo ra trong quá trình Sprint planning, Sprint backlog giúp đảm bảo rằng sản phẩm phần mềm được phát triển theo đúng tiến độ và đáp ứng được các yêu cầu của khách hàng.

Cùng tìm hiểu chi tiết hơn về Sprint backlog, các thành phần cấu thành và cách để thực hiện hiệu quả trong bài viết sau nhé!

Các bước xây dựng Backlog hiệu quả

Product Backlog còn là nơi phân chia các nhiệm vụ phức tạp thành một chuỗi các bước cụ thể và ủy thác chúng cho các thành viên trong nhóm. Thực hiện 4 bước sau sẽ giúp xây dựng một Product Backlog có hiệu quả:

5.1 Bước 1: Tạo Product Roadmap

Product roadmap là cơ sở cho Product Backlog. Đầu tiên, một nhóm nên tạo một lộ trình sản phẩm, nó sẽ đóng vai trò như một kế hoạch hành động về cách sản phẩm sẽ phát triển và thay đổi trong quá trình phát triển. Lộ trình sản phẩm là tầm nhìn dài hạn về việc phát triển sản phẩm.

5.2 Bước 2: Liệt kê hạng mục Product Backlog

Sau khi đã thiết lập Product Roadmap, nhóm có thể bắt đầu liệt kê hạng mục tồn đọng sản phẩm. Danh sách này nên chứa các mục công việc được ưu tiên và các ý tưởng thực hiện.

Trong quá trình tạo Product Backlog này, quan trọng là cần liên lạc với các bên liên quan và lắng nghe ý kiến của họ để cải tiến sản phẩm. Nếu áp dụng phương pháp Agile, có thể tổ chức các cuộc thảo luận như một phần của cuộc họp lập kế hoạch Sprint.

5.3 Bước 3: Xác định mức độ ưu tiên công việc tồn đọng

Sau khi đội nhóm đã liệt kê tất cả các mục công việc tồn đọng của sản phẩm, hãy sắp xếp và ưu tiên các nhiệm vụ quan trọng nhất. Có thể xác định các mặt hàng ưu tiên bằng cách đặt mình vào vị trí của khách hàng và xem xét những mục nào mang lại giá trị cao nhất cho họ.

5.4 Bước 4: Cập nhật thường xuyên

Khi làm việc với Product Backlog, hãy nhớ rằng nó là một tài liệu sống. Có thể liên tục bổ sung các mục công việc vào danh sách tồn đọng và ưu tiên hoặc cải thiện chúng trong quá trình làm việc.

Nội dung cơ bản của một Backlog hoàn chỉnh

Một backlog thường bao gồm các thông tin cơ bản về các nhiệm vụ, công việc hoặc yêu cầu trong dự án. Dưới đây là các thành phần cơ bản của một backlog đầy đủ:

1. Danh sách nhiệm vụ: Liệt kê các nhiệm vụ, công việc hoặc yêu cầu cần thực hiện trong dự án. Mỗi nhiệm vụ nên được mô tả một cách rõ ràng và đủ chi tiết để hiểu được yêu cầu cần thiết.
2. Thời gian hoàn thành: Nên được xác định rõ ràng và cụ thể về ngày giờ bắt buộc hoàn thành nhiệm vụ. Từ đó cho doanh nghiệp một cái nhìn tổng quan về dự án và dễ dàng trong việc báo cáo tiến độ thực hiện công việc.
3. Người thực hiện: Đây là thông tin về người hoặc nhóm người được giao trách nhiệm thực hiện mỗi nhiệm vụ. Xác định người thực hiện giúp phân chia công việc rõ ràng và tạo trách nhiệm cá nhân trong dự án tập thể.
4. Mức độ ưu tiên: Mỗi nhiệm vụ trong backlog nên được xác định mức độ ưu tiên. Điều này giúp xác định công việc quan trọng nhất và cần được hoàn thành trước. Có thể sử dụng các tiêu chí như giá trị, khả năng ảnh hưởng hoặc mức độ cần thiết để đánh giá mức độ ưu tiên.
5. Trạng thái nhiệm vụ: Thể hiện tình trạng hoặc tiến trình của công việc. Các trạng thái thông thường có thể là “chưa bắt đầu”, “đang tiến hành”, “hoàn thành” hoặc “đã hủy”. Theo dõi trạng thái nhiệm vụ giúp quản lý tiến độ và biết được công việc nào cần quan tâm và ưu tiên.

Product Backlog là gì?

Trong phát triển phần mềm, Product Backlog là danh sách các công việc cần phải thực hiện để hoàn thành một dự án. Những công việc trong Product Backlog có thể là các yêu cầu, tính năng hoặc các lỗi đầu vào cho Sprint Backlog.

Product Backlog các Product Owner hay Product Manager trực tiếp quản lý. Nội dung công việc trong Product Backlog sẽ được cập nhật liên tục theo sự thay đổi của khách hàng hay nhu cầu thị trường.

Về bản chất, Product Backlog tương tự như Sprint Backlog. Cả hai đều giúp nhóm phát triển quản lý công việc tồn đọng trong dự án. Tuy nhiên, Product Backlog có phạm vi công việc rộng hơn. Dưới đây là một số khía cạnh khác nhau giữa Product Backlog và Sprint Backlog:

• Product backlog là nơi lưu trữ tất cả các câu chuyện của người dùng. Trong khi đó Sprint Backlog chỉ chứa các câu chuyện của người dùng đã được chọn trong một Sprint. Hiểu một cách đơn giản, Sprint Backlog là một tập hợp con của Product Backlog.
• Sprint Backlog phân chia các nhiệm vụ cụ thể, còn Product Backlog mô tả tổng quan về công việc. Nếu Product Backlog là một chiến lược, thì Sprint Backlog được thiết kế để hiện thực hóa chiến lược đó.

Mẹo Quản Lý Sprint Backlog Hiệu Quả Với Phần Mềm Dự Án Viindoo

Viindoo Project là phần mềm quản lý dự án theo 12 nguyên tắc Agile tcung cấp các tính năng và chức năng để quản lý hiệu quả công việc tồn đọng trong sprint của bạn. Tool quản lý dự án này giúp quản lý tồn đọng sprint hiệu quả nhờ:

1. Quản lý câu chuyện người dùng : Sử dụng giao diện trực quan của Viindoo để tạo, ưu tiên và quản lý câu chuyện của người dùng. Chỉ định điểm câu chuyện hoặc ước tính nỗ lực để hiểu rõ hơn về khối lượng công việc và lập kế hoạch chạy nước rút một cách hiệu quả.
2. Phân chia nhiệm vụ : Chia các câu chuyện của người dùng thành các nhiệm vụ nhỏ hơn bằng cách sử dụng các tính năng quản lý tác vụ của Viindoo. Phân công nhiệm vụ cho các thành viên trong nhóm, đặt ngày hoàn thành và theo dõi tiến trình của họ trong suốt giai đoạn chạy nước rút.
3. Biểu đồ ghi lại : Sử dụng biểu đồ ghi lại của Viindoo để trực quan hóa tiến trình Sprint Backlog của bạn. Biểu đồ này hiển thị công việc còn lại so với công việc đã lên kế hoạch, cho phép bạn xác định bất kỳ sai lệch nào so với kế hoạch ban đầu.
4. Cộng tác và Giao tiếp : Viindoo cung cấp các tính năng cộng tác và liên lạc, chẳng hạn như nhận xét và gắn thẻ các thành viên trong nhóm. Sử dụng các tính năng này để đảm bảo giao tiếp rõ ràng và thông báo cho mọi người về trạng thái câu chuyện và tác vụ của người dùng.
5. Tích hợp với Hệ thống kiểm soát phiên bản : Viindoo tích hợp liền mạch với các hệ thống kiểm soát phiên bản phổ biến như Git. Việc tích hợp này cho phép bạn liên kết trực tiếp các câu chuyện và tác vụ của người dùng với các cam kết mã, đảm bảo khả năng truy xuất nguồn gốc và khả năng hiển thị trong quá trình phát triển.

Quản lý Sprint Backlog hiệu quả: Sự phụ thuộc vào hoạt động, phân tích và kiểm soát

Bằng cách tận dụng các khả năng của Phần mềm dự án Viindoo, bạn có thể hợp lý hóa việc quản lý Sprint Backlog của mình, tăng cường cộng tác nhóm và cải thiện năng suất tổng thể trong Agile dự án phát triển phần mềm.

Quá trình tạo Sprint backlog

Sprint planning meeting

Đây là buổi họp giữa nhóm Scrum và Product Owner để thảo luận về các yêu cầu của khách hàng và lên kế hoạch cho sprint tiếp theo. Trong buổi họp này, nhóm Scrum sẽ xác định các user story cần triển khai trong sprint và tạo Sprint backlog.

Prioritizing user stories

Sau khi xác định các user story cần triển khai, nhóm Scrum cần ưu tiên các user story để đảm bảo rằng những yêu cầu quan trọng nhất sẽ được hoàn thành trước.

Estimating user stories

Nhóm Scrum cần ước tính thời gian và công sức cần thiết để triển khai mỗi user story. Điều này giúp đưa ra kế hoạch và lên lịch công việc cho sprint.

Breaking down user stories into tasks and subtasks

Sau khi đã ước tính thời gian và công sức cần thiết, nhóm Scrum sẽ phân chia mỗi user story thành các task và subtask. Các task và subtask sẽ được gán cho các thành viên trong nhóm để thực hiện.

Trong quá trình tạo Sprint backlog, việc phân tích, ước tính và phân chia công việc là rất quan trọng để đảm bảo rằng sprint sẽ được triển khai một cách hiệu quả và đáp ứng được yêu cầu của khách hàng. Sprint backlog sẽ được cập nhật và điều chỉnh thường xuyên trong suốt quá trình sprint để đảm bảo tiến độ và chất lượng của sản phẩm.

Sprint Backlog là gì?

Sprint backlog là một phần của quá trình Agile Scrum, đây là một công cụ quản lý công việc của nhóm phát triển. Về cơ bản đây là một bảng phân chia công việc theo các User stories (các câu chuyện người dùng) và các Task (nhiệm vụ) phải hoàn thành. Mỗi Sprint Backlog sẽ bao gồm những Product Backlog Items được lựa chọn cho Sprint và kế hoạch công việc mà nhóm phát triển cần hoàn thành để đạt được Sprint.

Nhóm phát triển sẽ cập nhật Sprint Backlog trong suốt Sprint và có thể thêm hoặc loại bỏ các công việc trong Sprint Backlog. Công việc hay nhiệm vụ trong Sprint Backlog được cập nhật theo trạng thái To Do (việc cần làm), In Progress (đang tiến hành) và Done (đã hoàn thành). Chỉ có nhóm phát triển được đảm nhiệm việc cập nhật công việc trong Sprint Backlog và Product Owner (chủ sản phẩm) hay Scrum Master (điều phối viên) đều không có quyền này.

Quy trình 5 bước tạo Backlog chính xác nhất

Bước 1: Xác định mục tiêu và phạm vi

Xác định mục tiêu tổng thể của dự án hoặc sản phẩm mà đội nhóm đang thực hiện. Điều này bao gồm định rõ những gì doanh nghiệp muốn đạt được với dự án và những giá trị mà họ muốn mang lại cho khách hàng. Sau đó, Nhà quản lý cần xác định phạm vi của dự án bằng cách định rõ các tính năng, yêu cầu và nhiệm vụ cần thực hiện để đạt được mục tiêu đã đề ra.

Bước 2: Thiết lập mức độ ưu tiên

Doanh nghiệp cần thiết lập mức độ ưu tiên của các yêu cầu và tính năng trong Backlog. Từ đó xác định các công việc quan trọng nhất và cần được ưu tiên thực hiện trước. Mức độ ưu tiên có thể được xác định dựa trên giá trị kinh doanh mà các yêu cầu mang lại, sự phức tạp của công việc, sự khẩn cấp, yếu tố may rủi và các yếu tố khác liên quan.

Bước 3: Ước lượng thời gian hoàn thành

Xác định thời gian hoàn thành cho mỗi yêu cầu hoặc tính năng trong Backlog giúp Nhà quản lý có cái nhìn tổng quan về thời gian cần thiết để hoàn thành dự án hoặc sản phẩm. Đo lường thời gian hoàn thành được tính toán dựa trên kinh nghiệm trước đây, khả năng của thành viên, đội nhóm và các yếu tố khác như sự phức tạp của công việc.

Bước 4: Quản lý nguồn lực và phân chia công việc

Nhà quản lý cần đánh giá nguồn lực có sẵn để thực hiện dự án hoặc sản phẩm. Bao gồm đánh giá nhân lực, kỹ năng chuyên môn và tài nguyên khác mà quản lý có thể sử dụng cho dự án. Sau đó, quản lý tiến hành phân chia công việc từ Backlog vào các đơn vị công việc cụ thể, như gán người thực hiện cho mỗi công việc và phân bổ nguồn lực để đảm bảo rằng các công việc được thực hiện đúng tiến độ.

Bước 5: Theo dõi và cập nhật thường xuyên

Cuối cùng, Nhà quản trị cần theo dõi tiến độ công việc và cập nhật Backlog thường xuyên và định kỳ theo ngày, tuần, tháng hoặc theo quý. Điều này giúp tổ chức kiểm soát tiến trình thực tế của dự án hoặc sản phẩm và cập nhật thông tin trong Backlog để phản ánh sự thay đổi và phản hồi từ khách hàng.

Doanh nghiệp có thể tổ chức cuộc họp định kỳ sau mỗi giai đoạn hoặc Sprint để đánh giá và xem xét Backlog, điều chỉnh ưu tiên, thời gian hoàn thành và phân chia công việc nếu cần thiết.

Sprint Backlog là gì?

Sprint Backlog là công cụ quản lý công việc của nhóm phát triển (Development team) trong một Sprint. Mỗi Sprint Backlog sẽ bao gồm những Product Backlog Items được chọn cho Sprint và kế hoạch công việc nhóm phát triển phải hoàn thành để đạt được mục tiêu của Sprint (Sprint Goal).

Về cơ bản, Sprint Backlog là một bảng công việc phân chia theo các câu chuyện của người dùng (User-stories) và các nhiệm vụ (Task) phải hoàn thành. Nhóm phát triển sẽ cập nhật Sprint Backlog trong suốt Sprint. Họ có thể bổ sung thêm công việc mới hoặc loại bỏ những việc không cần thiết khỏi Sprint Backlog.

Trong Sprint Backlog, công việc hay nhiệm vụ sẽ được cập nhật theo các trạng thái như: To Do (việc cần làm), In Progress (đang tiến hành), Done (đã hoàn thành). Khi một công việc đã “Done” thì giá trị ước lượng của công việc đó sẽ được cập nhật.

Việc cập nhật công việc trong Sprint Backlog sẽ chỉ do nhóm phát triển đảm nhiệm. Product Owner (chủ sản phẩm) hay Scrum Master (điều phối viên) đều không có quyền chỉnh sửa Sprint Backlog.

Những lưu ý khi tạo Sprint backlog

Khi tạo Sprint backlog, có một số lưu ý quan trọng sau đây:

Hiểu rõ về yêu cầu khách hàng

Để tạo Sprint backlog hiệu quả, nhóm Scrum cần hiểu rõ yêu cầu của khách hàng. Điều này đảm bảo rằng sản phẩm sẽ đáp ứng được yêu cầu và mong đợi của khách hàng.

Độ ưu tiên và ước lượng thời gian

Các user story cần được ưu tiên một cách hợp lý để đảm bảo tiến độ sprint. Thời gian ước tính cho mỗi user story cũng rất quan trọng để đảm bảo rằng sprint sẽ được hoàn thành đúng hạn.

Phân bổ công việc hợp lý

Sau khi đã ước tính thời gian cần thiết, nhóm Scrum cần phân bổ công việc cho các thành viên trong nhóm. Việc này giúp đảm bảo rằng mỗi thành viên sẽ có đủ công việc để hoàn thành trong suốt sprint.

Đảm bảo tính linh hoạt và thích ứng

Sprint backlog không phải là một tài liệu cố định và sẽ phải được điều chỉnh và cập nhật thường xuyên trong suốt quá trình sprint. Nhóm Scrum cần đảm bảo tính linh hoạt và thích ứng để có thể đáp ứng được các yêu cầu thay đổi của khách hàng.

Khi tạo Sprint backlog, nhóm Scrum cần tập trung vào các yêu cầu của khách hàng và đảm bảo rằng sprint sẽ được triển khai một cách hiệu quả và đáp ứng được mong đợi của khách hàng. Việc tạo và quản lý Sprint backlog cần tính linh hoạt và thích ứng để đảm bảo tiến độ và chất lượng của sản phẩm.

Như vậy có thể thấy việc tạo và quản lý Sprint backlog đòi hỏi sự tập trung và kỹ năng của nhóm Scrum để đảm bảo rằng sản phẩm đáp ứng được yêu cầu của khách hàng và hoàn thành đúng tiến độ. Trên đây là những thông tin cần thiết cho bạn về Sprint backlog. Nếu bạn đang muốn bắt đầu với công việc Tester thì đừng quên tham khảo Khóa học Tester cho người mới bắt đầu nhé!

9 Tips để tạo một Sprint Backlog tốt

Bài đăng này đã không được cập nhật trong 2 năm

The sprint backlog là một danh sách đơn giản bao gồm các task, các task này phải được thực hiện bởi team để bàn giao các chức năng trong phần tăng trưởng vào cuối sprint đó. Sprint backlogđược thực hiện trong phần thứ hai buổi họp Sprint planning với sự tham gia của tất cả các thành viên trong nhóm. Quá trình thực hiện sprint planning này cần được thực sự lưu ý bởi nó sẽ giúp team hiểu rõ hơn về các công việc cần được hoàn thành và lên một kế hoạch tốt hơn cho sprint. Mặc dù vậy, nhiều team vẫn gặp rất nhiều khó khăn và đang phải vật lộn với việc này. Dưới đây là một vài gợi ý để tạo ra một Sprint backlog tốt.

Tất cả các thành viên trong team đều cần tham gia vào quá trình tạo sprint backlog

Sự tham gia của tất cả các thành viên trong team vào quá trình tạo Sprint backlog là cần thiết. Trong một team đa nhiệm, tất cả mọi người có thể đóng góp vào việc tạo ra task, cho phép team phân tích Story trên nhiều quan điểm khác nhau. Điều này tạo ra Sprint Backlog phong phú hơn nếu là nếu chỉ có coder hoặc một technical member tham gia.

Thảo luận về cách thức thực hiện từng item.

Trước khi bất kỳ task nào được viết ra, cả team dành thời gian thảo luận về các Story được đưa vào Sprint backlog là rất cần thiết. Trên thực tế, phần lớn cuộc họp cần được dành để hiểu team sẽ giải quyết những Story này như thế nào. Cuộc thảo luận này sẽ bao gồm việc tạo ra các thiết kế cơ bản, kiểm tra code hiện có, thảo luận các kiến trúc hệ thống, v.v … Có hiểu biết chung về Story và các giải pháp có thể sẽ cho phép nhóm tạo danh sách công việc phải làm.

Có một định nghĩa về việc hoàn thành (DoD- Defination of Done).

Có một định nghĩa chung về DoD được team thống nhất tại chỗ, các yêu cầu về sự hoàn thành này cần đươc định nghĩa và hiển thị cho mọi người cùng biết. Định nghĩa này như là một hướng dẫn cho những gì nên được thực hiện và sẽ nhắc nhở nhóm rằng tiêu chí chấp nhận chung cho mỗi task trong backlog.

Xác định tất cả các loại task.

Quá nhiều team chỉ tập trung vào việc coding. Sự thật là, chỉ coding không thì không đủ để cung cấp phần mềm có thể làm việc thực sự. Sprint backlog cần bao gồm mọi loại task: object modeling, coding, learning new technology, database activities, tests, v.v … Có một định nghĩa về DoD sẽ giúp nhắc nhở các team về những nhiệm vụ mà họ quên. Bằng cách liệt kê ra tất cả các yêu cầu, mong đợi trong một sản phẩm phần mềm được bàn giao và lần lượt thực hiện những việc đó thì nhóm sẽ có được một sự hiểu biết mới về effort thực sự cần có đối với các sprint tiếp theo.

Không estimate task.

Estimate cho task bằng số giờ là phổ biến và cần thiết cho team nếu đó là những sprint đầu, và nếu là lần đầu các thành viên làm việc với nhau. Các thành viên trong team cam kết hoàn thành các task trong sprint trong ý thức, tư tưởng của họ chứ không ép buộc rằng đó là một công việc phải hoàn thành. Nếu chúng ta estimate rằng một task sẽ mất 4 giờ để hoàn thành nhưng thực tế nó mất 12 giờ thì cũng vẫn được, miễn là team đạt được mục tiêu của sprint (sprint goal), nó sẽ tạo ra sự khác biệt nào ? Xác định càng nhiều nhiệm vụ càng tốt và tạo ra một cảm giác tiến bộ liên tục trong quá trình thực hiện Sprint là đủ.

Không giao task trước.

Chống lại sự cám dỗ về việc chỉ đạo trong công việc. Nhóm nên quyết định ai sẽ làm gì theo hoàn cảnh. Nếu bạn bắt đầu phân công nhiệm vụ cho thành viên nhóm “phù hợp nhất”, nó sẽ ngăn không cho các thành viên còn lại học hỏi những điều mới, ngăn cản sự giao tiếp và giảm sự cộng tác giữa các thành viên trong team. Trao quyền và tin tưởng vào nhóm để tự quản lý.

Xem lại Sprint commitment (cam kết trong Sprint).

Sau khi xác định nhiệm vụ, khi team rõ hơn về nỗ lực thực sự cần thiết, cần phải phân tích lại các commitment. Liệu Sprint backlog đã chọn có thực sự phù hợp đặt trong sprint hay không? Nếu không, có một số lựa chọn khác. Bỏ một vài task có mức độ ưu tiên thấp nhất ra hoặc chia nhỏ các task thành từng phần nhỏ. Điều quan trọng cuối cùng là nhóm có thể cam kết một cái gì đó mà họ có một sự hiểu biết tốt về nó.

Không sử dụng quá nhiều thời gian.

Tôn trọng timebox. Xác định thời gian cho mỗi cuộc họp và tuân thủ theo. Timebox buộc team phải tập trung và thảo luận kỹ lưỡng các item, khiến cho các task sẽ được phân tích rõ hơn. Nhóm không phải lúc nào cũng có thể xác định được mọi thứ cần làm trong suốt Sprint, nhưng đó không phải là vấn đề. Điều quan trọng hơn là họ có một sự hiểu biết thấu đáo về các Story họ đưa và Sprint.

Phát triển Sprint Backlog trong quá trình thực hiện Sprint.

Nhóm sẽ hiểu thêm về những Story khi họ làm việc với chúng. Những ý tưởng mới có thể nảy sinh và những ý tưởng cũ có thể bị bỏ đi. Sprint backlog nên phản ánh được những thay đổi này. Daily Scrum là một khoảng thời gian tuyệt vời nhìn nhận, đánh giá để có sự thay đổi kịp thời và ngay lập tức, thêm mới task hoặc bỏ đi những task không cần thiết.

Nếu nhóm đầu tư thời gian và nỗ lực để xây dựng một Sprint backlog tốt nó sẽ mang đến sự hiểu biết tổng thể tốt hơn rất nhiều về mức độ hoàn thành công việc, một cảm giác tiến bộ mỗi ngày, và cam kết rõ ràng về những gì sẽ được bàn giao. Nó có thể không dễ dàng, nhưng nó sẽ mang lại giá trị thực sự.

Nguồn: https://www.scrumalliance.org/community/articles/2009/march/9-tips-for-creating-a-good-sprint-backlog

All rights reserved

Backlog là một thuật ngữ trong quản lý dự án và phát triển sản phẩm. Nó đóng vai trò quan trọng giúp xác định, ưu tiên và theo dõi các công việc cần thực hiện. Backlog đảm bảo tiến độ công việc hiệu quả, cung cấp cái nhìn tổng quan về yêu cầu mới và công việc chưa hoàn thành.

Nhà quản trị hãy cùng MISA AMIS HRM tìm hiểu về Backlog là gì và 5 cách để quản lý nó một cách hiệu quả trong doanh nghiệp.

TẢI MIỄN PHÍ DASBOARD NHÂN SỰ – ĐIỀN SỐ TỰ ĐỘNG NHẢY

Đặc điểm cơ bản của một Product Backlog

Trong cuốn “Agile Product Management with Scrum: Creating Products That Customers Love”, ông Roman Pichler đã đưa ra quy tắc DEEP khi tạo một Product Backlog. Theo đó, Product Backlog có 4 đặc điểm cơ bản là Detailed appropriately, Estimated, Emergent và Prioritized.

Detailed appropriately (Chi tiết một cách hợp lý)

Trong Product Backlog, không phải bất cứ hạng mục công việc nào cũng cần thể hiện một cách chi tiết. Thông thường, những việc quan trọng phải làm trước sẽ được sắp xếp ở phía trên cùng của Product Backlog. Những công công việc này cần phải chi tiết để có thể đưa vào Sprint gần nhất.

Mức độ chi tiết thường giảm dần theo độ ưu tiên và cần thiết của hạng mục công việc đó. Công việc có độ ưu tiên thấp hoặc phụ thuộc vào những hạng mục khác nên để ở cuối cùng. Chúng có thể được phân tích ít chi tiết hơn những hạng mục công việc ở phía trên Product Backlog.

Estimated (Tính ước lượng)

Không chỉ là một danh sách các công việc phải làm, Product Backlog còn là một công cụ lập kế hoạch hữu ích. Trong Product Backlog, các hạng mục dành cho bản phát hành mới cần phải được ước lượng. Chúng có thể do nhóm phát triển hoặc khách hàng cung cấp.

Nhóm Phát triển sẽ cung cấp cho Product Owner khối lượng công việc ước lượng của từng hạng mục. Product Owner và các bên liên quan sẽ cung cấp thông tin về giá trị của sản phẩm. Đó có thể là lợi nhuận, chi phí, rủi ro trong kinh doanh và nhiều hạng mục khác.

Emergent (Sự tiến hóa)

Product Backlog không phải là một thực thể tĩnh mà nó luôn thay đổi theo thời gian. Các các câu chuyện của người dùng trong Product Backlog sẽ được thêm, xóa hoặc đánh giá lại. Product Backlog liên tục được Product Owner cập nhật trong suốt Sprint.

Ví dụ: Nhóm Phát triển cung cấp cho Product Owner khối lượng công việc của từng hạng mục. Nhưng trong quá trình thực hiện có một số rủi ro kỹ thuật dẫn đến sự thay đổi các hạng mục. Lúc này, Product Owner sẽ phải xem xét việc thêm bớt, hay sắp xếp lại mức độ ưu tiên trong Product Backlog.

Prioritized (Tính ưu tiên)

Một Product Backlog cần sắp xếp với các mặt hàng có giá trị nhất ở trên cùng và ít giá trị nhất ở dưới cùng. Cách làm này giúp nhóm có thể tối đa hóa giá trị của sản phẩm.

Chúng ta có thể đặt mức độ ưu tiên cao cho các hạng mục quan trọng cần được đưa vào Sprint. Tiếp đến sẽ là các hạng mục dự định phát hành trong đợt 1. Khi xếp ưu tiên vượt quá giai đoạn phát hành đợt 1, chúng ta có thể sẽ mất nhiều thời gian hơn.

Tóm lại, Product Backlog là một công cụ giúp quản lý công việc hiệu quả. Chúng ta có thể áp dụng Product Backlog trong nhiều lĩnh vực và ngành nghề khác nhau. Sau bài viết này, hi vọng các bạn đã hiểu rõ được Product Backlog là gì cũng như đặc điểm của nó. Nếu bạn muốn trở thành một Product Owner, hãy nắm vững các kiến thức Got It đã chia sẻ nhé!