Jest to codzienne, krótkie spotkanie, mające na celu synchronizację Developerów, a więc uzyskanie stanu, w którym wszyscy Developerzy wiedzą jak wygląda sytuacja w kontekście postępu prac w Sprincie. Celem jest weryfikacja planów dalszego działania w Sprincie i ich ewentualne dostosowanie, a przede wszystkim zaplanowanie kolejnych 24 godzin pracy.
Spotkanie to ma następujące cechy:
- trwa maksymalnie 15 minut (czas ten nie zależy ani od długości Sprintu ani liczebności Developerów),,
- odbywane jest zawsze w tym samym miejscu i o tej samej godzinie,
- w spotkaniu tym biorą aktywny udział wyłącznie Developerzy oraz opcjonalnie Scrum Master – udział innych osób jest dopuszczalny jedynie o ile pozostają one pasywnymi, milczącymi obserwatorami, a ich obecność nie zaburza w jakiś sposób przebiegu Daily Scruma,
- Product Owner lub Scrum Master uczestniczą aktywnie w spotkaniu jeśli są jednocześnie Developerami.
Daily Scrum często odbywa się na stojąco, ale nie jest to wymagane w Scrumie – formuła, w jakiej odbywa się to zdarzenie zależy od decyzji Developerów. Scrum Master nie powinien narzucać sposobu prowadzenia Daily Scruma, ale ma obowiązek nauczyć Developerów, jak robić to skutecznie.
Jeśli Daily Scrum ujawni problem wymagający znacznej zmiany planów działania w pozostałej części Sprintu (a więc uaktualnienia Backlogu Sprintu), może wymagać to więcej niż 15 minut. Daily Scrum służył będzie jedynie ustaleniu kiedy i w jakim gronie odbędzie się taka sesja „przeplanowania” Sprintu. Spotkanie to nie powinno być używane do dyskusji na temat rozwiązań technologicznych, sposobu korzystania z praktyk i narzędzi developerskich, ale do zidentyfikowania potrzeby takiej rozmowy i ustalenia, kiedy się ona odbędzie.
Developerzy komunikują się ze sobą w czasie Sprintu na bieżąco i Daily Scrum nie jest jedynym momentem, gdy koordynują swe działania. Nie czyni to tego spotkania nadmiarowym, ponieważ Daily Scrum nie służy jedynie wymiany informacji na temat tego co, kto i jak robi, ale przede wszystkim upewnieniu się, czy to, czym każdy jest aktualnie zajęty, jest tym, co przede wszystkim powinno teraz być robione. Ciężko uzyskać taką perspektywę i podjąć skuteczne decyzje o zmianie sposobu działania bez przerwania pracy na moment i uzyskania kompletnego obrazu stanu spraw w Sprincie.
Podczas Daily Scruma członkowie Zespołu Developerskiego omawiają następujące kwestie:
- co już udało się zrobić, a co przybliża Zespół Scrumowy do osiągnięcia Celu Sprintu,
- jakie problemy zagrażają osiągnięciu Celu Sprintu lub mogą to utrudnić,
- co w związku z tym każdy z Developerów zrobi do kolejnego Daily Scruma.
Podczas tego spotkania Developerzy dokonują sprawdzenia (ang. inspect) jak wygląda postęp prac nad osiągnięciem Celu Sprintu oraz dostosowują się (ang. adapt) poprzez odpowiednie, wspólne zaplanowanie kolejnego dnia.
W wielu Zespołach Scrum podczas Daily Scruma Developerzy odpowiadają kolejno na pytania wymienione powyżej, ale Scrum Guide nie wymaga takiego działania. Co więcej, niekoniecznie jest to korzystne, ponieważ wtedy w zasadzie tylko ostatni z Developerów zna kompletny obraz sytuacji i może świadomie zaplanować swoje działania. Dlatego, jeśli już stosuje się taką formułę Daily Scruma, warto zrobić dwie rundy: najpierw każdy mówi, co już zrobił i jakie problemy dostrzega, a potem – gdy stan wiedzy o przebiegu Sprintu jest wyrównany – każdy wyjaśnia, co zrobi. Zachęcamy też do eksperymentowania z różnymi formami prowadzenia Daily Scruma, a zwłaszcza inspirowania się praktykami kanbanowymi.
