SCRUM GUIDE 2020 SCRUM GUIDE 2020 KEN SCHWABER

SCRUM GUIDE 2020 SCRUM GUIDE 2020 KEN SCHWABER & JEFF SUTHERLAND SCRUM GUIDE 2020 M ụ c đích c ủ a Scrum Guide 2 Đ ị nh nghĩa Scrum 2 Lý thuy ế t Scrum 3 Transparency (Minh b ạ ch) 3 Inspection (Ki ể m tra) 3 Adaptation (Thích ứ ng) 3 Giá tr ị Scrum 3 Nhóm Scrum 4 Developers 4 Product Owner 4 Scrum Master 5 S ự ki ệ n Scrum 5 Sprint 6 Sprint Planning 6 Daily Scrum 7 Sprint Review 7 Sprint Retrospective 8 Scrum Artifacts 8 Product Backlog 8 Cam k ế t: M ụ c tiêu S ả n ph ẩ m 9 Sp rint Backlog 9 Cam k ế t: M ụ c tiêu Sprint 9 Increment 9 Cam k ế t: Đ ị nh nghĩa Hoàn thành 9 L ị ch s ử Scrum Guide 10 SCRUM GUIDE 2020 M ụ c đích c ủ a Scrum Guide Chúng tôi đã phát tri ể n Scrum vào đ ầ u nh ữ ng năm 1990 Chúng tôi đã vi ế t phiên b ả n đ ầ u tiên c ủ a Scrum Guide vào năm 2010 đ ể giúp m ọ i ngư ờ i trên toàn th ế gi ớ i hi ể u v ề Scru m Chúng tôi đã phát tri ể n Scrum Guide k ể t ừ đó thông qua các b ả n c ậ p nh ậ t nh ỏ Cùng nhau, chúng tôi đ ứ ng đ ằ ng sau nó (Ken Schwaber và Jeff Sutherland) Scrum Guide nêu đ ị nh nghĩa v ề Scrum M ỗ i y ế u t ố c ủ a khuôn kh ổ ph ụ c v ụ m ộ t m ụ c đích c ụ th ể c ầ n thi ế t cho giá tr ị t ổ ng th ể và k ế t qu ả đ ạ t đư ợ c v ớ i Scrum Vi ệ c thay đ ổ i thi ế t k ế ho ặ c ý tư ở ng c ố t lõi c ủ a Scrum, lo ạ i b ỏ các y ế u t ố ho ặ c không tuân theo các quy t ắ c c ủ a Scrum, s ẽ che đ ậ y các v ấ n đ ề và h ạ n ch ế l ợ i ích c ủ a Scrum, th ậ m chí có th ể khi ế n nó tr ở nên vô d ụ ng Chúng tôi theo dõi vi ệ c s ử d ụ ng Scrum ngày càng tăng trong m ộ t th ế gi ớ i ph ứ c t ạ p ngày càng phát tri ể n Chúng tôi r ấ t vui khi th ấ y Scrum đư ợ c áp d ụ ng trong nhi ề u lĩnh v ự c có công vi ệ c ph ứ c t ạ p v ề cơ b ả n, ngoài lĩnh v ự c phát tri ể n s ả n ph ẩ m ph ầ n m ề m v ố n là ngu ồ n g ố c c ủ a Scrum Đi cùng v ớ i vi ệ c áp d ụ ng Scrum r ộ ng rãi là lúc các nhà phát tri ể n, nhà nghiên c ứ u, nhà phân tích, nhà khoa h ọ c và các chuyên gia khác th ự c hi ệ n công vi ệ c Chúng tôi s ử d ụ ng t ừ “nhà phát tri ể n” trong Scrum không ph ả i đ ể lo ạ i tr ừ mà đ ể đơn gi ả n hóa N ế u b ạ n nh ậ n đư ợ c giá tr ị t ừ Scrum, hãy coi như b ạ n đư ợ c k ể là “nhà phát tri ể n” Khi Scrum đang đư ợ c s ử d ụ ng, các hình m ẫ u, quy trình và thông tin chi ti ế t phù h ợ p v ớ i khuôn kh ổ Scrum như đư ợ c mô t ả trong tài li ệ u này, có th ể đư ợ c tìm th ấ y, đư ợ c áp d ụ ng và phát minh l ạ i Mô t ả chúng (các hình m ẫ u, quy trình và thông tin chi ti ế t) n ằ m ngoài m ụ c đích c ủ a Scrum Guide vì chúng nh ạ y c ả m v ớ i ng ữ c ả nh và khác nhau nhi ề u gi ữ a các cách s ử d ụ ng Scrum Các chi ế n thu ậ t đ ể s ử d ụ ng trong khuôn kh ổ Scrum r ấ t khác nhau và đư ợ c mô t ả ở nh ữ ng tài li ệ u khác Đ ị nh nghĩa Scrum Scrum là m ộ t khuôn kh ổ h ạ ng nh ẹ giúp m ọ i ngư ờ i, các nhóm và t ổ ch ứ c t ạ o ra giá tr ị thông qua các gi ả i pháp linh ho ạ t thích ứ ng cho các v ấ n đ ề ph ứ c t ạ p Nói ng ắ n g ọ n , Scrum yêu c ầ u Scrum Mas ter ph ả i thúc đ ẩ y m ộ t môi trư ờ ng mà ở đó :  Product Owner ( Ch ủ s ở h ữ u s ả n ph ẩ m ) s ắ p x ế p th ứ t ự các công vi ệ c cho m ộ t v ấ n đ ề ph ứ c t ạ p thành m ộ t Product Backlog  Scrum team ( Nhóm Scrum ) bi ế n m ộ t t ậ p h ợ p công vi ệ c thành m ộ t Ph ầ n s ả n ph ẩ m gia tăng giá tr ị sau m ỗ i Sprint  Nhóm Scrum và các bên liên quan ki ể m tra k ế t qu ả và đi ề u ch ỉ nh cho Sprint ti ế p theo  L ặ p l ạ i quá trình nói trên Scrum r ấ t đơn gi ả n Hãy th ử nguyên tr ạ ng và xác đ ị nh xem tri ế t lý, lý thuy ế t và c ấ u trúc c ủ a nó có giúp đ ạ t đư ợ c m ụ c tiêu và t ạ o ra gi á tr ị hay không Khuôn kh ổ Scrum có ch ủ ý không hoàn ch ỉ nh, ch ỉ xác đ ị nh các ph ầ n c ầ n thi ế t đ ể tri ể n khai lý thuy ế t Scrum Scrum đư ợ c xây d ự ng d ự a trên trí tu ệ t ậ p th ể c ủ a nh ữ ng ngư ờ i s ử d ụ ng nó Thay vì cung c ấ p cho m ọ i ngư ờ i nh ữ ng hư ớ ng d ẫ n chi ti ế t, các quy t ắ c c ủ a Scrum hư ớ ng d ẫ n các m ố i quan h ệ và tương tác c ủ a h ọ Các quy trình, k ỹ thu ậ t và phương pháp khác nhau có th ể đư ợ c s ử d ụ ng trong khuôn kh ổ này Scrum bao g ồ m các th ự c hành hi ệ n có ho ặ c có th ể làm cho các th ự c hành đó không còn c ầ n thi ế t Scrum cho th ấ y hi ệ u qu ả tương đ ố i c ủ a các k ỹ thu ậ t qu ả n lý, môi trư ờ ng và công vi ệ c hi ệ n t ạ i, đ ể có th ể th ự c hi ệ n các c ả i ti ế n Lý thuy ế t Scrum Scrum đư ợ c thành l ậ p d ự a trên ch ủ nghĩa kinh nghi ệ m và tư duy tinh g ọ n Ch ủ nghĩa kinh nghi ệ m kh ẳ ng đ ị nh r ằ ng ki ế n t h ứ c đ ế n t ừ kinh nghi ệ m và đưa ra quy ế t đ ị nh d ự a trên nh ữ ng gì quan sát đư ợ c Tư duy tinh g ọ n gi ả m lãng phí và t ậ p trung vào nh ữ ng đi ề u c ầ n thi ế t Scrum s ử d ụ ng cách ti ế p c ậ n l ặ p đi l ặ p l ạ i, gia tăng đ ể t ố i ưu hóa kh ả năng d ự đoán và ki ể m soát r ủ i ro Scrum thu hút s ự tham gia c ủ a các nhóm ngư ờ i có t ấ t c ả các k ỹ năng và chuyên môn đ ể th ự c hi ệ n công vi ệ c và chia s ẻ ho ặ c h ọ c h ỏ i nh ữ ng k ỹ năng đó n ế u c ầ n Scrum k ế t h ợ p b ố n s ự ki ệ n chính th ứ c đ ể ki ể m tra và đi ề u ch ỉ nh trong m ộ t s ự ki ệ n bao trùm chung là Sprint Các s ự ki ệ n này ho ạ t đ ộ ng vì chúng th ự c hi ệ n các tr ụ c ộ t Scrum theo ch ủ nghĩa kinh nghi ệ m v ề tính minh b ạ ch, ki ể m tra và thích ứ ng Transparency ( Minh b ạ ch ) Quá trình và công vi ệ c n ổ i lên ph ả i đư ợ c hi ể n th ị rõ ràng cho nh ữ ng ngư ờ i th ự c hi ệ n công vi ệ c cũng như nh ữ ng ngư ờ i nh ậ n công vi ệ c V ớ i Scrum, các quy ế t đ ị nh quan tr ọ ng d ự a trên tr ạ ng thái nh ậ n th ứ c c ủ a ba s ả n ph ẩ m (artifact) chính th ứ c c ủ a nó Các s ả n ph ẩ m có tính minh b ạ ch th ấ p có th ể d ẫ n đ ế n các quy ế t đ ị nh làm gi ả m giá tr ị và tăng r ủ i ro Tính minh b ạ ch cho phép ki ể m tra Ki ể m tra mà không minh b ạ ch s ẽ là l ệ ch đư ờ ng và lãng phí Inspection ( Ki ể m tra ) Các v ậ t ph ẩ m c ủ a Scrum và ti ế n trình hư ớ ng t ớ i các m ụ c tiêu đã th ố ng nh ấ t ph ả i đư ợ c ki ể m tra thư ờ ng xuyên và c ầ n m ẫ n đ ể phát hi ệ n các v ấ n đ ề ho ặ c s ự sai l ệ ch không mong mu ố n Đ ể giúp ki ể m tra, Scrum cung c ấ p l ị ch ho ạ t đ ộ ng dư ớ i d ạ ng năm s ự ki ệ n c ủ a nó Ki ể m tra cho phép thích ứ ng Vi ệ c ki ể m tra mà không thích ứ ng đư ợ c coi là vô nghĩa Các s ự ki ệ n Scrum đư ợ c thi ế t k ế đ ể kích thích s ự thay đ ổ i Adaptation (T hích ứ ng ) N ế u b ấ t k ỳ khía c ạ nh nào c ủ a quá trình l ệ ch ra ngoài gi ớ i h ạ n cho phép ho ặ c n ế u s ả n ph ẩ m t ạ o thành không đư ợ c ch ấ p nh ậ n , thì quá trình đang đư ợ c áp d ụ ng ho ặ c nguyên li ệ u đư ợ c s ả n xu ấ t ph ả i đư ợ c đi ề u ch ỉ nh Vi ệ c đi ề u ch ỉ nh ph ả i đư ợ c th ự c hi ệ n càng s ớ m càng t ố t đ ể gi ả m thi ể u sai l ệ ch hơn n ữ a Vi ệ c thích ứ ng tr ở nên khó khăn hơn khi nh ữ ng ngư ờ i liên quan không đư ợ c trao quy ề n ho ặ c không t ự qu ả n lý Nhóm Scrum đư ợ c k ỳ v ọ ng s ẽ thích ứ ng ngay khi h ọ c đư ợ c b ấ t k ỳ đi ề u gì m ớ i thông qua ki ể m tra Giá tr ị S crum Vi ệ c s ử d ụ ng thành công Scrum ph ụ thu ộ c vào vi ệ c m ọ i ngư ờ i tr ở nên thành th ạ o hơn trong vi ệ c s ố ng v ớ i năm giá tr ị : Cam k ế t, T ậ p trung, C ở i m ở , Tôn tr ọ ng và Dũng c ả m ( Commitment, Focus, Openness, Respect, Courage ) Nhóm Scrum cam k ế t đ ạ t đư ợ c các m ụ c ti êu c ủ a mình và h ỗ tr ợ l ẫ n nhau Tr ọ ng tâm chính c ủ a h ọ là vào công vi ệ c c ủ a Sprint đ ể đ ạ t đư ợ c ti ế n đ ộ t ố t nh ấ t có th ể đ ố i v ớ i các m ụ c tiêu này Nhóm Scrum và các bên liên quan c ở i m ở v ề công vi ệ c và nh ữ ng thách th ứ c Các thành viên Nhóm Scrum tôn tr ọ ng l ẫ n nhau đ ể tr ở thành nh ữ ng ngư ờ i có năng l ự c, đ ộ c l ậ p và đư ợ c nh ữ ng ngư ờ i cùng làm vi ệ c tôn tr ọ ng Các thành viên Nhóm Scrum có can đ ả m đ ể làm đi ề u đúng đ ắ n, và gi ả i quy ế t nh ữ ng v ấ n đ ề khó khăn Nh ữ ng giá tr ị này cung c ấ p đ ị nh hư ớ ng cho Nhóm Scrum liên quan đ ế n công vi ệ c, hành đ ộ ng và hành vi c ủ a h ọ Các quy ế t đ ị nh đư ợ c đưa ra, các bư ớ c đã th ự c hi ệ n và cách s ử d ụ ng Scrum ph ả i c ủ ng c ố nh ữ ng giá tr ị này, không làm gi ả m ho ặ c làm suy y ế u chúng Các thành viên Nhóm Scrum tìm hi ể u và khám phá các giá tr ị khi h ọ là m vi ệ c v ớ i các s ự ki ệ n và v ậ t ph ẩ m c ủ a Scrum Khi nh ữ ng giá tr ị này đư ợ c th ể hi ệ n b ở i Nhóm Scrum và nh ữ ng ngư ờ i mà h ọ làm vi ệ c cùng, các tr ụ c ộ t kinh nghi ệ m c ủ a Scrum v ề tính M inh b ạ ch, K i ể m tra và T hích ứ ng s ẽ tr ở thành ni ề m tin xây d ự ng cu ộ c s ố ng Nhóm S crum Đơn v ị cơ b ả n c ủ a Scrum là m ộ t nhóm nh ỏ các thành viên g ọ i là Nhóm Scrum Nhóm Scrum bao g ồ m m ộ t Scrum Master, m ộ t Product Owner và các Nhà phát tri ể n Trong Nhóm Scrum, không có nhóm con ho ặ c h ệ th ố ng phân c ấ p Nhóm Scrum là m ộ t t ổ ch ứ c g ắ n k ế t c ủ a c ác chuyên gia t ậ p trung vào m ộ t m ụ c tiêu t ạ i m ộ t th ờ i đi ể m g ọ i là M ụ c tiêu S ả n ph ẩ m Các thành viên n hóm Scrum có kh ả năng hoán đ ổ i nghi ệ p v ụ (cross - functional) , nghĩa là các thành viên có t ấ t c ả các k ỹ năng c ầ n thi ế t đ ể t ạ o ra giá tr ị cho m ỗ i Sprint H ọ cũng có năng l ự c t ự qu ả n lý, nghĩa là h ọ t ự quy ế t đ ị nh ai làm gì, khi nào và làm như th ế nào Nhóm Scrum đ ủ nh ỏ đ ể luôn linh ho ạ t và đ ủ l ớ n đ ể hoàn thành công vi ệ c quan tr ọ ng trong m ộ t Sprint, và thư ờ ng là có 10 ngư ờ i tr ở xu ố ng Nói chung, chúng tôi nh ậ n t h ấ y các nhóm nh ỏ giao ti ế p t ố t hơn và làm vi ệ c hi ệ u qu ả hơn N ế u các n hóm Scrum tr ở nên quá l ớ n, nên xem xét t ổ ch ứ c l ạ i thành nhi ề u n hóm Scrum có s ự g ắ n k ế t v ớ i nhau , m ỗ i nhóm t ậ p trung vào cùng m ộ t s ả n ph ẩ m Do đó, các nhóm này nên chia s ẻ cùng m ộ t M ụ c t iêu S ả n ph ẩ m, m ộ t Product Backlog và m ộ t Product Owner Nhóm Scrum ch ị u trách nhi ệ m v ề t ấ t c ả các ho ạ t đ ộ ng liên quan đ ế n s ả n ph ẩ m : g ồ m vi ệ c h ợ p tác v ớ i các bên liên quan, ki ể m tra , b ả o trì, v ậ n hành, th ử nghi ệ m, nghiên c ứ u và phát tri ể n và b ấ t k ỳ ho ạ t đ ộ n g nào khác có th ể đư ợ c yêu c ầ u H ọ đư ợ c t ổ ch ứ c và trao quy ề n đ ể qu ả n lý công vi ệ c c ủ a chính h ọ Làm vi ệ c thông qua các Sprint v ớ i m ộ t nh ị p đ ộ b ề n v ữ ng giúp c ả i thi ệ n s ự t ậ p trung và nh ấ t quán c ủ a Nhóm Scrum Toàn b ộ Nhóm Scrum ph ả i ch ị u trách nhi ệ m v ề vi ệ c t ạ o ra Ph ầ n s ả n ph ẩ m gia tăng h ữ u ích và có giá tr ị sau m ỗ i Sprint Scrum xác đ ị nh ba vai trò trách nhi ệ m c ụ th ể trong m ộ t Nhóm Scrum: Developer s , Product Owner và Scrum Master Developers Các nhà phát tri ể n là nh ữ ng ngư ờ i trong Nhóm Scrum cam k ế t t ạ o ra m ọ i khía c ạ nh c ủ a m ộ t Ph ầ n s ả n ph ẩ m gia tăng có th ể s ử d ụ ng đư ợ c sau m ỗ i Sprint Các k ỹ năng c ụ th ể mà Nhà phát tri ể n c ầ n có thư ờ ng r ấ t r ộ ng và s ẽ thay đ ổ i theo lĩnh v ự c công vi ệ c Tuy nhiên, các Nhà phát tri ể n luôn ph ả i ch ị u trách nh i ệ m v ề :  L ậ p k ế ho ạ ch cho Sprint, Sprint Backlog;  Nâng cao ch ấ t lư ợ ng b ằ ng cách tuân th ủ Đ ị nh nghĩa Hoàn thành;  Đi ề u ch ỉ nh k ế ho ạ ch c ủ a h ọ h ằ ng ngày sao cho đ ạ t đư ợ c M ụ c tiêu c ủ a Sprint; và  Ch ị u trách nhi ệ m v ớ i nhau v ớ i tư cách là nh ữ ng ngư ờ i chuyên nghi ệ p Product Owner Product Owner có trách nhi ệ m t ố i đa hóa giá tr ị c ủ a s ả n ph ẩ m t ạ o ra b ở i công vi ệ c c ủ a Nhóm Scrum Cách th ự c hi ệ n đi ề u này có th ể r ấ t khác nhau gi ữ a các t ổ ch ứ c, Nhóm Scrum và cá nhân Product Owner Product Owner cũng ch ị u trách nhi ệ m v ề vi ệ c qu ả n lý Product Backlog hi ệ u qu ả , bao g ồ m:  Phát tri ể n và truy ề n đ ạ t rõ ràng M ụ c tiêu S ả n ph ẩ m;  T ạ o ra và truy ề n đ ạ t rõ ràng các h ạ ng m ụ c Product Backlog;  S ắ p x ế p th ứ t ự ưu tiên các h ạ ng m ụ c Product Backlog; và,  Đ ả m b ả o r ằ ng Product Backlog là minh b ạ ch, d ễ th ấ y và d ễ hi ể u Product Owner có th ể t ự th ự c hi ệ n công vi ệ c nói trên ho ặ c có th ể giao phó cho ngư ờ i khác B ấ t k ể cách nào , Product Owner v ẫ n ph ả i là ngư ờ i ch ị u trách nhi ệ m Đ ể cho các Product Owner thành công, toàn b ộ t ổ ch ứ c ph ả i tôn tr ọ ng quy ế t đ ị nh c ủ a h ọ Nh ữ ng quy ế t đ ị nh này đư ợ c hi ể n th ị trong n ộ i dung và th ứ t ự c ủ a Product Backlog, và thông qua Ph ầ n s ả n ph ẩ m gia tăng có th ể ki ể m tra đư ợ c trong bu ổ i Sprint Review Product Owner là m ộ t ngư ờ i, không ph ả i là m ộ t ủ y ban Product Owner có th ể đ ạ i di ệ n c ho nhu c ầ u c ủ a nhi ề u bên liên quan trong m ộ t Product Backlog Nh ữ ng ngư ờ i mu ố n thay đ ổ i Product Backlog có th ể th ự c hi ệ n s ự thay đ ổ i b ằ ng cách thuy ế t ph ụ c Product Owner Scrum Master Scrum Master có trách nhi ệ m thi ế t l ậ p Scrum như đư ợ c đ ị nh nghĩa trong Scr um Guide H ọ làm đi ề u này b ằ ng cách giúp m ọ i ngư ờ i hi ể u lý thuy ế t và th ự c hành Scrum, c ả trong Nhóm Scrum và t ổ ch ứ c Scrum Master ch ị u trách nhi ệ m v ề hi ệ u qu ả c ủ a Nhóm Scrum H ọ th ự c hi ệ n đi ề u này b ằ ng cách cho phép Nhóm Scrum c ả i thi ệ n các phương pháp th ự c hành c ủ a mình, trong khuôn kh ổ Scrum Scrum Master là nh ữ ng nhà lãnh đ ạ o th ự c s ự ph ụ c v ụ Nhóm Scrum và r ộ ng hơn là ph ụ c v ụ t ổ ch ứ c Scrum Master ph ụ c v ụ Nhóm Scrum theo m ộ t s ố cách, bao g ồ m:  Hu ấ n luy ệ n các thành viên trong nhóm v ề t ự qu ả n lý và hoán đ ổ i ch ứ c năng;  Giúp Nhóm Scrum t ậ p trung vào vi ệ c t ạ o ra các Ph ầ n s ả n ph ẩ m gia tăng có giá tr ị cao đáp ứ ng Đ ị nh nghĩa Hoàn thành;  G ây ra vi ệ c lo ạ i b ỏ các tr ở ng ạ i đ ố i v ớ i ti ế n trình công vi ệ c c ủ a Nhóm Scrum; và,  Đ ả m b ả o r ằ ng t ấ t c ả các s ự ki ệ n Scrum đư ợ c di ễ n ra m ộ t cách tích c ự c, có hi ệ u qu ả và gi ữ đư ợ c trong khung th ờ i gian c ố đ ị nh Scrum Master ph ụ c v ụ Product Owner theo m ộ t s ố cách, bao g ồ m:  Giúp tìm ra các k ỹ thu ậ t đ ể xác đ ị nh M ụ c tiêu S ả n ph ẩ m hi ệ u qu ả và qu ả n lý Product Backlog;  Giúp Nhóm Scrum hi ể u đư ợ c s ự c ầ n thi ế t c ủ a vi ệ c làm cho các h ạ ng m ụ c Product Backlog tr ở nên rõ ràng và ng ắ n g ọ n;  Giúp l ậ p k ế ho ạ ch s ả n ph ẩ m th ự c nghi ệ m cho m ộ t môi trư ờ ng ph ứ c t ạ p; và,  T ạ o đi ề u ki ệ n cho s ự h ợ p tác c ủ a các bên liên quan khi đư ợ c yêu c ầ u ho ặ c khi c ầ n thi ế t Scrum Master ph ụ c v ụ t ổ ch ứ c theo m ộ t s ố cách, bao g ồ m:  Lãnh đ ạ o, đào t ạ o và hu ấ n luy ệ n t ổ ch ứ c trong vi ệ c áp d ụ ng Scrum;  L ậ p k ế ho ạ ch và tư v ấ n tri ể n khai Scrum trong t ổ ch ứ c;  Giúp nhân viên và các bên liên quan hi ể u và đưa ra phương pháp ti ế p c ậ n th ự c nghi ệ m c ho các công vi ệ c ph ứ c t ạ p; và,  Lo ạ i b ỏ các rào c ả n gi ữ a các bên liên quan và Nhóm Scrum S ự ki ệ n Scrum Sprint là nơi ch ứ a t ấ t c ả các s ự ki ệ n khác M ỗ i s ự ki ệ n trong Scrum là m ộ t cơ h ộ i chính th ứ c đ ể ki ể m tra và đi ề u ch ỉ nh các v ậ t ph ẩ m Scrum Nh ữ ng s ự ki ệ n này đư ợ c thi ế t k ế đ ặ c bi ệ t đ ể t ạ o ra s ự minh b ạ ch c ầ n thi ế t N ế u k hông th ự c hi ệ n m ộ t s ự ki ệ n nào đó trong s ố nh ữ ng s ự ki ệ n đã ch ỉ d ẫ n s ẽ d ẫ n đ ế n h ậ u qu ả m ấ t cơ h ộ i đ ể ki ể m tra và thích ứ ng Các s ự ki ệ n trong Scrum nh ằ m t ạ o ra nh ị p đi ệ u công vi ệ c đ ề u đ ặ n và gi ả m thi ể u các cu ộ c h ọ p không đư ợ c qui đ ị nh trong Scrum M ộ t cách t ố i ưu, thì m ỗ i s ự ki ệ n Scrum nên đ ư ợ c t ổ ch ứ c t ạ i cùng m ộ t th ờ i đi ể m và đ ị a đi ể m đ ể gi ả m b ớ t s ự ph ứ c t ạ p Sprint Sprint là nh ị p tim c ủ a Scrum, nơi các ý tư ở ng đư ợ c bi ế n thành giá tr ị Chúng có đ ộ dài c ố đ ị nh t ừ m ộ t tháng tr ở xu ố ng đ ể t ạ o s ự nh ấ t quán M ộ t Sprint m ớ i b ắ t đ ầ u ngay sau khi k ế t thúc Sprint trư ớ c T ấ t c ả các công vi ệ c c ầ n thi ế t đ ể đ ạ t đư ợ c M ụ c tiêu S ả n ph ẩ m, bao g ồ m c ả các bu ổ i Sprint Planning, Daily Scrums, Sprint Rev iew, và Sprint Retrospective , đ ề u di ễ n ra trong Sprint Trong Sprint:  Không có thay đ ổ i nào đư ợ c th ự c hi ệ n mà có th ể làm ch ệ ch M ụ c tiêu Sprint;  Ch ấ t lư ợ ng không gi ả m;  Product Backlog đư ợ c tinh ch ỉ nh khi c ầ n thi ế t; và,  Ph ạ m vi có th ể đư ợ c làm rõ và thương l ư ợ ng l ạ i v ớ i Product Owner khi Nhóm h ọ c h ỏ i và bi ế t thêm nhi ề u hơn Các Sprint cho phép kh ả năng d ự đoán b ằ ng cách đ ả m b ả o ki ể m tra và đi ề u ch ỉ nh ti ế n đ ộ th ự c hi ệ n M ụ c tiêu s ả n ph ẩ m ít nh ấ t m ỗ i tháng m ộ t l ầ n Khi khung th ờ i gian c ủ a Sprint quá dài, M ụ c tiê u Sprint có th ể tr ở nên không h ợ p l ệ , đ ộ ph ứ c t ạ p và r ủ i ro có th ể tăng lên Các Sprint ng ắ n hơn có th ể đư ợ c s ử d ụ ng đ ể t ạ o ra nhi ề u chu k ỳ h ọ c t ậ p hơn và h ạ n ch ế r ủ i ro v ề chi phí và công s ứ c M ỗ i Sprint có th ể đư ợ c coi là m ộ t d ự án ng ắ n Có nhi ề u phương pháp th ự c hành khác nhau đ ể d ự báo ti ế n đ ộ , ch ẳ ng h ạ n như các bi ể u đ ồ burn - down, burn - up ho ặ c bi ể u đ ồ dòng ch ả y tích lũy (cumulative flow) M ặ c dù đã đư ợ c ch ứ ng minh là h ữ u ích, nhưng nh ữ ng phương pháp th ự c hành n ày không thay th ế đư ợ c t ầ m quan tr ọ ng c ủ a c h ủ nghĩa kinh nghi ệ m Trong môi trư ờ ng ph ứ c t ạ p, đi ề u s ẽ x ả y ra là không th ể bi ế t trư ớ c Ch ỉ nh ữ ng gì đã x ả y ra m ớ i có th ể đư ợ c s ử d ụ ng đ ể ra quy ế t đ ị nh trong tương lai M ộ t Sprint có th ể b ị h ủ y b ỏ n ế u M ụ c tiêu Sprint tr ở nên l ỗ i th ờ i Ch ỉ Product Owner m ớ i có quy ề n h ủ y Sprint Sprint P lanning L ậ p k ế ho ạ ch Sprint kh ở i đ ầ u Sprint b ằ ng cách s ắ p x ế p công vi ệ c c ầ n th ự c hi ệ n cho Sprint K ế ho ạ ch k ế t qu ả này đư ợ c t ạ o nên b ở i s ự c ộ ng tác c ủ a toàn b ộ Nhóm Scrum Product Owner đ ả m b ả o r ằ ng nh ữ ng ngư ờ i tham d ự đư ợ c c hu ẩ n b ị đ ể th ả o lu ậ n v ề các h ạ ng m ụ c Product Backlog quan tr ọ ng nh ấ t và cách chúng liên k ế t v ớ i M ụ c tiêu S ả n ph ẩ m Nhóm Scrum cũng có th ể m ờ i nh ữ ng ngư ờ i khác tham gia L ậ p k ế ho ạ ch Sprint đ ể nh ậ n đư ợ c l ờ i khuyên L ậ p k ế ho ạ ch Sprint gi ả i quy ế t các ch ủ đ ề s au: Ch ủ đ ề 1 : T ạ i sao Sprint này l ạ i có giá tr ị ? Product Owner đ ề xu ấ t cách s ả n ph ẩ m có th ể tăng giá tr ị và ti ệ n ích c ủ a nó trong Sprint hi ệ n t ạ i Sau đó, toàn b ộ Nhóm Scrum s ẽ c ộ ng tác đ ể xác đ ị nh M ụ c tiêu Sprint nh ằ m truy ề n đ ạ t lý do t ạ i sao Sprint l ạ i c ó giá tr ị đ ố i v ớ i các bên liên quan M ụ c tiêu Sprint ph ả i đư ợ c ch ố t l ạ i trư ớ c khi k ế t thúc bu ổ i L ậ p k ế ho ạ ch Sprint Ch ủ đ ề 2 : Công vi ệ c gì có th ể hoàn thành trong Sprint này? Thông qua th ả o lu ậ n v ớ i Product Owner, các Nhà phát tri ể n ch ọ n các h ạ ng m ụ c t ừ P roduct Backlog đ ể đưa vào Sprint hi ệ n t ạ i Nhóm Scrum có th ể tinh ch ỉ nh các m ụ c này trong quá trình ch ọ n này , nh ằ m tăng cư ờ ng s ự hi ể u bi ế t và s ự t ự tin Vi ệ c ch ọ n s ố lư ợ ng h ạ ng m ụ c có th ể hoàn thành trong m ộ t Sprint có th ể là m ộ t thách th ứ c Tuy nhiên, khi các Nhà phát tri ể n càng bi ế t nhi ề u v ề hi ệ u su ấ t làm vi ệ c trong quá kh ứ , năng l ự c s ắ p t ớ i và Đ ị nh nghĩa Hoàn thành c ủ a h ọ , thì h ọ càng tin tư ở ng vào các d ự báo Sprint c ủ a mình Ch ủ đ ề 3 : Công vi ệ c đã ch ọ n s ẽ đư ợ c hoàn thành b ằ ng cách nào? Đ ố i v ớ i m ỗ i h ạ ng m ụ c Product Backlog đã ch ọ n, các Nhà phát tri ể n l ậ p k ế ho ạ ch công vi ệ c c ầ n thi ế t đ ể t ạ o ra Ph ầ n s ả n ph ẩ m gia tăng đáp ứ ng Đ ị nh nghĩa Hoàn thành Đi ề u này thư ờ ng đư ợ c th ự c hi ệ n b ằ ng cách chia nh ỏ các h ạ ng m ụ c Product Backlog thành các m ụ c công vi ệ c nh ỏ hơn s ẽ đư ợ c làm trong m ộ t ngày ho ặ c ng ắ n hơn Vi ệ c này đư ợ c th ự c hi ệ n như th ế nào là do các Nhà phát tri ể n quy ế t đ ị nh Không ai khác ch ỉ cho h ọ cách bi ế n các h ạ ng m ụ c Product Backlog thành các Ph ầ n s ả n ph ẩ m gia tăng v ề giá tr ị M ụ c tiêu Sprint, các h ạ ng m ụ c Pr oduct Backlog đư ợ c ch ọ n cho Sprint, cùng v ớ i k ế ho ạ ch th ự c hi ệ n chúng đư ợ c g ọ i chung là Sprint Backlog L ậ p k ế ho ạ ch Sprint có khung th ờ i gian t ố i đa là tám gi ờ cho Sprint m ộ t tháng Đ ố i v ớ i Sprint ng ắ n hơn, s ự ki ệ n thư ờ ng ng ắ n hơn Daily Scrum M ụ c đích c ủ a Daily Scrum là ki ể m tra ti ế n đ ộ th ự c hi ệ n M ụ c tiêu Sprint và đi ề u ch ỉ nh Sprint Backlog khi c ầ n thi ế t, đi ề u ch ỉ nh k ế ho ạ ch công s ắ p t ớ i Daily Scrum là m ộ t s ự ki ệ n kéo dài 15 phút dành cho các Nhà phát tri ể n c ủ a Nhóm Scrum Đ ể gi ả m b ớ t s ự ph ứ c t ạ p, nó đư ợ c t ổ ch ứ c vào th ờ i gian c ố đ ị nh và di ễ n ra h ằ ng ngày trong Sprint N ế u Product Owner ho ặ c Scrum Master đang tích c ự c làm vi ệ c v ớ i các h ạ ng m ụ c trong Sprint Backlog, h ọ s ẽ tham gia v ớ i tư cách như là m ộ t Nhà phát tri ể n Các nhà phát tri ể n có th ể ch ọ n b ấ t k ỳ c ấ u trúc và k ỹ thu ậ t nào h ọ mu ố n, mi ễ n là Daily Scrum c ủ a h ọ t ậ p trung vào ti ế n đ ộ hư ớ ng t ớ i M ụ c tiêu Sprint và đưa ra m ộ t k ế ho ạ ch kh ả thi cho ngày làm vi ệ c ti ế p theo Đi ề u này t ạ o ra s ự t ậ p trung và c ả i thi ệ n kh ả năng t ự qu ả n lý Daily Scrums c ả i thi ệ n thông tin liên l ạ c, xác đ ị nh các tr ở ng ạ i, thúc đ ẩ y vi ệ c ra quy ế t đ ị nh nhanh chóng và do đó lo ạ i b ỏ nhu c ầ u v ề các cu ộ c h ọ p khác Daily Scrum không ph ả i là cơ h ộ i duy nh ấ t các Nhà phát tri ể n đư ợ c phép đi ề u ch ỉ nh k ế ho ạ ch c ủ a h ọ H ọ thư ờ ng g ặ p nhau su ố t c ả ngày đ ể th ả o lu ậ n chi ti ế t hơn v ề vi ệ c đi ề u ch ỉ nh ho ặ c l ậ p k ế ho ạ ch l ạ i ph ầ n vi ệ c còn l ạ i c ủ a Sprint Sprint Review M ụ c đích c ủ a Sprint Review là ki ể m tra k ế t qu ả công vi ệ c c ủ a Sprint và xác đ ị nh các s ự đi ề u ch ỉ nh trong tương lai Nhóm Scrum trình bày k ế t qu ả công vi ệ c c ủ a h ọ cho các bên liên quan chính và ti ế n trình hư ớ ng t ớ i M ụ c tiêu S ả n ph ẩ m s ẽ đư ợ c th ả o lu ậ n Trong s ự ki ệ n này, Nhóm Sc rum và các bên liên quan rà soát l ạ i nh ữ ng gì đã đ ạ t đư ợ c trong Sprint và nh ữ ng gì đã thay đ ổ i trong môi trư ờ ng c ủ a h ọ D ự a trên thông tin này, nh ữ ng ngư ờ i tham d ự cùng nhau xác đ ị nh nh ữ ng vi ệ c c ầ n làm ti ế p theo Product Backlog cũng có th ể đư ợ c đi ề u ch ỉ nh đ ể đáp ứ ng các cơ h ộ i m ớ i Sprint Review là m ộ t phiên làm vi ệ c và Nhóm Scrum nên tránh bi ế n nó thành m ộ t bu ổ i thuy ế t tr ình Sprint Review là s ự ki ệ n g ầ n sát cu ố i cùng c ủ a Sprint và có khung th ờ i gian t ố i đa là b ố n gi ờ cho Sprint có khung m ộ t tháng Đ ố i v ớ i Sprint ng ắ n hơn, s ự ki ệ n này thư ờ ng ng ắ n hơn Sprint Retrospective M ụ c đích c ủ a Sprint Retrospective là ho ạ ch đ ị nh bi ệ n pháp đ ể tăng ch ấ t lư ợ ng và hi ệ u qu ả Nhóm Scrum ki ể m tra xem Sprint đã di ễ n ra như th ế nào trên các khía c ạ nh các cá nhân, s ự tương tác, quy trình, công c ụ và Đ ị nh nghĩa Hoàn thành Các y ế u t ố đư ợ c ki ể m tra thư ờ ng thay đ ổ i theo lĩnh v ự c công vi ệ c Các gi ả đ ị nh khi ế n h ọ l ạ c l ố i c ầ n đư ợ c xác đ ị nh và tìm hi ể u ngu ồ n g ố c c ủ a chúng Nhóm Scrum th ả o lu ậ n v ề nh ữ ng gì di ễ n ra t ố t đ ẹ p trong Sprint, nh ữ ng v ấ n đ ề mà h ọ g ặ p ph ả i và cách nh ữ ng v ấ n đ ề đó đã đư ợ c gi ả i quy ế t (ho ặ c không đư ợ c gi ả i quy ế t ) Nhóm Scrum xác đ ị nh nh ữ ng thay đ ổ i h ữ u ích nh ấ t đ ể c ả i thi ệ n hi ệ u qu ả c ủ a nhóm Nh ữ ng c ả i ti ế n có ả nh hư ở ng nh ấ t nên đư ợ c th ự c hi ệ n càng s ớ m càng t ố t Chúng th ậ m chí có th ể đư ợ c đưa vào Sprint Backlog c ủ a Sprint ti ế p theo Sprint Retrospective là s ự ki ệ n cu ố i cùng c ủ a Spri nt Nó có khung th ờ i gian t ố i đa là ba gi ờ cho Sprint có khung m ộ t tháng Đ ố i v ớ i Sprint ng ắ n hơn, s ự ki ệ n thư ờ ng ng ắ n hơn Scrum Artifacts Các v ậ t ph ẩ m c ủ a Scrum đ ạ i di ệ n cho công vi ệ c ho ặ c giá tr ị Chúng đư ợ c thi ế t k ế đ ể t ăng cư ờ ng tính minh b ạ ch c ủ a các thông tin chính Vì v ậ y, t ấ t c ả m ọ i ngư ờ i ki ể m tra chúng đ ề u có cơ s ở như nhau đ ể thích ứ ng M ỗ i v ậ t ph ẩ m ch ứ a đ ự ng m ộ t s ự cam k ế t r ằ ng chúng cung c ấ p thông tin đ ể nâng cao tính minh b ạ ch và t ậ p trung vào cái đích mà theo đó ti ế n đ ộ th ự c hi ệ n đư ợ c đo lư ờ n g :  Đ ố i v ớ i Product Backlog, cam k ế t là M ụ c tiêu S ả n ph ẩ m  Đ ố i v ớ i Sprint Backlog, cam k ế t là M ụ c tiêu Sprint  Đ ố i v ớ i Ph ầ n s ả n ph ẩ m gia tăng, cam k ế t là Đ ị nh nghĩa Hoàn thành Nh ữ ng cam k ế t này t ồ n t ạ i đ ể c ủ ng c ố ch ủ nghĩa kinh nghi ệ m và các giá tr ị Scrum cho Nhóm Scrum và các bên liên quan c ủ a h ọ Product Backlog Product Backlog là m ộ t danh sách đư ợ c phát tri ể n d ầ n và có th ứ t ự v ề nh ữ ng th ứ c ầ n thi ế t đ ể c ả i thi ệ n s ả n ph ẩ m Đây là ngu ồ n duy nh ấ t các công vi ệ c mà Nhóm Scrum ph ả i th ự c hi ệ n Các h ạ ng m ụ c Produ ct Backlog mà có th ể đư ợ c Nhóm Scrum hoàn thành trong m ộ t Sprint đư ợ c coi là s ẵ n sàng đ ể đư ợ c l ự a ch ọ n trong s ự ki ệ n L ậ p k ế ho ạ ch Sprint Chúng thư ờ ng đ ạ t đư ợ c m ứ c đ ộ minh b ạ ch như v ậ y sau các ho ạ t đ ộ ng tinh ch ỉ nh (refinement) Tinh ch ỉ nh Product Backlog l à hành đ ộ ng chia nh ỏ và xác đ ị nh rõ hơn các h ạ ng m ụ c Product Backlog thành các m ụ c nh ỏ hơn và chính xác hơn Đây là m ộ t ho ạ t đ ộ ng liên t ụ c đ ể thêm các chi ti ế t, ch ẳ ng h ạ n như thêm mô t ả , s ắ p x ế p l ạ i th ứ t ự và ư ớ c lư ợ ng qui mô Các thu ộ c tính thư ờ ng thay đ ổ i theo lĩnh v ự c công vi ệ c Các nhà phát tri ể n, nh ữ ng ngư ờ i th ự c hi ệ n công vi ệ c , ch ị u trách nhi ệ m ư ớ c lư ợ ng qui mô công vi ệ c Product Owner có th ể ả nh hư ở ng đ ế n Nhà phát tri ể n b ằ ng cách giúp h ọ hi ể u và l ự a ch ọ n s ự cân b ằ ng Cam k ế t: M ụ c tiêu S ả n ph ẩ m M ụ c ti êu S ả n ph ẩ m mô t ả tr ạ ng thái tương lai c ủ a s ả n ph ẩ m đư ợ c dùng làm m ụ c tiêu đ ể Nhóm Scrum l ậ p k ế ho ạ ch th ự c hi ệ n M ụ c tiêu S ả n ph ẩ m n ằ m trong Product Backlog Nh ữ ng p h ầ n còn l ạ i c ủ a Product Backlog l ộ di ệ n d ầ n đ ể xác đ ị nh “cái gì” s ẽ hoàn thành M ụ c tiêu S ả n ph ẩ m S ả n ph ẩ m là phương ti ệ n đ ể cung c ấ p giá tr ị Nó có m ộ t ranh gi ớ i rõ ràng, có các bên liên quan đư ợ c bi ế t rõ , có ngư ờ i dùng ho ặ c khách hàng đư ợ c xác đ ị nh M ộ t s ả n ph ẩ m có th ể là m ộ t d ị ch v ụ , m ộ t s ả n ph ẩ m v ậ t lý ho ặ c m ộ t cái gì đó tr ừ u tư ợ ng hơn M ụ c tiêu S ả n ph ẩ m là m ụ c tiêu dài h ạ n c ủ a Nhóm Scrum H ọ ph ả i hoàn thành (ho ặ c t ừ b ỏ ) m ộ t m ụ c tiêu trư ớ c khi th ự c hi ệ n m ụ c tiêu ti ế p theo Sprint B acklog Sprint Backlog bao g ồ m M ụ c tiêu Sprint ( “Why” ), t ậ p h ợ p các h ạ ng m ụ c Product Backlog đư ợ c ch ọ n cho Sprint ( “What” ), và m ộ t k ế ho ạ ch hành đ ộ ng đ ể cung c ấ p Ph ầ n s ả n ph ẩ m gia tăng ( “How” ) Sprint Backlog là m ộ t k ế ho ạ ch dành cho các Nhà phát tri ể n Đó là m ộ t b ứ c tranh th ờ i gian th ự c, có th ể nhìn th ấ y rõ ràng v ề công vi ệ c mà các Nhà phát tri ể n d ự đ ị nh hoàn thành t rong Sprint đ ể đ ạ t đư ợ c M ụ c tiêu Sprint Do đó, Sprint Backlog đư ợ c c ậ p nh ậ t trong su ố t Sprint khi các nhà Phát tri ể n h ọ c đư ợ c nhi ề u đi ề u hơn Nó ph ả i có đ ủ chi ti ế t đ ể h ọ có th ể ki ể m tra ti ế n trình c ủ a mình trong Daily Scrum Cam k ế t: M ụ c tiêu Sprint M ụ c tiêu Sprint là m ụ c tiêu duy nh ấ t c ủ a Sprint M ặ c dù M ụ c tiêu Sprint là cam k ế t c ủ a Nhà phát tri ể n, nhưng nó cung c ấ p s ự linh ho ạ t v ề công vi ệ c c ụ th ể c ầ n th ự c hi ệ n đ ể đ ạ t đư ợ c nó M ụ c tiêu Sprint cũng t ạ o ra s ự g ắ n k ế t và t ậ p trung, khuy ế n khích Nhóm Scrum làm vi ệ c cùng nhau thay vì d ự a trên các sáng ki ế n riêng bi ệ t M ụ c tiêu Sprint đư ợ c t ạ o ra trong s ự ki ệ n L ậ p k ế ho ạ ch Sprint và sau đó đư ợ c thêm vào Sprint Backlog Khi các Nhà phát tri ể n làm vi ệ c trong Sprint, h ọ luôn ghi nh ớ M ụ c tiêu Sprint N ế u công v i ệ c di ễ n ra khác v ớ i h ọ mong đ ợ i, h ọ s ẽ c ộ ng tác v ớ i Product Owner đ ể thương lư ợ ng v ề ph ạ m vi c ủ a Sprint Backlog trong Sprint sao cho không ả nh hư ở ng đ ế n M ụ c tiêu Sprint Increment Ph ầ n s ả n ph ẩ m gia tăng là m ộ t bư ớ c đ ệ m c ụ th ể đ ể hư ớ ng t ớ i M ụ c tiêu S ả n ph ẩ m M ỗ i Ph ầ n s ả n ph ẩ m gia tăng đư ợ c c ộ ng vào t ấ t c ả các Ph ầ n s ả n ph ẩ m gia tăng trư ớ c đó và đư ợ c ki ể m tra k ỹ lư ỡ ng, đ ả m b ả o r ằ ng t ấ t c ả các Ph ầ n s ả n ph ẩ m gia tăng ho ạ t đ ộ ng cùng nhau trơn chu Đ ể cung c ấ p giá tr ị , Ph ầ n s ả n ph ẩ m gia tăng ph ả i có th ể s ử d ụ ng đ ư ợ c Nhi ề u Ph ầ n s ả n ph ẩ m gia tăng có th ể đư ợ c t ạ o ra trong m ộ t Sprint T ổ ng các Ph ầ n s ả n ph ẩ m gia tăng đư ợ c trình bày t ạ i phiên Sprint Review , và b ằ ng cách đó h ỗ tr ợ ch ủ nghĩa kinh nghi ệ m Tuy nhiên, m ỗ i Ph ầ n s ả n ph ẩ m gia tăng có th ể đư ợ c bàn giao cho các bên liên quan trư ớ c khi k ế t thúc Sprint Sprint Review không bao gi ờ đư ợ c coi là m ộ t cánh c ổ ng đ ể bàn giao giá tr ị Công vi ệ c không th ể đư ợ c coi là m ộ t ph ầ n c ủ a Ph ầ n s ả n ph ẩ m gia tăng ch ừ ng nào nó còn chưa đáp ứ ng Đ ị nh nghĩa v ề Hoàn thành Cam k ế t: Đ ị nh ng hĩa Hoàn thành Đ ị nh nghĩa Hoàn thành là m ộ t mô t ả chính th ứ c v ề tr ạ ng thái c ủ a Ph ầ n s ả n ph ẩ m gia tăng khi nó đáp ứ ng các ch ỉ tiêu ch ấ t lư ợ ng c ầ n thi ế t c ủ a s ả n ph ẩ m Th ờ i đi ể m m ộ t h ạ ng m ụ c Product Backlog đáp ứ ng Đ ị nh nghĩa Hoàn thành, thì m ộ t Ph ầ n s ả n ph ẩ m gia tăng đư ợ c t ạ o ra Đ ị nh nghĩa Hoàn thành t ạ o ra s ự minh b ạ ch b ằ ng cách cung c ấ p cho m ọ i ngư ờ i s ự hi ể u bi ế t chung v ề nh ữ ng công vi ệ c gì đã đư ợ c hoàn thành như m ộ t ph ầ n c ủ a Ph ầ n s ả n ph ẩ m gia tăng N ế u m ộ t h ạ ng m ụ c Product Backlog không đáp ứ ng Đ ị nh nghĩa Hoàn thành, nó không th ể đư ợ c phát hành ho ặ c th ậ m chí s ẽ không đư ợ c trình bày t ạ i phiên Sprint Review Thay vào đó, nó quay tr ở l ạ i Product Backlog đ ể xem xét trong tương lai N ế u Đ ị nh nghĩa Hoàn thành cho m ộ t P h ầ n s ả n ph ẩ m gia tăng là n ằ m trong m ộ t tiêu chu ẩ n c ủ a t ổ ch ứ c, thì t ấ t c ả các Nhóm Scrum ph ả i tuân th ủ nó như m ộ t đi ề u t ố i thi ể u N ế u Đ ị nh nghĩa Hoàn thành không ph ả i là m ộ t tiêu chu ẩ n t ổ ch ứ c, Nhóm Scrum ph ả i t ự t ạ o ra m ộ t Đ ị nh nghĩa Hoàn thành phù h ợ p cho s ả n ph ẩ m Các nhà phát tri ể n đư ợ c yêu c ầ u tuân th ủ Đ ị nh nghĩa Hoàn thành N ế u có nhi ề u Nhóm Scrum cùng làm vi ệ c trên m ộ t s ả n ph ẩ m, h ọ ph ả i cùng nhau xác đ ị nh và tuân th ủ cùng m ộ t Đ ị nh nghĩa Hoàn thành L ị ch s ử Scrum Guide Ken Schwaber và Jeff Sutherland l ầ n đ ầ u tiên đ ồ ng trình bày v ề Scrum t ạ i H ộ i ngh ị OOPSLA năm 1995 V ề cơ b ả n, nó ghi l ạ i nh ữ ng gì Ken và Jeff đã h ọ c đư ợ c trong vài năm trư ớ c đó và công khai đ ị nh nghĩa chính th ứ c đ ầ u tiên v ề Scrum Scrum Guide là tài li ệ u v ề Scrum như cách nó đã đư ợ c phát tri ể n , ti ế n hóa và duy trì b ề n v ữ ng trong hơn 30 năm qua b ở i Jeff Sutherland và Ken Schwa ber Các ngu ồ n khác cung c ấ p các m ẫ u, quy trình và thông tin chi ti ế t b ổ sung cho khuôn kh ổ Scrum Chúng có th ể làm tăng năng su ấ t, giá tr ị , s ự sáng t ạ o và s ự hài lòng v ề k ế t qu ả

