Bài viết

Biểu đồ Sprint Burndown có vai trò gì trong Scrum?

Biểu đồ Sprint Burndown thể hiện các ước tính cập nhật hàng ngày về khối lượng công việc còn lại tới khi hoàn thành. Biểu đồ Sprint Burndown lấy dữ liệu ước tính từ Sprint Backlog.

Ví dụ với bảng công việc như Hình 1 thì ta có Biểu đồ Sprint Burndown như Hình 2.
Cập nhật Sprint Backlog

Hình 1. Bảng công việc

Biểu đồ sprint burndown

Hình 2. Biểu đồ sprint Burndown

Biểu đồ Sprint Burndown giúp nhóm biết được trạng thái công việc hiện tại. Nếu xu hướng công việc đang tiến triển đang chậm hơn so với kỳ vọng, một dự báo rằng Sprint này có thể không thể hoàn thành hết công việc, như vậy Nhóm nên tập trung hoàn thành những nội dung quan trọng nhất để đạt mục tiêu Sprint và thậm chí làm việc với PO. Cũng trong trường hợp chậm này, Nhóm cũng nhìn thấy rằng mình đang gặp một số trở ngại để tiến tới mục tiêu Sprint. Lúc này Nhóm có thể cùng thanh tra để tìm ra nguyên nhân của những trở ngại và hành động thích nghi phù hợp.

Tuy nhiên, biểu đồ này chỉ thể hiện một ước lượng, do đó Nhóm không nên quá tin tưởng vào biểu đồ mà nên liên tục thanh tra và thích nghi dựa vào những công việc thực tế khác.

 

Phần tăng trưởng có vai trò gì trong Scrum?

Phần tăng trưởng là tên gọi ngắn của Phần tăng trưởng Sản phẩm Có khả năng Chuyển giao được (Potentially Shippable Product Increment) là phần sản phẩm Nhóm Phát triển tạo ra cuối mỗi Sprint. Đây là một khái niệm quan trọng trong Scrum tạo ra sự khác biệt lớn về mặt sản phẩm so với các phương pháp truyền thống. Scrum không chỉ đơn giản tách quá trình phát triển thành các Sprint nhỏ liên tiếp nhau, mà cuối mỗi Sprint đòi hỏi Nhóm Phát triển phải chuyển giao một phần tính năng “hoàn chỉnh” của sản phẩm. Hoàn chỉnh ở đây được hiểu theo nghĩa được Product Owner chấp nhận dựa theo Định nghĩa Hoành thành đã được thống nhất trước đó.

Đối với sản xuất phần mềm, điều đó có nghĩa là cuối mỗi Sprint, Nhóm Phát triển cần bàn giao một gói tính năng hoạt động tốt, đã được kiểm thử, tích hợp vào hệ thống và có đầy đủ tài liệu người dùng theo yêu cầu. Nhờ vậy, ở bất cứ thời điểm cuối Sprint nào thì sản phẩm đều đạt được trạng thái sẵn sàng phát hành mà không cần làm thêm bất cứ công việc nào liên quan đến đóng gói, tích hợp hay tinh chỉnh nhỏ. Điều này mang lại lợi ích cho nhiều phía từ các góc độ khác nhau, chẳng hạn như gia tăng sự minh bạch, sớm chuyển giao được giá trị kinh doanh và giảm thiểu rủi ro…

Khái niệm “chuyển giao được” ở đây không có nghĩa là sản phẩm phải được phát hành ngay. Việc có phát hành sản phẩm hay không là phụ thuộc vào quyết định liên quan đến kinh doanh. Còn trạng thái “chuyển giao được” thể hiện sự “tin tưởng” vào tính sẵn sàng của sản phẩm.

