Należy wziąć pod uwagę cały szereg czynników:

1. Sytuacja rynkowa – jeśli projekt jest realizowany w szybko zmieniającym się środowisku (np. aplikacje mobilne), sprinty powinny być krótsze, by poprzez częstszą weryfikację priorytetów lepiej adresować zmieniające się otoczenie.
2. Rotacja w zespole – jeśli jest duża, sprinty powinny być krótkie, by zespół skupiał się na pracy zamiast na rotacjach.(ustala cały zespół, ale w przypadku braku kompromisu głos decydujący ma Scrum Master).
3. Kompetencje zespołu w estymowaniu – im mniejsze, tym krótsze powinny być sprinty. Wtedy też zespół ma więcej okazji, by zebrać doświadczenia w estymowaniu.
4. Stopień szczegółowości zdefiniowanego zakresu – im bardziej ogólnie zdefiniowany zakres tym większe prawdopodobieństwo zmiany oczekiwań biznesu, a co za tym idzie tym krótsze powinny być sprinty.
5. Odstęp czasowy między wydaniami (Release) – przyjęło się, że w ramach danego wydania powinny się odbyć min. 4 sprinty, by klient miał kilka okazji na przekazanie swoich spostrzeżeń. Czyli dla projektu z wydaniami w cyklu miesięcznym, sprinty powinny być tygodniowe.
6. Cash flow projektu – dłuższe sprinty oznaczają więcej niezakończonej pracy (WIP), czyli więcej inwestycji, która jeszcze się nie zwróciła. Krótsze sprinty oznaczają krótszy czas oczekiwania na pierwsze przychody ze stworzonego produktu.
7. Potrzeby Product Ownera i biznesu (co ile chcą widzieć postęp, ile mają czasu dla projektu).

Do tego dochodzą aspekty specyficzne dla danego projektu (produkt, organizacja itp.).

Jeżeli w którymkolwiek elementów ogólnych lub specyficznych projekt nie spełnia zdefiniowanych wcześniej oczekiwań, stanowi to podstawę do rozważania zmiany długości sprintu – trzeba przy tych dyskusjach oczywiście uwzględnić wszystkie aspekty.

Pozdrawiam.

Marcin.