SCRUM GUIDE 2020

SCRUM GUIDE 2020

KEN SCHWABER & JEFF SUTHERLAND

SCRUM GUIDE 2020

Mục đích của Scrum Guide 2

Định nghĩa Scrum 2

Lý thuyết Scrum 3

Transparency (Minh bạch) 3

Inspection (Kiểm tra) 3

Adaptation (Thích ứng) 3

Giá trị Scrum 3

Nhóm Scrum 4

Developers 4

Product Owner 4

Scrum Master 5

Sự kiện Scrum 5

Sprint 6

Sprint Planning 6

Daily Scrum 7

Sprint Review 7

Sprint Retrospective 8

Scrum Artifacts 8

Product Backlog 8

Cam kết: Mục tiêu Sản phẩm 9

Sprint Backlog 9

Cam kết: Mục tiêu Sprint 9

Increment 9

Cam kết: Định nghĩa Hoàn thành 9

Lịch sử Scrum Guide 10

SCRUM GUIDE 2020

Mục đích của Scrum Guide

Chúng tôi đã phát triển Scrum vào đầu những năm 1990 Chúng tôi đã viết phiên bản đầu tiên của Scrum Guide vào năm 2010 để giúp mọi người trên toàn thế giới hiểu về Scrum Chúng tôi đã phát triển Scrum Guide kể từ đó thông qua các bản cập nhật nhỏ Cùng nhau, chúng tôi đứng đằng sau nó (Ken Schwaber

và Jeff Sutherland)