Có thể nói, việc chuyển giao được một Phần tăng trưởng ở cuối mỗi Sprint là nhiệm vụ cốt lõi và không hề dễ dàng đối với Nhóm Phát triển. Thông thường thì đối với các nhóm mới sử dụng Scrum, họ thường thất bại trong những Sprint đầu tiên. Bởi vì, để đạt được kết quả mong muốn này, Nhóm Phát triển cần phải áp dụng rất nhiều kỹ năng, công cụ, cộng tác và đưa ra các quyết định tốt trong suốt quá trình diễn ra Sprint. Có thể kể đến một số yếu tố ảnh hưởng đến việc này như:

  • Nhóm Phát triển có đảm bảo tính liên chức năng để thực hiện các công việc như được thống nhất trong Định nghĩa Hoàn thành không?
  • Nhóm Phát triển có biết cách lập kế hoạch Sprint để đảm bảo thuận lợi cho việc tạo ra phần tăng trưởng không?
  • Nhóm Phát triển có được trang bị các công cụ tự động để giúp cho quá trình phát triển, kiểm thử, tích hợp,… được diễn ra nhanh chóng không?
  • Nhóm Phát triển có vận hành tốt để đạt được mục tiêu chung hay không?
  • Khung thời gian của Sprint có đủ dài để hoàn thành các công việc hay không?

Sprint Backlog là gì?

Sprint Backlog là bảng công việc được Nhóm Phát triển sử dụng để quản lý quá trình phát triển trong một Sprint. Sprint Backlog được Nhóm Phát triển tạo ra trong buổi Lập kế hoạch Sprint và cập nhật trong suốt Sprint. Sprint Backlog chứa danh sách các hạng mục được phát triển trong Sprint và các công việc cần làm tương ứng với từng hạng mục để hoàn thành nó. Một Sprint Backlog cơ bản có cấu trúc như sau:

Sprint Backlog

Cấu trúc của Sprint Backlog

Trong đó, cột “Hạng mục trong Product Backlog” chứa danh sách các hạng mục được phát triển trong Sprint. Cột “Công việc trong Sprint” là danh sách công việc cần thực hiện tương ứng với từng hạng mục Product Backlog. Cột “Ước tính khối lượng công việc ban đầu” chứa giá trị ước tính mà Nhóm Phát triển đã đưa ra ở đầu Sprint. Sau mỗi ngày làm việc, nhóm sẽ cập nhật lại các giá trị này tương ứng với lượng công việc còn lại cần thực hiện cho từng nhiệm vụ. Ví dụ, sau 3 ngày thì Sprint Backlog có thể được cập nhật như sau:

Cập nhật Sprint Backlog

Cập nhật Product Backlog

Các công việc trong Sprint Backlog có thể được cập nhật (thêm, chỉnh sửa, loại bỏ,….) tùy theo tình hình phát triển hiện tại.

Nhóm Phát triển có thể sử dụng công cụ chuyên nghiệp, excel hay các bảng vật lý để thể hiện Sprint Backlog. Lý tưởng nhất vẫn là một bảng vật lý đặt ngay tại không gian làm việc của Nhóm Phát triển để giúp các thành viên luôn luôn nắm rõ được tình hình phát triển của Sprint.

Dựa trên Sprint Backlog, nhóm có thể sử dụng thêm Biểu đồ Sprint Burndown (Sprint Burndown Chart) để thể hiện tiến độ của Sprint qua từng ngày.

Cải tiến Sprint

Cải tiến Sprint là một sự kiện quan trọng trong Scrum diễn ra ngay sau buổi Sơ kết Sprint nhằm mục đích thanh tra và thích nghi quy trình làm việc. Nói cách khác đây là dịp để Nhóm Scrum nhìn lại quá trình làm việc của một Sprint và xác định những thay đổi cần thiết đối với quy trình để làm việc tốt hơn trong Sprint sau.

Thành phần tham dự: Nhóm Phát triểnScrumMaster bắt buộc phải tham dự. Product Owner có thể tham dự hoặc không. Ngoài ra Nhóm Phát triển còn có thể mời thêm những người khác cùng tham dự nếu cần thiết.

Thời gian: Sự kiện này được đóng khung trong 3 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thời gian có thể ngắn hơn, vào khoảng 45 phút tương ứng với 1 tuần làm việc của Sprint.

Mục đích của buổi Cải tiến Sprint bao gồm:

  • Thanh tra lại Sprint trước, về các yếu tố liên quan đến con người, giao tiếp, quy trình và công cụ.
  • Liệt kê những hạng mục đã làm tốt và những hạng mục có thể cải tiến được.
  • Lên kế hoạch triển khai các cải tiến về cách làm việc của Nhóm Scrum.

Có rất nhiều kỹ thuật để tiến hành một buổi Cải tiến Sprint, chẳng hạn như Glad-Sad-Mad, SpeedBoat, SailBoat,… Trang RetrospectiveWiki có liệt kê một số kỹ thuật thường được dùng.

