Tworzenie estymacji w Scrum służy do szacowania stopnia skomplikowania i czasu potrzebnego do wykonania zadań. Oszacowania dokonuje wspólnie Scrum Team na podstawie swojego dotychczasowego doświadczenia. Dlatego też im bardziej doświadczony Scrum Team, tym trafniejsze są jego estymacje. Scrum Team uzgadnia planowany czas wykonania zadań podczas Sprint Planningu pamiętając jednak, że nie jest on traktowany jako zobowiązanie, lecz prognoza, której trafność mogą zaburzyć niespodziewane trudności w realizacji zadań.

Estymacja i Story Points w Scrum – omówione zagadnienia:

  1. Wprowadzenie
  2. Znaczenie Story Points w Scrum
  3. Relatywne techniki estymacji
  4. Podsumowanie

Wprowadzenie

Na każdym Sprint Planningu, Product Owner przedstawia zespołowi nowe User Stories. Product Owner wybiera je z Backlogu Produktu do realizacji w najbliższym Sprincie. Zaś członkowie Scrum Team wspólnie oceniają ilość pracy potrzebną do wykonania tej nowej porcji zadań. Zadanie to nazywane jest estymacją, wyceną wymagań, bądź szacowaniem.

Wydawać by się mogło, że najprostszym sposobem estymacji jest określenie czasu potrzebnego do wykonania zadania w godzinach lub dniach. Jednak praktyka i badania prowadzone już od lat ’40 XX wieku dowodzą czegoś innego. Ludzie nie są w stanie trafnie szacować czasu potrzebnego na realizację nawet bardzo dobrze zdefiniowanych zadań. Poza tym ilość godzin potrzebnych do realizacji zadania jest zależna od tego, kto to zadanie wykonuje, oraz co zostało – lub nie zostało – zrobione wcześniej. Dlatego też w Scrum stosuje się zazwyczaj jednostki zwane Story Points.

Znaczenie Story Points w Scrum

Każdy Zespół Developerski wypracowuje w praktyce wartość jednostki Story Point bazując na swoich wcześniejszych doświadczeniach oraz porównaniu wielkości poszczególnych zadań, czyli kierując się zasadą empiryzmu. Najczęściej podczas Sprint Planningu Scrum Master wybiera jedno lub kilka przykładowych już zrealizowanych User Stories, które stanowią punkt odniesienia dla określenia wartości User Stories wybranych do realizacji.

Zadaniom nie można więc przypisać wartości w Story Points niezależnie od ich kontekstu. Przykładowo, jeśli pierwszemu zadaniu przypisana zostanie wartość 10, kolejne zostanie oszacowane w odniesieniu do niego jako większe bądź mniejsze. W ten sposób w ramach jednego projektu realizowanego przez Scrum Team, wszystkie zadania w Product Backlogu są odnoszone do siebie nawzajem. Oznacza to, że podobne zadania realizowane przez jeden Zespół Developerski otrzymają podobną liczbę punktów.

Story Points są jednostkami relatywnymi.Oznacza to, że:

  1. Wartość Story Point odnosi się wyłącznie do zadań wykonywanych przez konkretny Scrum Team. Story Points opisują prędkość realizacji zadań jednego zespołu. Innymi słowy, User Story oszacowana na 10 Story Points przez zespół A może zostać oszacowana na 50 Story Points przez zespół B. Dzieje się tak, ponieważ, jak wspomnieliśmy ich wartość estymowana jest na podstawie i w odniesieniu do innych zadań wykonywanych przez ten zespół, a także jego doświadczenia z podobnymi zadaniami.
  2. Wartość Story Points zrealizowanych w jednym Sprincie nie może być podstawą porównania wydajności dwóch Scrum Teams. Aby uniknąć błędów przy zarządzaniu projektami realizowanymi w Scrum należy pamiętać, że Prędkość Zespołu Developerskiego wyrażona w Story Points zrealizowanych w jednym Sprincie nie może służyć do porównywania wydajności dwóch Zespołów. Mogły one bowiem wykonać w równoległych Sprintach identyczną pracę, którą jeden z Zespołów oszacował na 10, a drugi 50 Story Points.

Nie należy również zapominać, że estymacja zawiera wiele elementów niewiadomych i dokonywana jest na bazie niekompletnych danych. Z tego powodu przewidywania nawet bardzo doświadczonego Scrum Team mogą czasem mocno odbiegać od realnego nakładu pracy potrzebnego do realizacji User Story.

Relatywne techniki estymacji

Jakie są zatem najskuteczniejsze techniki estymacji stosowane w Scrum? Nie ma jednej uniwersalnej metody, która sprawdzi się w każdym Scrum Team.

Wśród technik estymacji używanych w metodykach zwinnych stosowane są najczęściej:

  1. Planning Poker.Ta najpopularniejsza metoda relatywna polega na użyciu gry w karty do oszacowania ilości pracy potrzebnej do wykonania zadania. Jej szczegółowe zasady i przebieg opisujemy w osobnym artykule.
  2. Team Estimation Game.Ten ciekawy i bardzo efektywny sposób estymacji również opisujemy w osobnym tekście. Polega on na przypisaniu User Stories przeznaczonych do realizacji w danym Sprincie odpowiednich wartości liczbowych wybranych z ciągu Fibonacciego.

Natomiast z reguły nie stosuje się w Scrum estymowania klasycznego (Absolute Estimation) używanego w tradycyjnym zarządzaniu projektami. Klasyczny sposób szacowania zadań polega bowiem na określeniu z góry osobomiesięcy, czasu trwania i kosztu całego projektu. Jest to proces długotrwały, trudny w realizacji, oraz wymagający udziału ekspertów, którzy niekoniecznie będą wykonywać zadania, których wartość oszacowali. Innymi słowy, jest on nie tylko żmudny, ale również wysoce nieefektywny.

Estimation and Story Points in Scrum

Podsumowanie

Estymacja jest bardzo ważną umiejętnością, którą musi posiąść dojrzały Scrum Team. Umiejętność szacowania ilości czasu i wysiłku potrzebnych do realizacji zadań jest trudną sztuką. Dlatego by uczynić ją bardziej efektywną, opracowano relatywne techniki estymacji: Planning Poker i Team Estimation Game. Wycenianie User Stories przy użyciu Story Points jest szybszą i skuteczniejszą metodą niż używanie innych miar estymacji. Należy jednak pamiętać, że ich wartość odnosi się jedynie do zadań wykonywanych przez konkretny Scrum Team. Ilość Story Points nie może być więc podstawą porównywania Prędkości różnych Zespołów Developerskich.

Zapoznaj się z kolejnym wpisem z ej serii: Jak działa Planning Poker?

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 23. Estymacja i Story Points w Scrum caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?