Scrum Guide nêu định nghĩa về Scrum Mỗi yếu tố của khuôn khổ phục vụ một mục đích cụ thể cần thiết cho giá trị tổng thể và kết quả đạt được với Scrum Việc thay đổi thiết kế hoặc ý tưởng cốt lõi của Scrum, loại bỏ các yếu tố hoặc không tuân theo các quy tắc của Scrum, sẽ che đậy các vấn đề và hạn chế lợi ích của Scrum, thậm chí có thể khiến nó trở nên vô dụng

Chúng tôi theo dõi việc sử dụng Scrum ngày càng tăng trong một thế giới phức tạp ngày càng phát triển Chúng tôi rất vui khi thấy Scrum được áp dụng trong nhiều lĩnh vực có công việc phức tạp về cơ bản, ngoài lĩnh vực phát triển sản phẩm phần mềm vốn là nguồn gốc của Scrum Đi cùng với việc áp dụng Scrum rộng rãi là lúc các nhà phát triển, nhà nghiên cứu, nhà phân tích, nhà khoa học và các chuyên gia khác thực hiện công việc Chúng tôi sử dụng từ “nhà phát triển” trong Scrum không phải để loại trừ mà để đơn giản hóa Nếu bạn nhận được giá trị từ Scrum, hãy coi như bạn được kể là “nhà phát triển”