Có một lỗi mà các nhóm thường gặp phải đó là buổi cải tiến chỉ tập trung vào những vấn đề làm chưa tốt để cải tiến. Điều này thường dẫn đến tình trạng các thành viên có cảm giác không thích thú với sự kiện này và xem nó như một cuộc họp mang tính tiêu cực. Hãy cố gắng tạo ra sự hứng thú và tinh thần tích cực trong các thành viên bằng cách động viên thông qua những công việc đã làm tốt.

Mặc dù việc cải tiến có thể diễn ra bất cứ lúc nào, nhưng sự kiện Cải tiến Sprint vẫn là thời điểm chính thức được quy định để làm việc này. Tuân thủ và thực hiện tốt sự kiện này là cách để tạo một thói quen thanh tra và thích nghi quy trình làm việc trong nhóm.

Đọc thêm:

Cải tiến Sprint với Speedboat

Cải tiến Sprint với Sailboat

Cải tiến Sprint với Glad, Sad, Mad.

Sơ kết Sprint

Sơ kết Sprint là sự kiện diễn ra ở cuối Sprint nhằm thanh trathích nghi sản phẩm đang được xây dựng. Sự kiện này bao gồm 2 hoạt động chính đó là dùng thử sản phẩm và thảo luận về tình hình của sản phẩm, hướng đi tiếp theo và những điều chỉnh đối với sản phẩm nếu cần thiết.

Thành phần tham dự: Nhóm Phát triển, ScrumMasterProduct Owner bắt buộc phải tham dự. Ngoài ra, Product Owner có thể mời những người khác như người dùng, khách hàng và các bên liên quan khác.

Thời gian: Sự kiện này đóng khung tối đa trong 4 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thường cần ít thời gian hơn.

Bắt đầu sự kiện, Product Owner sẽ trình bày về những hạng mục đã được lựa chọn cho Sprint, liệu chúng đã được hoàn thành hay chưa. Nhóm Phát triển có thể trình bày về những khó khăn mà mình gặp phải trong suốt Sprint và các giải pháp mà mình đã đưa ra.

Tiếp theo là buổi dùng thử sản phẩm. Thay vì để Nhóm Phát triển trình diễn về những tính năng mới làm được trong Sprint thì nên sắp xếp để những người tham gia có thể trực tiếp dùng thử sản phẩm, đặc biệt là những người dùng thực sự.

Sau đó, tất cả mọi người tham gia sẽ thảo luận và đóng góp ý kiến cho sản phẩm. Product OwnerNhóm Phát triển ghi nhận những ý kiến này. Product BacklogKế hoạch Phát hành có thể được thay đổi nếu cần thiết để phù hợp hơn với tình hình mới.

Sự kiện này cũng được coi là cơ hội để Product OwnerNhóm Phát triển tìm hiểu lẫn nhau. Product Owner tìm hiểu về sản phẩm và tình hình của Nhóm Phát triển. Nhóm Phát triển tìm hiểu về tình hình của Product Owner và thị trường.

Agipedia

Sprint Backlog là gì?

Sprint Backlog là bảng công việc được Nhóm Phát triển sử dụng để quản lý quá trình phát triển trong một Sprint. Sprint Backlog được Nhóm Phát triển tạo ra trong buổi Lập kế hoạch Sprint và cập nhật trong suốt Sprint. Sprint Backlog chứa danh sách các hạng mục được phát triển trong Sprint và các công việc cần làm tương ứng với từng hạng mục để hoàn thành nó. Một Sprint Backlog cơ bản có cấu trúc như sau:

Sprint Backlog

Cấu trúc của Sprint Backlog

Trong đó, cột “Hạng mục trong Product Backlog” chứa danh sách các hạng mục được phát triển trong Sprint. Cột “Công việc trong Sprint” là danh sách công việc cần thực hiện tương ứng với từng hạng mục Product Backlog. Cột “Ước tính khối lượng công việc ban đầu” chứa giá trị ước tính mà Nhóm Phát triển đã đưa ra ở đầu Sprint. Sau mỗi ngày làm việc, nhóm sẽ cập nhật lại các giá trị này tương ứng với lượng công việc còn lại cần thực hiện cho từng nhiệm vụ. Ví dụ, sau 3 ngày thì Sprint Backlog có thể được cập nhật như sau:

Cập nhật Sprint Backlog

Cập nhật Product Backlog

Các công việc trong Sprint Backlog có thể được cập nhật (thêm, chỉnh sửa, loại bỏ,….) tùy theo tình hình phát triển hiện tại.

Nhóm Phát triển có thể sử dụng công cụ chuyên nghiệp, excel hay các bảng vật lý để thể hiện Sprint Backlog. Lý tưởng nhất vẫn là một bảng vật lý đặt ngay tại không gian làm việc của Nhóm Phát triển để giúp các thành viên luôn luôn nắm rõ được tình hình phát triển của Sprint.

Dựa trên Sprint Backlog, nhóm có thể sử dụng thêm Biểu đồ Sprint Burndown (Sprint Burndown Chart) để thể hiện tiến độ của Sprint qua từng ngày.

5 giá trị Scrum

5-gia-tri-scrumNăm 2016, dựa trên những ý kiến của cộng đồng trên User Voice hai tác giả đã quyết định cung cấp thêm một bản cập nhật nhỏ nữa với nội dung: Giá trị Scrum (Scrum Value). 5 giá trị đó trong Scrum là:

  1. Tập trung
  2. Dũng cảm
  3. Cam kết
  4. Cởi mở
  5. Tôn trọng

Đọc thêm bài viết: Hướng dẫn Scrum 2016 có gì mới?

3 trụ cột của Scrum

Ba trụ cột (hay ba chân) của Scrum là Tính minh bạch, Sự thanh traSự thích nghi. Đây chính là phần lõi của khung làm việc Scrum, thiếu bất cứ trụ cột nào trong số này đều khiến khung Scrum không còn hoạt động đúng nữa.

Scrum có thể được nhìn nhận như là là một khuôn khổ lí thuyết và thực hành cho việc phát triển sản phẩm, nhưng nó cũng có thể được nhìn nhận như là một phương pháp quản lí kiểu mới dành cho các tổ chức quản lí dựa vào tri thức (Knowledge-Based Management). Đi từ ý tưởng từ sư tổ ngành Quản lí Peter Drucker, đến Ikujiro Nonaka và Takeuchi, Scrum thực sự là một khung làm việc rất phù hợp với thời đại tri thức ngày nay, và được Steve Denning đánh giá là một trong các phát kiến quan trọng nhất trong lĩnh vực quản trị hiện đại.

Sức mạnh của Scrum nằm trong cả cách tiếp cận, triết lí, cho đến cấu trúc và các biện pháp thực hành cụ thể. Ở bài này, chúng ta cùng tìm hiểu thành phần nằm trong lõi của Scrum: BA CHÂN CỦA SCRUM.

Ba chân (hay ba trụ cột) của Scrum bao gồm Tính minh bạch, Sự thanh traSự thích nghi. Có thể nói, đây là phần lõi cùng với lí thuyết quản lí thực nghiệm tạo nên phần hồn của Scrum, cùng với các vai trò, sự kiện, quy trình, tạo tác và các quy tắc tạo nên khung xương cho Scrum. Thiếu ba chân này Scrum không thể hoạt động. Mọi thiết kế, quy tắc, hoạt động của Nhóm Scrum về cơ bản là xoay quanh ba trụ cột đó. Chúng ta thử đi sâu phân tích kĩ các giá trị cốt lõi này để thấy được động lực cho sự thành công của một nhóm nằm ở đâu. Từ các phân tích này, ta cũng có thể rút ra được một số ý tưởng cho các lĩnh vực khác ngoài ngành phát triển phần mềm, nơi Scrum vẫn có giá trị thực hành và phát huy tính hiệu quả.

do-hinh-scrum

Nói chung, khung làm việc Scrum yêu cầu thông tin (vấn đề, giải pháp, sáng kiến) được minh bạchthông suốt cho toàn bộ nhóm (hoặc cao hơn là mức độ tổ chức), nhằm mang lại khả năng ra quyết định tối ưu nhất để hoàn thành công việc, đạt hiệu quả cao nhất. Trong quá trình phát triển sản phẩm, Scrum luôn đảm bảo nhóm phát triển tích cực tìm kiếm thông tin (vấn đề, giải pháp, ý tưởng…) thông qua cơ chế Thanh tra đều đặn và liên tục (trong Scrum Hằng ngày, Sơ kết Sprint, hay họp Cải tiến Sprint); từ đó mở đường cho các chiến lược và hành động Thích nghi, nhằm thích ứng với các thay đổi (nội bộ hoặc từ bên ngoài), đạt năng suất tối ưu, mang lại lợi ích tối đa.

