Wykres Spalania Wydania (ang. Release Burndown Chart) śledzi postęp zespołu deweloperskiego pod względem realizacji planu wydania. Wykres spalania wydania to podstawowy artefakt służący do śledzenia i przewidywania postępu w metododyce Scrum. „Wykres spalania pozwala na śledzenie i przewidywanie postępów projektu. Na podstawie szybkości z poprzednich sprintów wykres spalania wydania przewiduje przyszłość, aby zespół scrumowy mógł dostosować produkt […]

Tablica Zadań (ang. Task Board) pokazuje całość pracy wykonywanej przez zespół podczas sprintu. Jest ona stale aktualizowana w trakcie sprintu- jeżeli ktoś myśli o nowym zadaniu, pisze nową kartę i umieszcza ją na tablicy. W trakcie lub przed Codziennym Scrumem, zmienia się szacunki (w górę lub w dół) i przemieszcza się karty na tablicy. Tablica zadań

Rejestr sprintu  (ang. Sprint Backlog) to lista zadań, które Zespół Scrum zobowiązuje się wykonać w bieżącym sprincie. Pozycje rejestru sprintu są przeniesione z Produkt Backloga przez zespół, w oparciu o priorytety ustalone przez Właściciela Produktu. „Rejestr sprintu opisuje poprzez zestaw szczegółowych zadań, w jaki sposób zespół planuje zaprojektować, zbudować i przetestować dany podzbiór cech z rejestru

Pisząc jakąkolwiek specyfikację wymagań a rejestr produktu i rejestr sprintu są taką specyfikację należy uwzględnić wymagania niefunkcjonalne. O ile sama historyjka użytkownika zazwyczaj reprezentuje wymagania funkcjonalne to, w moim odczuciu, drobny problem jest z wymaganiami niefunkcjonalnymi, które reprezentują oczekiwania na poziomie systemu. Brak wymagań niefunkcjonalnych lub ich niedostateczna ilość są często źródłem problemów z programowaniem a

W zeszłym tygodniu pisałem o dobrych cechach Rejestru Produktu. Dziś chciałbym przybliżyć dobre cechy historyjki użytkownika. Dobra historyjka użytkownika powinna spełniać kryteria INVEST. INVEST to: Independent – niezależność Negotiable – negocjowalność Valuable – wartościowość Estimatable – ocenialność Sized correctly – dobry rozmiar Testable – testowalność Połączenie tych cech pozwala na budowanie sensownych i użytecznych historyjek użytkownika.

W zeszłym tygodniu opisałem rejestr produktu. Dziś chciałbym przybliżyć temat jakości rejestru produktu. Dobry rejestr produktu jest DEEP. Akronim DEEP został stworzony przez Romana Pichlera i Mike’a Cohena ułatwiający zapamiętanie kryteriów służących do oceny jakości rejestru produktu. DEEP oznacza: Detailed appropriately – wystarczająco szczegółowy, Estimated – szacunkowy Emergent – nowo powstający (podaję za Pichlerem [2]) Prioritized – zawiera

Pisząc o Scrum nie można zapomnieć o historyjkach użytkownika. Co prawda  Scrum nie określa sposobu opisywania elementów rejestru produktu i pozwala na dodanie tam różnych artefaktów to historyjka użytkownika stałą się jednym z symboli metodyki Scrum. „User story, czyli historia użytkownika, opowiada o kliencie lub użytkowniku korzystającym z produktu. Zawiera imię, krótki opis oraz kryteria akceptacji