poniedziałek, 12 marca 2012

Tworzenie wymagań (product backlog)

Spis user stories i epiców w porządku od najważniejszego do najmniej ważnego, opisane przez product ownera tworzy product backlog. Stanem optymalnym wydaje się mieć user stories na około 3-4 sprinty, w tym około połowę wyestymowaną przez zespół. Mając tak przygotowany product backlog dajemy zespołowi poczucie kontroli nad tym co mamy oraz pokazujemy członkom zespołu wizję w stronę której zmierzamy.

Cykl życia product product backlogu:
przykład product backlogu
Przykład product backlogu
  • Właściciel produktu tworzy wymagania (epiki i user stories) z których chciałby aby składał się produkt.
  • Następuje priorytetyzacja backlogu.
  • Backlog jest przestawiany na spotkaniu planistycznym sprintu, gdzie zespół decyduje ile pracy jest  w stanie wykonać
  • Elementy backlogu przyjmowane są do wykonania.
  • Elementy wykonane usuwa się z backlogu produktu, w kolejnym sprincie ponowienie procesu

Spis user stories i epiców które są wybrane przez zespół i wykonywane podczas sprintu tworzą mniejszy zbiór zwany sprint baclogiem. Sprint backlog powinien pozostawać niezmienny zgodnie z założeniami scruma, wyjątkiem są sytuacje kiedy product owner chce dodać coś na szybko do wykonania przez zespół, może to dodać jedynie kosztem usunięcia starego user story o podobnym rozmiarze.