Minh bạch (Transparency)

Scrum giả định rằng một tổ chức hiệu quả và phát triển bền vững cần phải minh bạch. Tài chính minh bạch, công việc minh bạch, quy trình minh bạch, đánh giá minh bạch, chiến lược minh bạch, hiệu quả minh bạch, vấn đề cũng phải được minh bạch. Thiếu minh bạch, tổ chức dễ rơi vào tình huống rủi ro, ít khả năng thích ứng thiếu thông tin để ra quyết định chính xác. Thiếu minh bạch, tổ chức có thể bị phụ thuộc vào một vài cá nhân hoặc nhóm lợi ích, khó phát triển bền vững và trường tồn .
Minh bạch thường phải kèm thông suốt (thực ra hai từ này mang đủ nội hàm của chữ Transparency – chữ gốc của Scrum). Vì thiếu thông suốt, giá trị của minh bạch bị giảm xuống. Thông suốt tức là mọi người đều nắm được, từ cấp cao đến cấp thấp, từ phòng ban nọ tới phòng ban kia; khi có mục tiêu, mọi người đều hiểu nó là cái gì, theo cùng một cách thống nhất.

Vì nhiều lí do, thông tin cần thiết có thể đang ẩn nấp dưới rất nhiều dạng  thức (các nghiên cứu thị trường, hiệu suất của đối thủ cạnh tranh, thông tin về khách hàng, trạng thái sản xuất…) và cũng nằm ở rất nhiều ngóc ngách của tổ chức (ở người nào đó có hiểu biết, ở mối quan hệ với ai đó, ở nghiên cứu của nhóm nào đó, hoặc ở một tài liệu đúc rút kinh nghiệm của những người tiền nhiệm …). Các thông tin này được minh bạch sẽ tạo cơ hội cho “trí tuệ tập thể” phát huy tác dụng.

Thông thường ở một tổ chức kinh doanh, yếu tố tài chính thường được kiểm soát chặt chẽ nhất và dường như có xu hướng minh bạch nhất. Còn các yếu tố khác có thể không được như vậy. Điều đó có thể ảnh hưởng đến hiệu quả chung. Một số ví dụ có thể kể đến như: quy trình được mô tả chi tiết, nhưng việc thực hiện quy trình đến đâu lại có thể không được đánh giá; hệ thống có KPI nhưng các hoạt động ít khi bám KPI, dẫn đến đây chỉ là các “chỉ báo chết” và không có giá trị trong thực tiễn hoạt động, v.v.

Thanh tra (Inspection)

Không có thanh tra, không thể có minh bạch. QA ra đời là để đảm bảo công tác thanh tra về quy trình và các chỉ số. Nhưng thế thôi chưa đủ. Thanh tra cần được hiểu rộng hơn thế. Thanh tra là công tác cần phải được thực hiện bởi chính người tác nghiệp chứ không phải bởi bên thứ ba. Nhân viên QA thường không mấy khi biết vấn đề là gì, ít khi có tác động trực tiếp và có thể tạo ra động lực cho nhân viên (vì đấy cũng không phải là nhiệm vụ của QA). Trong khi nếu như công tác thanh tra được đẩy cho người làm việc thực hiện, tức tự thanh tra, thì sẽ tạo thói quen truy tìm vấn đề, tích cực thúc đẩy tiến trình công việc, và đặc biệt là đảm bảo chất lượng tự thân trong hoạt động của mình. Trong tiêu chuẩn ISO có mô tả một chức danh Giám đốc chất lượng (QMR), là người thay thế lãnh đạo, chịu trách nhiệm về tất cả các vấn đề về chất lượng của công ty. Thường đây là người không đứng dưới các “giám đốc” khác, để có thể có “tiếng nói” khi phát hiện vấn đề. ISO cho đây là người rất quan trọng trong việc đảm bảo một hệ thống quản trị chất lượng hiệu quả. Tuy Scrum không định nghĩa rõ những vai trò như thế, nhưng vẫn đảm bảo những yêu cầu công việc của QA, QMR được thực hiện với các kĩ thuật thanh tra đặc thù.