Khi Scrum đang được sử dụng, các hình mẫu, quy trình và thông tin chi tiết phù hợp với khuôn khổ Scrum như được mô tả trong tài liệu này, có thể được tìm thấy, được áp dụng và phát minh lại Mô tả chúng (các hình mẫu, quy trình và thông tin chi tiết) nằm ngoài mục đích của Scrum Guide vì chúng nhạy cảm với ngữ cảnh và khác nhau nhiều giữa các cách sử dụng Scrum Các chiến thuật để sử dụng trong khuôn khổ Scrum rất khác nhau và được mô tả ở những tài liệu khác

Định nghĩa Scrum

Scrum là một khuôn khổ hạng nhẹ giúp mọi người, các nhóm và tổ chức tạo ra giá trị thông qua các giải pháp linh hoạt thích ứng cho các vấn đề phức tạp

Nói ngắn gọn, Scrum yêu cầu Scrum Master phải thúc đẩy một môi trường mà ở đó:

thành một Product Backlog

sau mỗi Sprint

 Lặp lại quá trình nói trên

Scrum rất đơn giản Hãy thử nguyên trạng và xác định xem triết lý, lý thuyết và cấu trúc của nó có giúp đạt được mục tiêu và tạo ra giá trị hay không Khuôn khổ Scrum có chủ ý không hoàn chỉnh, chỉ xác định các phần cần thiết để triển khai lý thuyết Scrum Scrum được xây dựng dựa trên trí tuệ tập thể của những người sử dụng nó Thay vì cung cấp cho mọi người những hướng dẫn chi tiết, các quy tắc của Scrum hướng dẫn các mối quan hệ và tương tác của họ

