Poniżej zbiór dobrych praktyk agailowych, które powinny znaleźć zastosowanie w większości projektów przez nas prowadzonych:

• współpraca z klientem (customer collaboration)
  • bieżąca aktualizacja postępu prac
  • informacja co będzie zrobione w ramach sprintu
  • nieustanna komunikacja z zespołem w celu pewności dostarczenia wszystkich funkcjonalności 
• budowa produktu (product backlog) 
  • podział produktu na małe kawałki możliwe do implementacji
  • duże funkcjonalności (epic) dzielone na wiele małych
  • oszacowanie pracochłonności potrzebnej na zrobienie danego kawałka 
  • priorytetyzacja w zalezności od potrzeb biznesowych klienta
  • najważniejsze finkcjonalności na górze listy 
  • utrzymywanie backlogu w porządku i ryzach, nie doprowadzać do przepełnienia
• iteracyjne budowanie produktu (iterative development, sprints)
  • dobór na podstawie dostępych godzin zespołu ilości pracy możliwej do zrobienia
  • zespół sam decyduje ile jest w stanie zrobić, patrząc na swoje możliwości i  doświadczenie poprzedniej iteracji
• ograniczenia czasowe (time boxed)
  • sztywny czas trwania sprintu (zazwyczaj od 2 tygodni do 1 miesiąca)
  • sztywny czas trwania scrum meetingów (codziennie około 10-15 minut)
• analiza i definicja funkcjonalnosci (value stream analysis)
  • definicja produktu na user stories bazując na analizie biznesowej, aby nie ominąć żadnych wartości biznesowych
  • definicja zależności biznesowych oraz technicznych pomiedzy funkcjonalnosciami  
• opisanie funkcjonalności produktu (user stories)
  • opis funkcjonalnosci bazując na komunikacji z klientem
  • opis z pozycji usera w specyficzny sposób (jako …. chcę ….. ponieważ… )
  • zawierające 3 najważniejsze sekcje (opis, kryterium akcepatcji oraz estymację czasową bazującą na złożoności) 
  • zbyt złożone rozbijane na mniejsze, aby mogły być jako całość zrobione w ramach kilku sprintów
• opisanie funkcjonalności poprzez przykłady (user stories specified by examples)
  • opis user stories w sposób podany wyżej uzupełniony o przykłady które pokazują wszytskie opcje działania funkcjonalnosci oraz jej wpyw na inne
  • duży support dla deweloperów i testerów 

• codzienne spotkania statusowe (scrum meetings)
  • codzienne poranne spotkanie, ok. 10 minutowe
  • prowadzone przez scrum mastera z całym zespołem
  • rozmowa o trzech kluczowych kwestiach (co zrobione od wczoraj, co zamierzamy robić dzisiaj oraz czy są jakies przeszkody aby spokojnie pracować)
  • dodatkowo programując w parach informacja kto z kim w parze
• ciągła integracja kodu (countinous integration)
  • pozwala zachować kod up to date
  • kod poddawany weryfikacji zanim zostanie złączony ze starym kodem
  • ułatwia testowanie nowych user stories
  • po złączeniu wykonywane junit testy, sprawdzenie czy nie ma błędów
  • nastepnego dnia  wykonywany regression test, gdzie widać czy nowa funkcjonalność wpływa negatywnie na resztę kodu
• automatyczne testy (automated tests)
  • regression test usuchamiany codzinnie przed przystąpieniem do prac upewniający która wersje kody są akceptowalne
  • szybka informacja który kawałek funkcjonalnosci nie działa zgodnie z załozeniami
• programowanie w parach (extreme programming)
  • implementacja user stories w parach(primary i secondary)
  • praca eksperta z nowicjuszem, jeden właściciel user story, w parze niezmienny, drugi zapewnia support, może rotować 
  • dwie sesje deweloperskie dziennie, raz jeden raz drugi jest właścicielem user story
  • przeglądy kodu realizowane w parach
  • macierz par w celu oceny zespołów, wyników oraz częstości pracy razem
  • wyniki zazwyczaj lepsze niż praca dwóch deweloperów samodzielnie
• development poprzez testy (test driven development)
  • programowanie począwszy od napisania testów akceptacyjnych, poprzedzaonych testami jednostkowymi, dopiero póżniej od pisania właściwego kodu opisującego user story
  • aktualizacja podczas spotkań scrumowych
• wykresy wypalania (burndown charts)
  • wykresy pokazujące czy idziemy zgodnie z planem, z kalendarzem deweloperskim
  • pokazujący szybko harmonogram prac ws czas
  • pokazujący ilość wykonanych user stories per jednostka czasu, poniżej lub powyzej planu
• demo sprintu (sprint demo meeting)
  • krótkie spotkanie pokazujące klientowi wykonane w ramach sprintu funkcjonalnosci i sposób ich działania
  • potwierdzenie prze klienta że akceptuje i że jest zrobione zgodnie z jego oczekiwaniami 
• spotkanie retrospektywne (retrospective meeting)
  • spotkanie iteracyjne po skończonych dewelopmencie
  • udział obowiązkowy to cały zespół, moze uczestniczyć klient
  • rozmowy na temat możliwosci poprawy procesu, jakości pracy, narzędzi, lessons learned, itp
  • macierz z podziałem na sekcje stop, start i continue
• działająca paczka po zakończeniu iteracji (shippable code)
  • zawsze działający kod po okresie developmentu
  • klient ma pewność że dostanie w krótkim czasie zakładaną wartość biznesową
• planownie releasów (release planning) 
  • kalendarz releasów daje jasną informację dla wszytskich kiedy można sie spodziewać produkcyjnie nowych funkcjonalnosci
  • pomaga w prawidłowym wersjononowaniu kodu
  • wspiera testy automatyczne i integracje