Việc thanh tra có thể được thực hiện nhẹ nhàng trong các buổi họp của nhóm. Ở đó, thông tin, vấn đề được mang ra mổ xẻ, phân tích và tìm kiếm giải pháp. Các đơn vị tham gia quy trình nghiệp vụ hoàn toàn bình đẳng trong cộng tác, đều có trách nhiệm báo cáo và giải trình cho nhau để đảm bảo thúc đẩy sự cộng tác đạt kết quả tối ưu. Sẽ không có cơ hội  để người làm kém (dù là lãnh đạo hay nhân viên quèn) lấp liếm các thất bại,  ảnh hưởng tới hiệu quả chung.

Thanh tra cần phải liên tục. Không có cơ chế thanh tra liên tục, thì ít khi các vấn đề được phát lộ, hoặc khi phát hiện ra vấn đề thì nó dễ dàng bị rơi vào cảnh “để lâu hóa bùn”, vì không có cơ chế gì đảm bảo vấn đề đó phải được giải quyết triệt để, có phản hồi rõ ràng và kết quả phải tới được các nơi cần biết. Cho nên, trong Scrum, việc thanh tra được thực hiện ở những sự kiện với tần suất dày đặc, phù hợp với yêu cầu thực tiễn: Scrum Hằng ngày để thanh ra tiến độ và vấn đề, thực hiện hằng ngày; Sơ kết Sprint để thanh tra tiến độ và chất lượng sản phẩm; Cải tiến Sprint để thanh tra về cách làm việc và đề xuất phương án cải tiến cùng với kế hoạch hành động; Cơ chế Định nghĩa Hoàn thành hoặc áp dụng “Điều kiện tiếp nhận” để giúp mỗi một người tự thanh tra chất lượng công việc của mình, được cá nhân thực hiện hằng ngày.

Thanh tra phải liên tục và đều đặn, và phải bám đuổi tích cực. Việc hôm trước phát hiện có sai sót, hôm nay đã giải quyết chưa? Nếu không có sự bám đuổi ấy, thanh tra chỉ là trò hề. Chỉ là làm vì cho có quy trình. Khi đó, quy trình cũng không có, sự cải tiến càng là thứ xa xỉ.

Khi thanh tra không kết hợp với minh bạch thì kết luận thanh tra cũng không giúp gì cho tổ chức cả. Vấn đề được phát hiện mà mọi người (đặc biệt là người có trách nhiệm) không biết, hoặc không ai đứng ra giải quyết thì việc thanh tra cũng chỉ phí thì giờ, hao tâm tổn sức.

Thích nghi (Adaptation)

Trên cơ sở thông tin đầy đủ và minh bạch, ta sẽ huy động được “sức mạnh của toàn dân”. Phương án thích nghi sẽ đi “từ dưới lên”, “từ trên xuống”, “từ bên cạnh” – rất hiệu quả, và bền vững. Trên cơ sở minh bạch thông tin, việc ra quyết định sẽ có chất lượng hơn; nhờ minh bạch về “vấn đề”, tổ chức biết được “chỗ ngứa” để “gãi”; nhờ minh bạch về “năng lực” và “best practice”, tổ chức biết mình phải phát huy cái gì, có lợi thế cạnh tranh gì; v.v. Với đặc điểm làm việc nhóm theo lối tự tổ chức (self-organizing), thì một nhóm không có khả năng thích nghi là một nhóm chưa trưởng thành.

Thích nghi giống như “tiền đạo” trong đội bóng “Ba trụ cột”. Không ghi bàn thì dù đội bóng có đá hay cũng chưa thể ăn mừng. Để có được sự hiệu quả và tiến bộ, nhất thiết phải có hành động thích nghi tốt.

