Pomagałem ostatnio nowo powstałemu zespołowi podczas ich drugiego Sprintu. Kiedy się u nich pojawiłem – dzień przed Sprint Review – na tablicy korkowej wisiało 10 zadań, z czego tylko 1 było zakończone. Co więcej, było to zadanie znajdujące się na ostatniej pozycji ich Sprint Backlogu. Podczas rozmowy ze Scrum Masterem tego zespołu dowiedziałem się, że mają problem z finalizowaniem zadań oraz, że to kolejny sprint, kiedy dużo pracy jest w trakcie realizacji, a pomimo tego niewiele jest faktycznie skończone. Co to jest swarming? Zaproponowałem użycie techniki zwanej swarming (ang. rój). Polega ona na tym, że w danym momencie cały zespół pracuje

Efektem każdego sprintu w Scrumie powinien być działający fragment oprogramowania. Problematyczne dla wielu zespołów – szczególnie jeśli wcześniej pracowali w modelu kaskadowym – jest dzielenie wymagań produktowych na małe, zbywalne przyrosty. Często słyszy się głosy z zespołu mówiące, że krótkie sprinty uniemożliwiają oddanie sensownego przyrostu, a jako rozwiązanie proponują wydłużyć sprint. Idąc tym tokiem myślenia możemy założyć, że skoro w ciągu jednotygodniowego sprintu oddajemy zero działającego oprogramowania, to w ciągu dwutygodniowego sprintu oddamy… 2 razy zero. Jak zatem uporać się ze wspomnianym zerem? Przy dzieleniu wymagań na mniejsze części, pomocne może być spojrzenie z kilku perspektyw i próba odpowiedzi na proste pytania: użytkownik –