Các quy trình, kỹ thuật và phương pháp khác nhau có thể được sử dụng trong khuôn khổ này Scrum bao gồm các thực hành hiện có hoặc có thể làm cho các thực hành đó không còn cần thiết Scrum cho thấy hiệu quả tương đối của các kỹ thuật quản lý, môi trường và công việc hiện tại, để có thể thực hiện các cải tiến

Lý thuyết Scrum

Scrum được thành lập dựa trên chủ nghĩa kinh nghiệm và tư duy tinh gọn Chủ nghĩa kinh nghiệm khẳng định rằng kiến thức đến từ kinh nghiệm và đưa ra quyết định dựa trên những gì quan sát được Tư duy tinh gọn giảm lãng phí và tập trung vào những điều cần thiết

Scrum sử dụng cách tiếp cận lặp đi lặp lại, gia tăng để tối ưu hóa khả năng dự đoán và kiểm soát rủi ro Scrum thu hút sự tham gia của các nhóm người có tất cả các kỹ năng và chuyên môn để thực hiện công việc và chia sẻ hoặc học hỏi những kỹ năng đó nếu cần

Scrum kết hợp bốn sự kiện chính thức để kiểm tra và điều chỉnh trong một sự kiện bao trùm chung là Sprint Các sự kiện này hoạt động vì chúng thực hiện các trụ cột Scrum theo chủ nghĩa kinh nghiệm về tính minh bạch, kiểm tra và thích ứng