Trong khi Khung làm việc Scrum giúp cho nhóm có thể đảm bảo thông tin minh bạch, thanh tra tốt (qua các công cụ, sự kiện và các quy tắc được thiết kế rất hiệu quả) thì yếu tố thích nghi đòi hỏi nhóm phải tự mình ra quyết định. Đây là yếu tố liên quan nhiều nhất đến yếu tố con người trong ba chân của Scrum. Scrum có thể giúp ta phát lộ rất nhiều lỗ hổng trong hệ thống, rất nhiều vấn đề trong tổ chức; nhưng phải có (những) ai đó (đủ năng lực) có khả năng đứng ra giải quyết vấn đề đó. Nếu không, tổ chức của ta sẽ chẳng đi đến đâu cả.

Nói chung, nhiều người nhận xét là nếu bỏ chữ Scrum đi, thì cái gọi là “ba trụ cột của Scrum” có thể quan trọng và nhu cầu cấp thiết với bất kì doanh nghiệp tổ chức nào. Nhưng Scrum còn đi xa hơn thế khi được thiết kế với những biện pháp thực hành tương đối cụ thể để đảm bảo các trụ cột đó được thực thi và phát huy hiệu quả. Chúng ta hoàn toàn có thể trích ra từ đó các ý tưởng để có thể thúc đẩy các yếu tố minh bạch thông tin, thanh tra  và thích nghi ở các loại hình công việc khác, không chỉ phát triển phần mềm.

Planning Poker

planning-pokerPlanning Poker là một kĩ thuật rất hiệu quả được sử dụng phổ biến để thực hiện ước tính trong Agile. Planning Poker kết hợp cả ba cách thức ước tính là dựa trên ý kiến chuyên gia, so sánh tương đối và chia nhỏ các hạng mục. Việc ước tính sử dụng Planning Poker khá nhanh chóng và mang lại kết quả đáng tin cậy. Nhóm Scrum có thể sử dụng Planning Poker để ước tính các hạng mục Product Backlog (Agile Estimation – Ước tính linh hoạt) hoặc các hạng mục công việc trong Sprint Backlog.

Để thực hiện kĩ thuật này, cần phải chuẩn bị các bộ bài Planning Poker đủ cho tất cả các thành viên tham dự. Bộ bài Planning Poker có nhiều kiểu khác nhau, tuy nhiên thông thường thì một bộ poker này chứa các quân bài thuộc dãy số: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Đây chính là dãy số Fibonacci đã được điều chỉnh một chút để phù hợp với việc ước tính. Dãy số này thể hiện các giá trị ước tính, không phụ thuộc vào đơn vị ước tính. Do đó, kĩ thuật này có thể sử dụng để ước tính với các đơn vị khác nhau, chẳng hạn là điểm tương đối hoặc giờ lý tưởng. Các nhóm có thể tự thiết kế bài cho mình hoặc là mua các loại có sẵn trên thị trường.

(Trích sách Cẩm nang Scrum cho người mới bắt đầu)

Bài đọc thêm: Ước tính linh hoạt với planning poker

Biểu đồ Sprint Burndown

Biểu đồ Sprint Burndown thể hiện các ước tính cập nhật hàng ngày về khối lượng công việc còn lại tới khi hoàn thành. Biểu đồ Sprint Burndown lấy dữ liệu ước tính từ Sprint Backlog.

Ví dụ với bảng công việc như Hình 1 thì ta có Biểu đồ Sprint Burndown như Hình 2.
Cập nhật Sprint Backlog

Hình 1. Bảng công việc

 

Biểu đồ sprint burndown

Hình 2. Biểu đồ sprint Burndown

Biểu đồ Sprint Burndown giúp nhóm biết được trạng thái công việc hiện tại. Nếu xu hướng công việc đang tiến triển đang chậm hơn so với kỳ vọng, một dự báo rằng Sprint này có thể không thể hoàn thành hết công việc, như vậy Nhóm nên tập trung hoàn thành những nội dung quan trọng nhất để đạt mục tiêu Sprint và thậm chí làm việc với PO. Cũng trong trường hợp chậm này, Nhóm cũng nhìn thấy rằng mình đang gặp một số trở ngại để tiến tới mục tiêu Sprint. Lúc này Nhóm có thể cùng thanh tra để tìm ra nguyên nhân của những trở ngại và hành động thích nghi phù hợp.

Tuy nhiên, biểu đồ này chỉ thể hiện một ước lượng, do đó Nhóm không nên quá tin tưởng vào biểu đồ mà nên liên tục thanh tra và thích nghi dựa vào những công việc thực tế khác.