Rolą estymacji jest przede wszystkim dostarczenie informacji o potencjalnym czasie wykonania w oparciu o złożoność wymagań w produkt backlog. Wiedza która za sobą niesie estymacja jest istotna dla zespołu który w oparciu o nie zobowiązuje się dostarczyć w ramach iteracji określoną porcję nowych funkcjonalności (tzw. sprint commitment), jak również dla Produkt Ownera który musi zaplanować kalendarz releasów produktu. Zazwyczaj wstępny szacunek jest dodawany do itemu podczas tworzenia go w product backlog a modyfikowany podczas aktualizacji (np. rozszerzania zakresu o nowe przypadki biznesowe, podzielenia itemu na mniejsze, dospecyfikowania szczegółów funkcjonalnych czy technicznych). Estymacje na różnych poziomach budowania produktu niosą za sobą nieco inną informację. Estymacje na poziomie planowania releasów nie są aż tak zobowiązujące dla zespołu, są jedynie inicjalną wartością która jest brana w oparciu o wiedzę i przewidywania doświadczonych członków zespołu. Estymacje dostarczane podczas backlog grooming czy sprint planning muszą być znacznie dokładniejsze, przedstawiać orientacyjny czas pozwalający w oparciu o niego zaplanować ilość pracy w sprincie. Wszelkie estymacje powinny być dostarczone przez zespół który później będzie implementował dane wymaganie, w przeciwnym razie istnieje duże ryzyko, że estymacje nie pokryją się z czasami wykonania. Podsumowując to krótkie wprowadzenie należy zaznaczyć, iż Scrum sugeruje estymować itemy w oparciu o abstrakcyjne jednostki zamiast przypisywać itemom konkretne wartości czasu.
Jednostki estymacji itemów w product backlog:

• Rozmiar Tshirt (XS, S, M, L, XL,XXL)
• Story Points (zmodyfikowany ciąg Fibonacciego)
• Idealny czas (dni/godziny)

Estymowanie rozmiarem T-shirt – bardzo prosta technika estymowania polegająca na przypisywaniu każdemu z wymagań predefiniowanego rozmiaru (XS- bardzo mały, S-mały, M-średni, L-duży, XL-bardzo duży, XXL- ogromny). Jak dobrze widzicie są to wartości odpowiadające rozmiarom ubrań. Metoda bazuje na przełożeniu dobrze rozumianej przez ludzi różnicy pomiędzy rozmiarami ubrań na rozmair wymagań. Zaletą metody jest jej szybkość i prostota, każdy zespół bez większych problemów będzie w stanie przypisać każdemu wymaganiu wartość rozmiaru. Istotną kwestią aby robić to wydajnie jest ustalenie i zrozumienie wielkości bazowej dla XS tak aby zespół miał  odniesienie estymując itemy o większym rozmiarze. Minusami metody jest jej niedeterministyczność, itemy mogą mieć przydzielane rozmiary w oparciu o planning poker kartami z rozmiarami lub dyskusję członków zespołu, często podczas rozmowy rozmiar XL co innego znaczy dla kilku członków zespołu (nie wiedzą czy rozmiar L jest większy od M o 10% czy 20%). Kolejny minus to brak możliwości sumowania itemów, na koniec procesu szacowania mamy x itemów w każdym z rozmiarów. Metoda zalecana zespołom które dopiero zaczynają przygodę z estymacją, sugerowane aby po pewnym czasie zaczęły operować na  liczbach (najlepiej story points).
Estymowanie w story points – abstrakcyjna metoda estymacji itemów w produkt backlogu w oparciu o przypisywanie każdemu estymowanemu itemowi określonej liczby punktów. Tak samo jak w przypadku pozostałych metod należy na początku określić porcję pracy której będzie odpowiadać jeden story point a dopiero później w oparciu o tą wiedzę przypisywać liczbę punktów itemom o większej złożoności. Zaleca się ustalenie wspólnego zrozumienia story point dla wszystkich zespołów scrumowych w organizacji w przeciwnym razie jest prawie pewne, że zespoły przyjmą różną definicję 1 story point. Warto nadmienić, że ilość dostępnych do przypisania wartości jest ograniczona zmodyfikowanymi wartościami ciągu Fibonacciego (0.5,1,2,3,5,13,40,100) przez co proces estymacji idzie sprawniej. Ważny jest fakt, że zespół ustala między sobą końcową wartość estymacji dopóki wszyscy się na nią nie zgodzą. Posługując się techniką planning poker zespół przydziela odpowiednią liczbę strory points do każdego wymagania. Kolejną zaletą tej metody jest możliwość zliczania i sumowania story points wszystkich dostarczonych podczas iteracji itemów co przekłada się na trackowanie velocity zespołu. Z iteracji na iterację tendencja velocity, czyli suma story points wszystkich dostarczonych itemów powinna wzrastać. Natomiast dla pełnego badania velocity należy ustawić bramkę jakości tak aby monitorować liczbę błędów, aby zobaczyć czy velocity zespołu nie wzrasta kosztem jakości produktu, wiekszej ilości błędów. Jednostka szczególnie rekomendowana przez scrum.
Estymacja w idealnym czasie (dni/godziny) – ostatnia z prezentowanych metod to estymacja w oparciu o idealne dni lub godziny. Większość ludzi ma wspólne rozumienie idealnego dnia roboczego lub idealnej roboczogodziny. Zastosowanie tej metody wymaga jak w przypadku poprzednich wspólnego rozumienia co kryje się pod pojęciem idealnego dnia czy godziny. Zazwyczaj estymowanie w oparciu o idealne dni/godziny wymaga od zespołu bardzo dobrego zrozumienia wymagania i określonych predyspozycji. Trzeba mieć również na uwadze, że estymując wymagania w czasie idealnym możemy często spotkać się z przekroczeniem. Przykładem na to może być mecz piłkarski który trwa według idealnego czasu 90 minut lecz prawie zawsze po 90 minutach się nie kończy… zazwyczaj zajmuje więcej czasu.
Sugerowane jednostki estymacji na różnych poziomach rozwoju produktu: 

• Portfolio Management (portfel projektów) – stosujemy rozmiar
• Release Management (2-5 miesięcy) – stosujemy story points lub idealne dni
• Backlog Refinement Meeting (zakres 1-2 najbliższych sprintów) – stosujemy story points lub idealne dni
• Sprint Planning (zakres sprintu wraz z podzialem na taski) – stosujemy idealne godziny 

Drodzy praktycy Scrum a jak Wasze wymagania są estymowane na poszczególnych etapach ??