Transparency (Minh bạch)

Quá trình và công việc nổi lên phải được hiển thị rõ ràng cho những người thực hiện công việc cũng như những người nhận công việc Với Scrum, các quyết định quan trọng dựa trên trạng thái nhận thức của ba sản phẩm (artifact) chính thức của nó Các sản phẩm có tính minh bạch thấp có thể dẫn đến các quyết định làm giảm giá trị và tăng rủi ro

Tính minh bạch cho phép kiểm tra Kiểm tra mà không minh bạch sẽ là lệch đường và lãng phí

Inspection (Kiểm tra)

Các vật phẩm của Scrum và tiến trình hướng tới các mục tiêu đã thống nhất phải được kiểm tra thường xuyên và cần mẫn để phát hiện các vấn đề hoặc sự sai lệch không mong muốn Để giúp kiểm tra, Scrum cung cấp lịch hoạt động dưới dạng năm sự kiện của nó

Kiểm tra cho phép thích ứng Việc kiểm tra mà không thích ứng được coi là vô nghĩa Các sự kiện Scrum được thiết kế để kích thích sự thay đổi

Adaptation (Thích ứng)

Nếu bất kỳ khía cạnh nào của quá trình lệch ra ngoài giới hạn cho phép hoặc nếu sản phẩm tạo thành không được chấp nhận, thì quá trình đang được áp dụng hoặc nguyên liệu được sản xuất phải được điều chỉnh Việc điều chỉnh phải được thực hiện càng sớm càng tốt để giảm thiểu sai lệch hơn nữa

Việc thích ứng trở nên khó khăn hơn khi những người liên quan không được trao quyền hoặc không tự quản lý Nhóm Scrum được kỳ vọng sẽ thích ứng ngay khi học được bất kỳ điều gì mới thông qua kiểm tra

Giá trị Scrum

Việc sử dụng thành công Scrum phụ thuộc vào việc mọi người trở nên thành thạo hơn trong việc sống với năm giá trị:

Cam kết, Tập trung, Cởi mở, Tôn trọng và Dũng cảm (Commitment, Focus, Openness, Respect, Courage)

Nhóm Scrum cam kết đạt được các mục tiêu của mình và hỗ trợ lẫn nhau Trọng tâm chính của họ là vào công việc của Sprint để đạt được tiến độ tốt nhất có thể đối với các mục tiêu này Nhóm Scrum và các bên liên quan cởi mở về công việc và những thách thức Các thành viên Nhóm Scrum tôn trọng lẫn nhau

để trở thành những người có năng lực, độc lập và được những người cùng làm việc tôn trọng Các thành viên Nhóm Scrum có can đảm để làm điều đúng đắn, và giải quyết những vấn đề khó khăn

Những giá trị này cung cấp định hướng cho Nhóm Scrum liên quan đến công việc, hành động và hành vi của họ Các quyết định được đưa ra, các bước đã thực hiện và cách sử dụng Scrum phải củng cố những giá trị này, không làm giảm hoặc làm suy yếu chúng Các thành viên Nhóm Scrum tìm hiểu và khám phá các giá trị khi họ làm việc với các sự kiện và vật phẩm của Scrum Khi những giá trị này được thể hiện bởi Nhóm Scrum và những người mà họ làm việc cùng, các trụ cột kinh nghiệm của Scrum về tính Minh bạch, Kiểm tra và Thích ứng sẽ trở thành niềm tin xây dựng cuộc sống

Nhóm Scrum

Đơn vị cơ bản của Scrum là một nhóm nhỏ các thành viên gọi là Nhóm Scrum Nhóm Scrum bao gồm một Scrum Master, một Product Owner và các Nhà phát triển Trong Nhóm Scrum, không có nhóm con hoặc

hệ thống phân cấp Nhóm Scrum là một tổ chức gắn kết của các chuyên gia tập trung vào một mục tiêu tại một thời điểm gọi là Mục tiêu Sản phẩm

Các thành viên nhóm Scrum có khả năng hoán đổi nghiệp vụ (cross-functional) , nghĩa là các thành viên

có tất cả các kỹ năng cần thiết để tạo ra giá trị cho mỗi Sprint Họ cũng có năng lực tự quản lý, nghĩa là họ

tự quyết định ai làm gì, khi nào và làm như thế nào

Nhóm Scrum đủ nhỏ để luôn linh hoạt và đủ lớn để hoàn thành công việc quan trọng trong một Sprint,

và thường là có 10 người trở xuống Nói chung, chúng tôi nhận thấy các nhóm nhỏ giao tiếp tốt hơn và làm việc hiệu quả hơn Nếu các nhóm Scrum trở nên quá lớn, nên xem xét tổ chức lại thành nhiều nhóm Scrum có sự gắn kết với nhau, mỗi nhóm tập trung vào cùng một sản phẩm Do đó, các nhóm này nên chia sẻ cùng một Mục tiêu Sản phẩm, một Product Backlog và một Product Owner

Nhóm Scrum chịu trách nhiệm về tất cả các hoạt động liên quan đến sản phẩm: gồm việc hợp tác với các bên liên quan, kiểm tra, bảo trì, vận hành, thử nghiệm, nghiên cứu và phát triển và bất kỳ hoạt động nào khác có thể được yêu cầu Họ được tổ chức và trao quyền để quản lý công việc của chính họ Làm việc thông qua các Sprint với một nhịp độ bền vững giúp cải thiện sự tập trung và nhất quán của Nhóm Scrum Toàn bộ Nhóm Scrum phải chịu trách nhiệm về việc tạo ra Phần sản phẩm gia tăng hữu ích và có giá trị sau mỗi Sprint Scrum xác định ba vai trò trách nhiệm cụ thể trong một Nhóm Scrum: Developers, Product Owner và Scrum Master

Developers

Các nhà phát triển là những người trong Nhóm Scrum cam kết tạo ra mọi khía cạnh của một Phần sản phẩm gia tăng có thể sử dụng được sau mỗi Sprint

Các kỹ năng cụ thể mà Nhà phát triển cần có thường rất rộng và sẽ thay đổi theo lĩnh vực công việc Tuy nhiên, các Nhà phát triển luôn phải chịu trách nhiệm về:

 Lập kế hoạch cho Sprint, Sprint Backlog;

Product Owner

Product Owner có trách nhiệm tối đa hóa giá trị của sản phẩm tạo ra bởi công việc của Nhóm Scrum Cách thực hiện điều này có thể rất khác nhau giữa các tổ chức, Nhóm Scrum và cá nhân Product Owner Product Owner cũng chịu trách nhiệm về việc quản lý Product Backlog hiệu quả, bao gồm:

 Tạo ra và truyền đạt rõ ràng các hạng mục Product Backlog;

Product Owner có thể tự thực hiện công việc nói trên hoặc có thể giao phó cho người khác Bất kể cách nào, Product Owner vẫn phải là người chịu trách nhiệm

Để cho các Product Owner thành công, toàn bộ tổ chức phải tôn trọng quyết định của họ Những quyết định này được hiển thị trong nội dung và thứ tự của Product Backlog, và thông qua Phần sản phẩm gia tăng có thể kiểm tra được trong buổi Sprint Review

Product Owner là một người, không phải là một ủy ban Product Owner có thể đại diện cho nhu cầu của nhiều bên liên quan trong một Product Backlog Những người muốn thay đổi Product Backlog có thể thực hiện sự thay đổi bằng cách thuyết phục Product Owner

Scrum Master

Scrum Master có trách nhiệm thiết lập Scrum như được định nghĩa trong Scrum Guide Họ làm điều này bằng cách giúp mọi người hiểu lý thuyết và thực hành Scrum, cả trong Nhóm Scrum và tổ chức

Scrum Master chịu trách nhiệm về hiệu quả của Nhóm Scrum Họ thực hiện điều này bằng cách cho phép Nhóm Scrum cải thiện các phương pháp thực hành của mình, trong khuôn khổ Scrum

Scrum Master là những nhà lãnh đạo thực sự phục vụ Nhóm Scrum và rộng hơn là phục vụ tổ chức Scrum Master phục vụ Nhóm Scrum theo một số cách, bao gồm:

Định nghĩa Hoàn thành;

 Gây ra việc loại bỏ các trở ngại đối với tiến trình công việc của Nhóm Scrum; và,

trong khung thời gian cố định

Scrum Master phục vụ Product Owner theo một số cách, bao gồm:

rõ ràng và ngắn gọn;

 Tạo điều kiện cho sự hợp tác của các bên liên quan khi được yêu cầu hoặc khi cần thiết

Scrum Master phục vụ tổ chức theo một số cách, bao gồm:

công việc phức tạp; và,

Sự kiện Scrum

Sprint là nơi chứa tất cả các sự kiện khác Mỗi sự kiện trong Scrum là một cơ hội chính thức để kiểm tra

và điều chỉnh các vật phẩm Scrum Những sự kiện này được thiết kế đặc biệt để tạo ra sự minh bạch cần

thiết Nếu không thực hiện một sự kiện nào đó trong số những sự kiện đã chỉ dẫn sẽ dẫn đến hậu quả mất cơ hội để kiểm tra và thích ứng Các sự kiện trong Scrum nhằm tạo ra nhịp điệu công việc đều đặn và giảm thiểu các cuộc họp không được qui định trong Scrum

Một cách tối ưu, thì mỗi sự kiện Scrum nên được tổ chức tại cùng một thời điểm và địa điểm để giảm bớt

sự phức tạp

Sprint

Sprint là nhịp tim của Scrum, nơi các ý tưởng được biến thành giá trị

Chúng có độ dài cố định từ một tháng trở xuống để tạo sự nhất quán Một Sprint mới bắt đầu ngay sau khi kết thúc Sprint trước

Tất cả các công việc cần thiết để đạt được Mục tiêu Sản phẩm, bao gồm cả các buổi Sprint Planning, Daily Scrums, Sprint Review, và Sprint Retrospective, đều diễn ra trong Sprint

Trong Sprint:

 Product Backlog được tinh chỉnh khi cần thiết; và,

thêm nhiều hơn

Các Sprint cho phép khả năng dự đoán bằng cách đảm bảo kiểm tra và điều chỉnh tiến độ thực hiện Mục tiêu sản phẩm ít nhất mỗi tháng một lần Khi khung thời gian của Sprint quá dài, Mục tiêu Sprint có thể trở nên không hợp lệ, độ phức tạp và rủi ro có thể tăng lên Các Sprint ngắn hơn có thể được sử dụng để tạo ra nhiều chu kỳ học tập hơn và hạn chế rủi ro về chi phí và công sức Mỗi Sprint có thể được coi là một dự án ngắn

Có nhiều phương pháp thực hành khác nhau để dự báo tiến độ, chẳng hạn như các biểu đồ burn-down, burn-up hoặc biểu đồ dòng chảy tích lũy (cumulative flow) Mặc dù đã được chứng minh là hữu ích, nhưng những phương pháp thực hành này không thay thế được tầm quan trọng của chủ nghĩa kinh nghiệm Trong môi trường phức tạp, điều sẽ xảy ra là không thể biết trước Chỉ những gì đã xảy ra mới có thể được

sử dụng để ra quyết định trong tương lai

Một Sprint có thể bị hủy bỏ nếu Mục tiêu Sprint trở nên lỗi thời Chỉ Product Owner mới có quyền hủy Sprint

Sprint Planning

Lập kế hoạch Sprint khởi đầu Sprint bằng cách sắp xếp công việc cần thực hiện cho Sprint Kế hoạch kết quả này được tạo nên bởi sự cộng tác của toàn bộ Nhóm Scrum

Product Owner đảm bảo rằng những người tham dự được chuẩn bị để thảo luận về các hạng mục Product Backlog quan trọng nhất và cách chúng liên kết với Mục tiêu Sản phẩm Nhóm Scrum cũng có thể mời những người khác tham gia Lập kế hoạch Sprint để nhận được lời khuyên

Lập kế hoạch Sprint giải quyết các chủ đề sau:

Chủ đề 1: Tại sao Sprint này lại có giá trị?

Product Owner đề xuất cách sản phẩm có thể tăng giá trị và tiện ích của nó trong Sprint hiện tại Sau đó, toàn bộ Nhóm Scrum sẽ cộng tác để xác định Mục tiêu Sprint nhằm truyền đạt lý do tại sao Sprint lại có

giá trị đối với các bên liên quan Mục tiêu Sprint phải được chốt lại trước khi kết thúc buổi Lập kế hoạch Sprint

Chủ đề 2: Công việc gì có thể hoàn thành trong Sprint này?

Thông qua thảo luận với Product Owner, các Nhà phát triển chọn các hạng mục từ Product Backlog để đưa vào Sprint hiện tại Nhóm Scrum có thể tinh chỉnh các mục này trong quá trình chọn này, nhằm tăng cường sự hiểu biết và sự tự tin

Việc chọn số lượng hạng mục có thể hoàn thành trong một Sprint có thể là một thách thức Tuy nhiên, khi các Nhà phát triển càng biết nhiều về hiệu suất làm việc trong quá khứ, năng lực sắp tới và Định nghĩa Hoàn thành của họ, thì họ càng tin tưởng vào các dự báo Sprint của mình

Chủ đề 3: Công việc đã chọn sẽ được hoàn thành bằng cách nào?

Đối với mỗi hạng mục Product Backlog đã chọn, các Nhà phát triển lập kế hoạch công việc cần thiết để tạo ra Phần sản phẩm gia tăng đáp ứng Định nghĩa Hoàn thành Điều này thường được thực hiện bằng cách chia nhỏ các hạng mục Product Backlog thành các mục công việc nhỏ hơn sẽ được làm trong một ngày hoặc ngắn hơn Việc này được thực hiện như thế nào là do các Nhà phát triển quyết định Không ai khác chỉ cho họ cách biến các hạng mục Product Backlog thành các Phần sản phẩm gia tăng về giá trị Mục tiêu Sprint, các hạng mục Product Backlog được chọn cho Sprint, cùng với kế hoạch thực hiện chúng được gọi chung là Sprint Backlog

Lập kế hoạch Sprint có khung thời gian tối đa là tám giờ cho Sprint một tháng Đối với Sprint ngắn hơn,

sự kiện thường ngắn hơn

Daily Scrum

Mục đích của Daily Scrum là kiểm tra tiến độ thực hiện Mục tiêu Sprint và điều chỉnh Sprint Backlog khi cần thiết, điều chỉnh kế hoạch công sắp tới

Daily Scrum là một sự kiện kéo dài 15 phút dành cho các Nhà phát triển của Nhóm Scrum Để giảm bớt

sự phức tạp, nó được tổ chức vào thời gian cố định và diễn ra hằng ngày trong Sprint Nếu Product Owner hoặc Scrum Master đang tích cực làm việc với các hạng mục trong Sprint Backlog, họ sẽ tham gia với tư cách như là một Nhà phát triển

Các nhà phát triển có thể chọn bất kỳ cấu trúc và kỹ thuật nào họ muốn, miễn là Daily Scrum của họ tập trung vào tiến độ hướng tới Mục tiêu Sprint và đưa ra một kế hoạch khả thi cho ngày làm việc tiếp theo Điều này tạo ra sự tập trung và cải thiện khả năng tự quản lý

Daily Scrums cải thiện thông tin liên lạc, xác định các trở ngại, thúc đẩy việc ra quyết định nhanh chóng

và do đó loại bỏ nhu cầu về các cuộc họp khác

Daily Scrum không phải là cơ hội duy nhất các Nhà phát triển được phép điều chỉnh kế hoạch của họ Họ thường gặp nhau suốt cả ngày để thảo luận chi tiết hơn về việc điều chỉnh hoặc lập kế hoạch lại phần việc còn lại của Sprint

Sprint Review

Mục đích của Sprint Review là kiểm tra kết quả công việc của Sprint và xác định các sự điều chỉnh trong tương lai Nhóm Scrum trình bày kết quả công việc của họ cho các bên liên quan chính và tiến trình hướng tới Mục tiêu Sản phẩm sẽ được thảo luận

Trong sự kiện này, Nhóm Scrum và các bên liên quan rà soát lại những gì đã đạt được trong Sprint và những gì đã thay đổi trong môi trường của họ Dựa trên thông tin này, những người tham dự cùng nhau

xác định những việc cần làm tiếp theo Product Backlog cũng có thể được điều chỉnh để đáp ứng các cơ hội mới Sprint Review là một phiên làm việc và Nhóm Scrum nên tránh biến nó thành một buổi thuyết trình

Sprint Review là sự kiện gần sát cuối cùng của Sprint và có khung thời gian tối đa là bốn giờ cho Sprint có khung một tháng Đối với Sprint ngắn hơn, sự kiện này thường ngắn hơn

Sprint Retrospective

Mục đích của Sprint Retrospective là hoạch định biện pháp để tăng chất lượng và hiệu quả

Nhóm Scrum kiểm tra xem Sprint đã diễn ra như thế nào trên các khía cạnh các cá nhân, sự tương tác, quy trình, công cụ và Định nghĩa Hoàn thành Các yếu tố được kiểm tra thường thay đổi theo lĩnh vực công việc Các giả định khiến họ lạc lối cần được xác định và tìm hiểu nguồn gốc của chúng Nhóm Scrum thảo luận về những gì diễn ra tốt đẹp trong Sprint, những vấn đề mà họ gặp phải và cách những vấn đề

đó đã được giải quyết (hoặc không được giải quyết)

Nhóm Scrum xác định những thay đổi hữu ích nhất để cải thiện hiệu quả của nhóm Những cải tiến có ảnh hưởng nhất nên được thực hiện càng sớm càng tốt Chúng thậm chí có thể được đưa vào Sprint Backlog của Sprint tiếp theo

Sprint Retrospective là sự kiện cuối cùng của Sprint Nó có khung thời gian tối đa là ba giờ cho Sprint có khung một tháng Đối với Sprint ngắn hơn, sự kiện thường ngắn hơn

Scrum Artifacts

Các vật phẩm của Scrum đại diện cho công việc hoặc giá trị Chúng được thiết kế để tăng cường tính minh bạch của các thông tin chính Vì vậy, tất cả mọi người kiểm tra chúng đều có cơ sở như nhau để thích ứng

Mỗi vật phẩm chứa đựng một sự cam kết rằng chúng cung cấp thông tin để nâng cao tính minh bạch và tập trung vào cái đích mà theo đó tiến độ thực hiện được đo lường:

 Đối với Sprint Backlog, cam kết là Mục tiêu Sprint

Những cam kết này tồn tại để củng cố chủ nghĩa kinh nghiệm và các giá trị Scrum cho Nhóm Scrum và các bên liên quan của họ

Product Backlog

Product Backlog là một danh sách được phát triển dần và có thứ tự về những thứ cần thiết để cải thiện sản phẩm Đây là nguồn duy nhất các công việc mà Nhóm Scrum phải thực hiện

Các hạng mục Product Backlog mà có thể được Nhóm Scrum hoàn thành trong một Sprint được coi là sẵn sàng để được lựa chọn trong sự kiện Lập kế hoạch Sprint Chúng thường đạt được mức độ minh bạch như vậy sau các hoạt động tinh chỉnh (refinement) Tinh chỉnh Product Backlog là hành động chia nhỏ và xác định rõ hơn các hạng mục Product Backlog thành các mục nhỏ hơn và chính xác hơn Đây là một hoạt động liên tục để thêm các chi tiết, chẳng hạn như thêm mô tả, sắp xếp lại thứ tự và ước lượng qui mô Các thuộc tính thường thay đổi theo lĩnh vực công việc

Các nhà phát triển, những người thực hiện công việc, chịu trách nhiệm ước lượng qui mô công việc Product Owner có thể ảnh hưởng đến Nhà phát triển bằng cách giúp họ hiểu và lựa chọn sự cân bằng

Cam kết: Mục tiêu Sản phẩm

Mục tiêu Sản phẩm mô tả trạng thái tương lai của sản phẩm được dùng làm mục tiêu để Nhóm Scrum lập

kế hoạch thực hiện Mục tiêu Sản phẩm nằm trong Product Backlog Những phần còn lại của Product Backlog lộ diện dần để xác định “cái gì” sẽ hoàn thành Mục tiêu Sản phẩm

Sản phẩm là phương tiện để cung cấp giá trị Nó có một ranh giới rõ ràng, có các bên liên quan được biết rõ, có người dùng hoặc khách hàng được xác định Một sản phẩm có thể là một dịch vụ, một sản phẩm vật lý hoặc một cái gì đó trừu tượng hơn

Mục tiêu Sản phẩm là mục tiêu dài hạn của Nhóm Scrum Họ phải hoàn thành (hoặc từ bỏ) một mục tiêu trước khi thực hiện mục tiêu tiếp theo

Sprint Backlog

Sprint Backlog bao gồm Mục tiêu Sprint (“Why”), tập hợp các hạng mục Product Backlog được chọn cho Sprint (“What”), và một kế hoạch hành động để cung cấp Phần sản phẩm gia tăng (“How”)

Sprint Backlog là một kế hoạch dành cho các Nhà phát triển Đó là một bức tranh thời gian thực, có thể nhìn thấy rõ ràng về công việc mà các Nhà phát triển dự định hoàn thành trong Sprint để đạt được Mục tiêu Sprint Do đó, Sprint Backlog được cập nhật trong suốt Sprint khi các nhà Phát triển học được nhiều điều hơn Nó phải có đủ chi tiết để họ có thể kiểm tra tiến trình của mình trong Daily Scrum

Cam kết: Mục tiêu Sprint

Mục tiêu Sprint là mục tiêu duy nhất của Sprint Mặc dù Mục tiêu Sprint là cam kết của Nhà phát triển, nhưng nó cung cấp sự linh hoạt về công việc cụ thể cần thực hiện để đạt được nó Mục tiêu Sprint cũng tạo ra sự gắn kết và tập trung, khuyến khích Nhóm Scrum làm việc cùng nhau thay vì dựa trên các sáng kiến riêng biệt

Mục tiêu Sprint được tạo ra trong sự kiện Lập kế hoạch Sprint và sau đó được thêm vào Sprint Backlog Khi các Nhà phát triển làm việc trong Sprint, họ luôn ghi nhớ Mục tiêu Sprint Nếu công việc diễn ra khác với họ mong đợi, họ sẽ cộng tác với Product Owner để thương lượng về phạm vi của Sprint Backlog trong Sprint sao cho không ảnh hưởng đến Mục tiêu Sprint

Increment

Phần sản phẩm gia tăng là một bước đệm cụ thể để hướng tới Mục tiêu Sản phẩm Mỗi Phần sản phẩm gia tăng được cộng vào tất cả các Phần sản phẩm gia tăng trước đó và được kiểm tra kỹ lưỡng, đảm bảo rằng tất cả các Phần sản phẩm gia tăng hoạt động cùng nhau trơn chu Để cung cấp giá trị, Phần sản phẩm gia tăng phải có thể sử dụng được

Nhiều Phần sản phẩm gia tăng có thể được tạo ra trong một Sprint Tổng các Phần sản phẩm gia tăng được trình bày tại phiên Sprint Review, và bằng cách đó hỗ trợ chủ nghĩa kinh nghiệm Tuy nhiên, mỗi Phần sản phẩm gia tăng có thể được bàn giao cho các bên liên quan trước khi kết thúc Sprint Sprint Review không bao giờ được coi là một cánh cổng để bàn giao giá trị

Công việc không thể được coi là một phần của Phần sản phẩm gia tăng chừng nào nó còn chưa đáp ứng Định nghĩa về Hoàn thành

Cam kết: Định nghĩa Hoàn thành

Định nghĩa Hoàn thành là một mô tả chính thức về trạng thái của Phần sản phẩm gia tăng khi nó đáp ứng các chỉ tiêu chất lượng cần thiết của sản phẩm

Thời điểm một hạng mục Product Backlog đáp ứng Định nghĩa Hoàn thành, thì một Phần sản phẩm gia tăng được tạo ra