## Wstęp

Liczba mitów na temat [Scruma](/pl/blog/first-steps-to-learn-scrum/) wciąż rośnie. Jeśli mam być szczera, to różnego rodzaju metodologie, w których pojęcia związane ze [Scrumem](/pl/blog/first-steps-to-learn-scrum/) są używane nieprawidłowo, nie pomagają. 

W tym poście chciałabym wymienić najbardziej popularne mity na temat [Scruma](/pl/blog/first-steps-to-learn-scrum/), z którymi się spotkałam pracując jako Scrum Masterka. Wiem, że wciąż są one powtarzane i powielane pomiędzy firmami. W ramach edukacji i szerzenia wiedzy, postaram się obalić kilka z tych mitów. 

## Mit numer 1 - W Scrumie chodzi tylko o spotkania i role

Wiele organizacji decyduje się wprowadzić [Scruma](/pl/blog/first-steps-to-learn-scrum/), ale kończy się na tym, że wprowadzają tylko **role, spotkania i czasami artefakty.**
Jaki jest skutek tych działań? Skupiają się oni tylko na tym jak zmienić proces oraz sposób pracy bez używania [wartości Scruma](/pl/blog/letsscrumit.com/the-importance-of-scrum-values/) i z pominięciem **empirycznego sposobu działania**.
Tego typu praktyka ma swoją własną nazwę:  **Mechaniczny Scrum** i nie działa dobrze na dłuższą metę.

W [Scrumie](/pl/blog/first-steps-to-learn-scrum/) dużo ważniejsza jest **zmiana sposobu myślenia i inspirowanie zespołów** niż cokolwiek innego. Nie oznacza to, że spotkania, role i artefakty nie mają zupełnie znaczenia. Natomiast jeśli używamy ich bez odpowiedniego nastawienia i wartości, to nie jest to [Scrum](/pl/blog/first-steps-to-learn-scrum/).

Wprowadzanie [Scruma](/pl/blog/first-steps-to-learn-scrum/) i jakichkolwiek innych zmian w firmie, jest jak budowanie domu - potrzeba dobrych **fundamentów**.

## Mit numer 2 - Daily Scrum to tylko spotkanie sprawdzające postępy

[Daily Scrum](/pl/blog/scrum-events-3-daily-scrum/) jest często używany nieprawidłowo w [Scrumie](/pl/blog/first-steps-to-learn-scrum/) jako “status report meeting”, na którym każdy indywidualnie opisuje co zrobił, co zamierza zrobić i jakie ma przeszkody na swojej drodze. 
Możliwe, że teraz w głowie pytasz - “Czekaj, czekaj, ale co w tym złego? Czy to nie są dokładnie przykłady rozmów na Daily Scrum, które były wymienione w Scrum Guidzie w 2012 roku?”.

Odpowiedź na to pytanie brzmi “nie”. Brakuje najważniejszego elementu - [Celu Sprintu](/pl/blog/sprint-goal-why-do-we-need-it/). [Cel Sprintu](/pl/blog/sprint-goal-why-do-we-need-it/) jest często traktowany przez Zespoły Scrumowe jako niechciany, niepotrzebny element. Zdarza się, że zespół albo ma wiele celów (i nie wie na czym się skupić), albo nie wyznacza żadnego celu [Sprintu](/pl/blog//scrum-events-1-the-sprint/).

Co mówi o tym najnowsza wersja [Przewodnika po Scrumie - Scrum Guide](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf)?

> Celem Daily Scrum jest sprawdzenie postępów w dążeniu do osiągnięcia Celu Sprintu oraz w razie konieczności adaptacja Sprint Backlogu, czyli dostosowanie zaplanowanej pracy.  

[Daily Scrum](/blog/scrum-events-3-daily-scrum/) nie polega tylko na **sprawdzeniu indywidualnego postępu zadań**. To powinien być czas dla Deweloperów na rozmowę o tym jak **wspólnie radzą sobie z realizacją wyznaczonego [Celu Sprintu](/pl/blog/sprint-goal-why-do-we-need-it/)** oraz **jaki mają plan jako zespół na kolejny dzień**.

Podkreślam jeszcze raz, chodzi tutaj o ich **wspólny, zespołowy** plan, który pozwoli im na realizację wyznaczonego [Celu Sprintu](/pl/blog/sprint-goal-why-do-we-need-it/). Kiedy skupiamy się tylko na indywidualnych jednostkach, element **pracy zespołowej** zanika i zespół przestaje ze sobą współpracować. 

![Status report](img/status_report.jpg "Status report")

## Mit Numer 3 - Agile to Scrum

Używanie terminów **Scrum i Agile** to często spotykany błąd. Nie dziwię się temu, bo wyobrażam sobie, że zapamiętanie wszystkich terminów **Scrumowych** jest wyzwaniem. Co więcej, termin **Agile** stał się bardzo popularny i modny przez ostatnie lata.

Pozwólcie, że to wyklaruję: 

* Termin **Agile** został użyty po raz pierwszy w [“Manifeście Programowania Zwinnego”](https://agilemanifesto.org/iso/pl/manifesto.html) stworzonym w 2001 roku. Zawiera w sobie **wartości i zasady**, które ludzie piszący manifest chcieli promować podczas produkowania oprogramowania. Obecnie Agile nie jest terminem zarezerwowanym tylko dla branży IT. Pozostaje wciąż filozofią, którą można stosować w różnych branżach i sytuacjach. 
* **[Scrum](/pl/blog/first-steps-to-learn-scrum/) to ramy działania** stworzone do tworzenia wartości w kompleksowych środowiskach. Termin [Scrum](/pl/blog/first-steps-to-learn-scrum/) został użyty po raz pierwszy we wczesnych latach 90 przez Kena Schwaber i Jeffa Sutherland. 

**Te terminy nie są równoznaczne**.

[Scrum](/pl/blog/first-steps-to-learn-scrum/) może być uznawany za jedną z praktyk Agile. Dla wyjaśnienia, przedstawiam poniższy rysunek. Moim zdaniem świetnie pokazuje [relację pomiędzy Agile i Scrumem](/pl/blog/relationship-between-scrum-and-agile/). Mam nadzieję, że pomoże Ci lepiej zrozumieć różnicę między nimi. 

![Agile mindset vs Agile practices](img/Agile.png "Agile mindset vs Agile practices")

Źródło: https://www.agilesherpas.com/agile-mindset-marketing-agility/

## Mit Numer 4 - Sprint Review to tylko demo

Kolejnym znanym mitem jest traktowanie [Sprint Review](/pl/blog//scrum-events-4-sprint-review/) jedynie jako **demo** pracy, która była wykonana podczas [Sprintu](/pl/blog/scrum-events-1-the-sprint/). Oczywiście na tym spotkaniu chcemy pokazać co osiągnęliśmy, ale to nie jest jedyny cel tego spotkania. 

Co możemy przeczytać na ten temat w [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf)?

> Celem Sprint Review jest inspekcja efektów pracy wykonanej w Sprincie oraz wskazanie przyszłych zmian. Scrum Team prezentuje rezultaty swojej pracy kluczowym interesariuszom, omawiane są także postępy w dążeniu do Celu Produktu.
>
> Podczas tego wydarzenia Scrum Team wraz z interesariuszami oceniają to, co zostało zrealizowane podczas Sprintu oraz zmiany, jakie zaszły w ich otoczeniu. Na podstawie tych informacji uczestnicy wspólnie ustalają, co należy robić w następnej kolejności. 

[Sprint Review](/pl/blog/scrum-events-4-sprint-review/) to kolejna możliwość **inspekcji**, ale także bardzo ważny moment w [Sprincie](/pl/blog/scrum-events-1-the-sprint/), kiedy Zespół Scrumowy może współpracować z interesariuszami i uzyskać od nich **informację zwrotną** na temat wartości, która była dostarczona. Nie chcemy tylko pokazać co było zrobione i przejść dalej do kolejnego [Sprintu](/pl/blog/scrum-events-1-the-sprint/).

To powinien być moment **zatrzymania i refleksji** na temat tego co osiągnęliśmy. Chcemy także zaktualizować [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) uwzględniając informację zwrotną interesariuszy oraz zaplanować przyszły kierunek działań.

## Mit numer 5 - Scrum Master nic nie robi

To jest jeden z najbardziej bolesnych mitów dla mnie jako [Scrum Masterki](/pl/blog/scrum-roles-3-scrum-master/), ponieważ wiem jak wiele rzeczy, które robi [Scrum Master](/pl/blog/scrum-roles-3-scrum-master/) jest **niewidocznych** i **niedocenianych** przez ludzi. 

Oczywiście, nie przeczę, są ludzie, którzy nie wykonują swojej pracy dobrze i może oni rzeczywiście nic nie robią. Ale jeśli mam być szczera  [dobry Scrum Master](/pl/blog/secrets-of-the-successful-scrum-master/) **nie ma być gwiazdą, o której jest głośno**. 

Jest wiele małych kroków, które muszą być zrobione przez SM każdego dnia, które są najzwyczajniej **niewidoczne** dla zewnętrznego obserwatora. Mówię na przykład o **zadawaniu odpowiednich pytań**, **rozmowach** z indywidualnymi osobami, **coaching Właściciela Produktu**, szukanie technik, które mogą pomóc Zespołowi Scrumowemu, **analizowanie** zachowań i sytuacji, przygotowywanie do warsztatów i wiele innych. 

Także mam nadzieję, że teraz jest to już jasne i klarowne [Scrum Master](/pl/blog/scrum-roles-3-scrum-master/) to nie jest osoba, która tylko pije kawę i rozmawia. Aczkolwiek dużo kawy i rozmowy z wieloma ludźmi są wpisane w tę rolę. 

![Kawa](img/coffee.jpg "Kawa")

## Podsumowanie

Jeśli wierzyłaś/eś w którykolwiek z powyższych mitów, mam nadzieję, że nauczyłaś/eś się dzisiaj czegoś nowego. 

* [Scrum](/pl/blog/first-steps-to-learn-scrum/) to zasady działania, a nie tylko spotkania i role
* [Daily Scrum](/pl/blog/scrum-events-3-daily-scrum/) to nie jest status report meeting.
* [Sprint Review](/pl/blog/scrum-events-4-sprint-review/) to nie tylko demo. 
* Agile nie jest równoznaczny ze [Scrumem](/pl/blog/first-steps-to-learn-scrum/).
* [Scrum Master](/pl/blog/scrum-roles-3-scrum-master/) robi dużo więcej niż picie kawy.

Czy znasz jeszcze jakieś inne ciekawe mity na temat Scruma? Zachęcam Cię do podzielenia się nimi w komentarzu, bądź na mediach społecznościowych Let’s Scrum it.

Czy Agile to to samo co Scrum? Czy kiedykolwiek myślałaś/eś, że Daily Scrum to spotkanie sprawdzające tylko progress pracy tzw. “Status meeting”, a Sprint Review oznacza demo? To są jedne z mitów, które obalam w tym artykule. 

5 najczęstszych mitów na temat Scruma

## Wstęp

[Scrum](/pl/blog/first-steps-to-learn-scrum/) lub inne praktyki [Agilowe](https://agilemanifesto.org/iso/pl/manifesto.html) stały się bardzo popularne przez ostatnie 10-20 lat. Coraz więcej organizacji decyduje sie na **”Transformację Agile”**. Co to znaczy w rzeczywistości? W wielu przypadkach jest to tylko zmiana języka w organizacji, ale podejście do pracy i ludzi pozostaje takie samo.

Na szczęście są firmy, które naprawdę chcą działać i **zmieniają swój sposób myślenia, pracy i dostarczania** produktów. Oczywiście zmiana to proces i nie da się wdrożyć [Scruma](/pl/blog/first-steps-to-learn-scrum/) lub jakichkolwiek innych [praktyk zwinnych](https://agilemanifesto.org/iso/pl/manifesto.html) bez popełniania błędów. 

Dzisiaj chciałabym pokazać **7 znaków zwiastujących problemy w Zespole Scrumowym**. Bądź ostrożna jeśli zauważysz je w swoim zespole. Prawdopodobnie oznacza to, że jakieś elementy [Scruma](/pl/blog/first-steps-to-learn-scrum/) zgubiły się podczas implementacji. Ale nie przejmuj się! Zawsze możesz zastosować **empiryczne podejście** i sprawdzić co nie działa oraz zaaplikować potrzebne zmiany. 

## 1. Właściciel Produktu lub Scrum Master przypisujący pracę

Jedną z większych różnic pomiędzy tradycyjnym dostarczaniem produktów (Waterfall) a [Scrumem](/pl/blog/first-steps-to-learn-scrum/) jest **samozarządzanie** oraz **samoorganizacja** samoorganizacja Zespołu Scrumowego. 

Jeśli kiedykolwiek dostrzeżesz, że [Właściciel Produktu](/pl/blog/scrum-roles-2-product-owner/) lub [Scrum Master](/pl/blog/scrum-roles-3-scrum-master/) **przypisuje elementy Product Backlogu do ludzi**, jest to zawsze zły znak. Oznacza to, że zespół nie ma autonomii, aby decydować jak będzie pracować i nie jest samozarządzający.

[Właściciel Produktu](/pl/blog/scrum-roles-2-product-owner/)  powinien dać znać zespołowi tylko **Co** potrzebuje być zrobione, ale **Jak** to dokładnie będzie zrobione i **Kto** będzie pracować nad konkretnym zadaniem, to już jest decyzja [Deweloperów](/pl/blog/scrum-roles-1-development-team/) w Zespole Scrumowym. 
[Scrum Master](/pl/blog/scrum-roles-3-scrum-master/) także nie powinien kontrolować zespołu i przypisywać komukolwiek zadań. To powinna być osoba,która wspiera zespół i uczy jak mają być samozarządzający. Wiem, że łatwo się to mówi lecz wielu [Scrum Masterów](/pl/blog/scrum-roles-3-scrum-master/) , którzy byli kiedyś Project Menedżerami ma problem z odpuszczeniem kontroli. Ale **nie ma innego wyjścia** jeśli naprawdę chcesz pomóc zespołowi.

## 2. Brak transparentności

Co mam na myśli pisząc “brak transparentności”? O rany! Jest tyle rzeczy, które ludzie potrafią ukrywać. 

Jednym ze złych znaków w Zespole Scrumowym jest **rozmawianie o problemach za plecami danej osoby**, zamiast rozmawiać o tym z całym zespołem na [Retrospektywie Sprintu](/pl/blog/scrum-events-5-sprint-retrospective/). Może to oznaczać, że zespół **nie ma wystarczająco zaufania do siebie**, aby móc rozmawiać o problemach. 

Problemy z transparentnością mogą być także związane z komunikacją z klientami np. Zespół Scrumowy ukrywający problemy związane z tworzeniem produktu, przez co interesariusze myślą, że wszystko jest w porządku. 

W obu przypadkach, problemy wyjdą na jaw w pewnym momencie, a ukrywanie rzeczy nie przyniesie korzyści. W takich sytuacjach zdecydowanie polecam **bycie szczerym i rozmawianie o tym z czym zespół się zmaga**. Nawet jeśli nie będzie to komfortowe dla ludzi!

![plotkowanie](img/gossip.jpg)

## 3. Brak Celu Sprintu - wszystko jest priorytetem

Jeśli zapytasz swojego [Właściciela Produktu](/pl/blog/scrum-roles-2-product-owner/) lub Zespół Scrumowy - **”Co jest dla nas najwyższym priorytetem?”** a oni odpowiedzą **”Wszystko!”**, jest to zawsze zły znak. Ale to nie koniec. Nawet jeśli odpowiedzą w ten sposób, ale mają **[Cel Sprintu](/pl/blog/sprint-goal-why-do-we-need-it/)** i na końcu są w stanie wybrać najważniejsze elementy Product Backlogu, to powinno być w porządku. 

Problem zaczyna się wtedy, gdy **Zespół Scrumowy nie ma Celu Sprintu w trakcie Sprintu** i myślą oni, że wszystko w [Sprint Backlogu](/pl/blog/scrum-artifacts-2-sprint-backlog) jest najważniejsze. 

Jaki jest rezultat takiego myślenia? **Multitasking i brak skupienia** podczas [Sprintu](/pl/blog/scrum-events-1-the-sprint). \*\*Cel Sprintu jest świetnym artefaktem, ponieważ pomaga [Deweloperom](/pl/blog/scrum-roles-1-development-team/) w skupieniu i kieruje ich podczas każdej decyzji, którą podejmują w trakcie [Sprintu](/pl/blog/scrum-events-1-the-sprint).

## 4. Zbyt wiele osób w Zespole Scrumowym

Bazując na ostatniej wersji [Przewodnika po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf), Zespół Scrumowy powinien liczyć max. 10 osób. Dlaczego?

> Jak wynika z naszego doświadczenia, mniejsze zespoły na ogół lepiej się komunikują i są bardziej produktywne.

Jeśli Zespół Scrumowy liczy więcej niż 10 osób, jest to zły znak. Najczęściej oznacza to, że **komunikacja** między członkami zespołu dzie działa. Czasami może się wydawać, że wszystko jest w porządku, ale w rzeczywistości zbyt duży zespół sprawia, że można pominąć **potrzeby członków zespołu**, ponieważ nie ma wystarczająco czasu i przestrzeni, aby każdy dzielił się z innymi swoimi myślami. 

![pusty zeszyt](img/blank.jpg "pusty zeszyt")

## 5. Product Backlog nigdy nie jest gotowy na Planowanie Sprintu

Ten problem występuje często i zdecydowanie jest to oznaka problemów. Jeśli [Product Backlog](/pl/blog/scrum-artifacts-1-product-backlog/) nie jest gotowy na [Planowanie Sprintu](/pl/blog/scrum-events-2-sprint-planning/) i zespół nie wie na czym powinien się skupić, [Sprint](/pl/blog/scrum-events-1-the-sprint) prawdopodobnie będzie bardzo chaotyczny.

Kiedy mówię, że **[Product Backlog](/pl/blog/scrum-artifacts-1-product-backlog/) jest gotowy**, nie oznacza to, że jest w pełni zdefiniowany. Oznacza to tylko, że elementy backlogu, które są na szczycie, są **zdefiniowane wystarczająco**, aby zespół mógł zacząć pracę nad nimi. 

Oznacza to również, że [Product Owner](/pl/blog/scrum-roles-2-product-owner/) ma klarowną wizję produktu i będzie ona prowadzić zespół w dalszych działaniach. Powinniśmy unikać tak bardzo jak to możliwe \*\*chaotycznego [Product Backlogu](/pl/blog/scrum-artifacts-1-product-backlog/), który nie służy Zespołu Scrumowemu.

## 6. Story points tłumaczone na godziny

Pozwólcie, że wyjaśnię - **story points nie są częścią Scruma**. Ale mogą być używane przez Zespół Scrumowy do szacowania i planowania ich pracy. Zatem jeśli Zespół Scrumowy zdecyduje się używać story points (szacowania w punktach), **NIGDY nie powinni tłumaczyć ich na godziny**. Dlaczego? Powód jest bardzo prosty. Godziny to **szacowanie absolutne**, a story points są **relatywnym sposobem szacowania**. 

**Co to oznacza?**

Estymowanie absolutne jest wykonane w absolutnych wartościach np. godzinach. Jako ludzie, jesteśmy bardzo **słabi w szacowaniu złożonych zadań w godzinach**. 

Jeśli chodzi o relatywną estymację, to szacowanie nie jest związane tylko z **wysiłkiem** włożonym w realizację zadania i w związku z tym nie powinniśmy tłumaczyć punktów na godziny. Musimy wziąć też pod uwagę **ryzyko, niepewności, technologię oraz wolumen**.

Wyobraź sobie, że zdecydowałaś, że 1 story point oznacza jakąś liczbę godzin. W tej sytuacji w rzeczywistości nie stosujesz relatywnej estymacji. To jest wciąż niezmienne szacowanie w godzinach. 

Kiedy używamy story points do szacowania, te estymaty będą różne w zależności od zespołu, ich wiedzy, umiejętności i rzeczy, które wiedzą na temat zadania czy historyjki. 

Szacują oni biorąc pod uwagę wszystkich członków zespołu. Zatem jedna osoba może pracować nad historyjką przez 8 godzin, bo jest nowa i musi się nauczyć danej technologii. Tymczasem inny członek zespołu mógłby zrobić to 3 godziny, ponieważ jest doświadczony i ta technologia jest dla niego prosta.

To jest jeden z przykładów jak działa estymacja. Jest to także świetna możliwość dla [Deweloperów](/pl/blog/scrum-roles-1-development-team/) do dyskusji na temat poszczególnych elementów backlogu oraz do wyklarowania niewiadomych.

Tłumaczenie story points na godziny nie daje żadnej wartości, a dodaje ryzyka mikro menedżmentu i późniejszej weryfikacji przez kogoś, czy dane zadanie było ukończone w planowanym czasie.
 
## 7. Retrospektywa Sprintu bez akcji

To kolejny znany problem i chciałabym go tutaj podkreślić, ponieważ **zatrzymuje to Zespół Scrumowy przed rozwojem**. Najczęściej spotykanym scenariuszem jest [Retrospektywa](/pl/blog/scrum-events-5-sprint-retrospective) na której mówi się o tym co poszło dobrze, źle oraz co powinno być usprawnione. Problem pojawia się wtedy, gdy mówimy o problemach, pomysłach na usprawnienie, ale nie kończymy spotkania z jasnymi **akcjami** do wykonania. 

Bazując na [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf):

>Scrum Team określa zmiany najbardziej pożądane pod kątem poprawy swojej efektywności. Najbardziej znaczące usprawnienia wprowadza się jak najszybciej. Można je wręcz włączyć do Sprint Backlogu na kolejny Sprint.

Powinniśmy określić zmiany, które powinny być wdrożone i jak najszybciej je wdrożyć. Bez tego, cała dyskusja jest tylko zmarnowaniem czasu i wówczas [Retrospektywa](/pl/blog/scrum-events-5-sprint-retrospective) nie daje wartości, którą powinna dostarczać. 

Oczywiście, jeśli nie ustalamy akcji, to jest też to oznaka czegoś. Co się za tym kryje? Czy mamy wystarczająco **przestrzeni w Sprincie**, żeby pracować nad **usprawnieniami**? Czy firma wspiera nas w dokonywaniu **zmian**? Czy czujemy się **częścią zespołu** i mamy **motywację**, aby wprowadzać zmiany na lepsze?

To są pytania, które **warto sobie zadać**, jeśli rozpoznamy taki problem w swoim zespole.

## Podsumowanie 

Ten post miał na celu podsumowanie znaków problemów w Zespole Scrumowym, aby **pomóc Ci je rozpoznać** i zacząć je adresować. 

To koniec artykułu, ale zdecydowanie nie jest to **koniec znaków problemów** w zespołach. Czy kiedykolwiek doświadczyłaś problemów, które wypisałam? Jak sobie z nimi poradziłaś? Czy są jakieś inne, które znasz i możesz wymienić?

[Embed](https://www.instagram.com/reel/Ci2YR1qjaze/?utm_source=ig_embed&utm_campaign=loading)


Czy zauważyłaś jakieś problemy po wdrożeniu Scruma? Zastanawiasz się co możesz zmienić, aby pomóc Twojemu zespołowi się doskonalić? Przeczytaj ten artykuł i sprawdź, czy czasem nie wpadliście w którąś z 7 pułapek wymienionych przeze mnie. 

7 znaków zwiastujących problemy w Zespole Scrumowym

## Wstęp

Jest wiele powodów dla których stworzyłam tego bloga. Jednym z nich jest pomaganie Ci w zrozumieniu najważniejszych informacji dotyczących [Scruma](/pl/blog/first-steps-to-learn-scrum). Oczywiście, możesz zrobić to także poprzez przeczytanie [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf), ale nie znajdziesz tam przykładów z życia wziętych.

W ostatnich dwóch seriach postów opisałam wszystkie spotkania i role Scrumowe. Czas wyjaśnić Scrumowe artefakty. Wspomniałam o nich nieco w moich poprzednich artykułach, ale pozwól, że wyjaśnię więcej.

Zacznijmy od króla Scrumowych artefaktów, czyli **Product Backlogu**. 

* Ten post jest zaktualizowany na podstawie [Przewodnika po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) 2020.

## Co to jest Product Backlog?

Product Backlog jest naprawdę królem, ponieważ żadne z zadań Scrumowych nie mogłoby się wydarzyć bez niego. Wyobraź sobie, że pieczesz ciasto. Możesz to zrobić bez przepisu, ale musisz przynajmniej wiedzieć jakie składniki są potrzebne do tego ciasta. Product Backlog jest dla produktu tym, czym jest lista składników dla ciasta.

Bazując na [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf):

> Product Backlog to ewoluująca, uporządkowana lista tego, co jest konieczne do ulepszenia produktu. To jedyne źródło pracy podejmowanej przez Scrum Team.

## Jedyne źródło wymagań

Dlaczego Product Backlog - uporządkowana lista ze wszystkimi “składnikami” jest taką ważną częścią [Scruma](/pl/blog/first-steps-to-learn-scrum)?

Po pierwsze, jest to **jedyne źródło prawdy**, które mówi o tym, co jest wymagane w produkcie. Czy kiedykolwiek doświadczyłaś sytuacji, w której wiele ludzi pyta Cię o tę samą rzecz, ale wszyscy mają inne wymagania? Product Backlog jako lista pomaga w zebraniu tych wszystkich wymagań w jedno miejsce i uporządkowaniu ich. Minimalizuje ryzyko związane ze sprzecznymi wymaganiami lub z brakiem widoczności zmian.

Co więcej, dobrze zarządzany Product Backlog, wspiera **przejrzystość/transparentność** - jedną z 3 filarów empiryzmu, który jest podstawą [Scruma](/pl/blog/first-steps-to-learn-scrum).

![Lista](img/list.jpg "Lista")

## Kto powinien zarządzać Product Backlogiem

Jest jedna rola w [Scrumie](/pl/blog/first-steps-to-learn-scrum) odpowiadająca za zarządzanie Product Backlogiem -  [Product Owner](/pl/blog/scrum-roles-2-product-owner/). Ona lub on decyduje o tym co się znajduje w Product Backlogu oraz czy jest on dostępny dla wszystkich i uporządkowany.  [Product Owner](/pl/blog/scrum-roles-2-product-owner/) upewnia się, że Product Backlog jest widoczny i jasny dla każdego członka Zespołu Scrumowego.

## Stałe wymagania vs Product Backlog

W tradycyjnym zarządzaniu projektami, wszystkie wymagania są wymienione w dokumencie związanym z zakresem pracy na początku projektu i pozostają one niezmienne. 

Zwinne (Agile) podejście promuje jednak inny sposób pracy z klientami i ich potrzebami. Wstępne wymagania są wypisane w Product Backlogu, ale lista ta zmienia się wraz ze zmianami związanymi z produktem i sytuacją na rynku. Oznacza to, że Product Backlog jest artefaktem, który jest stale aktualizowany i nigdy nie jest skończony.

Odpowiadanie na zmiany jest ważniejsze w [Scrumie](/pl/blog/first-steps-to-learn-scrum) niż podążanie za ustalonym planem. Dlaczego? Ponieważ wszystko co się wiąże z produktem może ulec zmianie: użytkownicy, sytuacja rynkowa, strategia firmy. Nawet rzeczy takie jak światowa pandemia - COVID19 mogą zmienić całkowicie sposób użytkowania produktu. W związku z tym Product Backlog jest dynamiczny i istnieje tak długo jak istnieje produkt.

## Product Backlog - co zawiera?

Ok, mamy magiczną listę zwaną Product Backlogiem, ale co się kryje w środku? Najlepsza odpowiedź to **wszystko co wiąże się z produktem**.

Bazując na [Przewodniku po Scrumie - 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Polish.pdf):

> Backlog Produktu jest listą wszystkich cech, funkcji, wymagań, ulepszeń i korekt, które reprezentują zmiany wprowadzane do produktu w jego przyszłych wydaniach. 

W najnowszej wersji nie jest to określone. Jest to zapewne celowy zabieg, aby nie ograniczać sposobu interpretacji Product Backlogu. 

Jest wiele sposobów przedstawiania Product Backlogu. Ja podzielę się z Tobą przykładami, których doświadczyłam. Na liście, której używał jeden z moich Zespołów Scrumowych, pojawiły się poniższe elementy:

* **Epic** - duża część funkcjonalności, która może być tworzona przez kilka Sprintów. Jest to ogólny zarys poszczególnych elementów produktu.

Zanim przejdę do opisywania dalszych elementów, chciałabym zaznaczyć, że często epiki (czasem razem z features, których tu nie wymieniłam) są używane do tworzenia tzw “Sprint Roadmap”, czyli Planu działania Sprintów, aby mieć mniej więcej zarys tworzenia produktu. 

* **User Story/Historyjka użytkownika** - historyjki, to elementy Product Backlogu, które opisują konkretną potrzebę użytkownika. Zazwyczaj historyjka powinna być na tyle duża/mała, aby móc ją zrealizować w trakcie jednego Sprintu. 

Powinna ona zawierać:
- Informację o tym kim jest użytkownik
- Opis co ten użytkownik chciałby zrobić, jaką ma potrzebę, którą chce zaspokoić
- Opis celu jego działania.

Przykładowo: Jako (użytkownik), chcę (co chce zrobić), aby móc (cel tego działania).

\- Kryteria akceptacji - wszystko co jest wymagane od historyjki. Można to ubrać w format **given, when, then** - zakładając, że (kontekst), kiedy (akcja), wówczas (wynik tej akcji, co się wydarzy). Ten format jest tylko przykładem. Najważniejsze jest to, aby te kryteria wyjaśniały co jest wymagane w danej historyjce.
- Rozmiar - wyestymowany przez [Deweloperów](/pl/blog/scrum-roles-1-development-team/) na [Planowaniu Sprintu](/pl/blog/scrum-events-2-sprint-planning/).

* **Bug** - opisuje on problem związany z jakąś funkcjonalnością w backlogu. 
* **Zadanie** - Istnieje możliwość, że są techniczne zadania, które są wymagane do rozpoczęcia pracy nad produktem, a nie mieszczą się w historyjkach. Nie jest to norma, ale są zespoły, które używają tasków/zadań właśnie w ten sposób.
* **Podzadanie** - Historyjki mogą zawierać wiele mniejszych pod-zadań, które muszą być zrealizowane aby historyjka została ukończona. Jest to tak zwane “Jak”, które ustalają [Deweloperzy](/pl/blog/scrum-roles-1-development-team/). To oni ustalają wszystkie akcje, które są wymagane do ukończenia historyjki, aby móc uznać ją za “ukończoną”. Definicja “Ukończenia” jest używana przez nich do ustalenia jaki jest status danej historyjki.

Podane powyżej elementy, to tylko przykłady jak można opisać Product Backlog. Jest wiele innych sposobów. Na poniższym obrazku wyszczególniłam także inne elementy, które są używane przez niektóre zespoły.
Pamiętaj, że to jak wygląda backlog, to decyzja  [Product Ownera](/pl/blog/scrum-roles-2-product-owner)  i zespołu. Najważniejsze, aby backlog pomagał w dostarczaniu wartości.

![Product-Backlog](img/product-backlog.drawio-1-.png "Product backlog")

## Doskonalenie Product Backlogu (Refinement)

Kiedy jest potrzeba dokonania zmian w Product Backlogu, [Właściciel Produktu](/pl/blog/scrum-roles-2-product-owner/) oraz [Developerzy](/pl/blog/scrum-roles-1-development-team/) spotykają się, aby zrobić tzw. refinement - doskonalenie. Co to oznacza? Aktualizują detale historyjek, estymaty, czy też ich kolejność. Analizują poszczególne historyjki, współpracują i dokonują wszelkich potrzebnych zmian.

Zgodnie z [Przewodnikiem po Scrumie 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Polish.pdf):

> Doskonalenie zazwyczaj zajmuje nie więcej niż 10% czasu Zespołu Deweloperskiego w Sprincie. Nie zmienia to faktu, że elementy Backlogu Produktu mogą być uaktualniane w każdej chwili przez Właściciela Produktu lub za jego zgodą. 

10% nie jest wymienione w najnowszej wersji Scrum Guide. Znajdziemy tam tylko informację o tym, aby refinement traktować jako ciągłą/trwającą aktywność. 

## Kolejność w Product Backlogu

Elementy Produkt Backlogu, które są na jego szczycie powinny być najlepiej opisane. Im niżej jest położony element (historyjka, task itp), tym mniej detali jest wymaganych. Oznacza to, że Product Backlog nie musi być w pełni opisany od początku pierwszego Sprintu. Jedyna rzecz, która wtedy ma znaczenie, to elementy, które są najwyżej położone.

Zgodnie z  [Przewodnikiem po Scrumie z 2020](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf):

> Elementy Product Backlogu, które mogą zostać Ukończone przez Scrum Team w trakcie jednego Sprintu, zostają uznane za gotowe do wybrania podczas Sprint Planningu.

Przez “gotowe” - mają oni na myśli wystarczająco opisane, aby [Deweloperzy](/pl/blog/scrum-roles-1-development-team) mogli nad nimi pracować. 

![Kolejność](img/order.jpg "Kolejność")

## Podsumowanie

Najważniejsze informacje, które powinnaś zapamiętać z tego artykułu o **Product Backlogu**:

* Jest to **uporządkowana lista**, która jest jedynym źródłem wszystkiego co jest potrzebne w produkcie.
* Jest to **żyjący artefakt**, który jest aktualizowany kiedy występują zmiany oraz istnieje tak długo, jak istnieje produkt.
* [Właściciel Produktu](/pl/blog/scrum-roles-2-product-owner/) jest odpowiedzialny za zarządzanie Product Backlogiem: zawartości, kolejności, priorytetów itp.
* Product Backlog nie jest czymś **stałym** - jest nigdy nie skończony.
* Product Backlog może zawierać różnego rodzaju elementy np. **Epik, User Story, Task, Bug** itp.
* Product Backlog **Refinement** jest przeprowadzany w celu uzupełnienia detali w elementach Backlogu.
* Najwyżej położone elementy w Backlogu powinny mieć wystarczająco dużo detali, aby być **Gotowe**, co pozwoli [Developerom](/pl/blog/scrum-roles-1-development-team)  pracować nad nimi.

Ten pierwszy post w serii o Scrumowych artefaktach pozwoli Ci lepiej zrozumieć czym jest Product Backlog i jaką rolę pełni w Scrumie.

Artefakty Scrumowe #1 Product Backlog

## Wstęp

\*Ten artykuł został zaktualizowany na podstawie [Przewodnika Po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) z 2020 roku.

Moim [ostatnim artykułem](/pl/blog/scrum-events-1-the-sprint/) rozpoczęłam serię dotyczącą Spotkań Scrumowych i opisałam pierwsze spotkanie w Scrumie - **Sprint**. Jeśli jeszcze go nie przeczytałaś, zapraszam serdecznie do lektury, zanim zaczniesz ten post.

Dzisiaj chciałabym kontynuować serię opisując spotkanie, które  **inicjuje** [Sprint](/pl/blog/scrum-events-1-the-sprint/) - **Sprint Planning** - Planowanie Sprintu.

Proszę weź pod uwagę, że niektóre elementy **Sprint Planningu**, które będę opisywać nie są wymienione bezpośrednio w [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf).
W związku z tym, będę używać przykłady często spotykanych praktyk, lub moich własnych doświadczeń. 

## Sprint Planning - definicja i długość

Każdy  [Sprint](/pl/blog/scrum-events-1-the-sprint/) rozpoczyna się od spotkania, które nazywa się **Sprint Planning**, czyli planowanie Sprintu. Podczas tego wydarzenia, Zespół Scrumowy: [Deweloperzy](/pl/blog/scrum-roles-1-development-team), [Product Owner](/pl/blog/scrum-roles-2-product-owner) i [Scrum Master](/pl/blog/scrum-roles-3-scrum-master) wspólnie tworzą plan pracy na nadchodzącą iterację. 

Spotkanie ma określony limit czasowy (podobnie jak wszystkie inne wydarzenia w [Scrumie](/pl/blog/first-steps-to-learn-scrum) do maksymalnie 8 godzin na 1 miesiąc [Sprintu](/pl/blog/scrum-events-1-the-sprint/). Oczywiście w przypadku krótszych [Sprintów](/pl/blog/scrum-events-1-the-sprint/), ten czas jest odpowiednio dostosowywany.

Aby, pomóc Ci zrozumieć czym jest **Sprint Planning**, chciałabym kontynuować mają sportową analogię z poprzedniego artykułu. To spotkanie jest jak **początek sprintu** - (krótkodystansowego biegu). Jeżeli rozpoczniesz za szybko, przed sygnałem startowym, cały wyścig musi być zrestartowany z powodu falstartu. Z drugiej strony, jeśli zagapisz się i przeoczysz start biegu, może to zrujnować cały Twój bieg i rezultat końcowy.

Dokładnie tak samo jest w [Scrumie](/pl/blog/first-steps-to-learn-scrum). Zespół Scrumowy potrzebuje **pracować razem,** aby rozpocząć [Sprint](/pl/blog/scrum-events-1-the-sprint/). Jeśli ktoś zacznie przed innymi, nie będzie **przejrzystości** i wpłynie to bardzo na cały [Sprint](/pl/blog/scrum-events-1-the-sprint/). Dodatkowo, każde opóźnienia w starcie, nieporozumienia, niejasne wymagania mogą opóźnić [Sprint](/pl/blog/scrum-events-1-the-sprint/) i wpłynąć negatywnie na jego rezultaty.

## Dlaczego?

Pierwsza część Sprint Planningu powinna być skoncentrowana na wyjaśnieniu **“Dlaczego”** przez [Product Ownera](/pl/blog/scrum-roles-2-product-owner). W [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) jest ona wyjaśniona w ten sposób:

> Product Owner proponuje, jak zwiększyć wartość produktu oraz jego użyteczność w bieżącym Sprincie. Następnie cały Scrum Team współpracuje nad sformułowaniem [Celu Sprintu](/pl/blog/sprint-goal-why-do-we-need-it), który opisuje to, dlaczego dany Sprint jest wartościowy dla interesariuszy. [Cel Sprintu](/pl/blog/sprint-goal-why-do-we-need-it) musi zostać określony przed zakończeniem Sprint Planningu.  

Ja dodałabym jeszcze do tego opisu wyjaśnienie szerszego kontekstu związanego z produktem:

* Jak następny Sprint **wpłynie** na tworzenie produktu?
* Jakie są **zmiany** z poprzedniego Sprintu, które wpłynęły na górną część Product Backlogu? Co musi być wzięte pod uwagę podczas Sprint Planningu?

Z mojego doświadczenia wynika, że dużo łatwiej pracuje się nad czymś, jeśli znamy **szerszy kontekst** i rozumiemy **cel naszych działań**. Oczywiście detale związane z każdym elementem pracy, powinne być wyjaśnione w Kryteriach Akceptacji, ale oprócz tego ważne jest, aby Zespół Scrumowy rozumiał cały obrazek.

Pomocne może się okazać przedstawienie przez Product Ownera tzw. **Sprint Roadmap** (Mapy drogi Sprintów - planu działania) oraz wyjaśnienie Celu Produktu. Lubię analogię związaną z mapą drogi, ponieważ wyobrażam sobie, że Zespół Scrumowy zaczyna razem podróż. Dużo łatwiej osiągnąć pierwszy cel, jeśli mniej więcej wiemy o **kolejnych miejscach**, do których idziemy. Nawiasem mówiąc, jest to inny rodzaj roadmapy niż używana w Zarządzaniu Projektami. Ta jest tylko pewnym szerokim kontekstem, wizją opartą na velocity (prędkości) zespołu i może być zmieniana, kiedy następują zmiany.

![Sprint-Roadmap](img/roadmap.webp "Roadmap")

Następnym krokiem **Sprint Planningu** jest ustalenie [Celu Sprintu](/pl/blog/sprint-goal-why-do-we-need-it) przez Zespół Scrumowy. Jest to cel, który zamierzają oni zrealizować podczas najbliższej iteracji. [Cel Sprintu](/pl/blog/sprint-goal-why-do-we-need-it) powinien dostarczać wartość i być jasny dla każdego. Pomaga on zespołowi w skupieniu i w rozumieniu, dlaczego wykonują swoją pracę. 

## Co?

Po ustaleniu “Dlaczego” w [Sprincie](/pl/blog/scrum-events-1-the-sprint/), czas na rozmowę o tym “Co” będzie zrobione w trakcie [Sprintu](/pl/blog/scrum-events-1-the-sprint/). [Właściciel Produktu](/pl/blog/scrum-roles-2-product-owner) i [Deweloperzy](/pl/blog/scrum-roles-1-development-team) dyskutują nad tym jakie elementy z [Product Backlogu](/pl/blog/scrum-artifacts-1-product-backlog) będą realizowane w obecnym [Sprincie](/pl/blog/scrum-events-1-the-sprint/). Lista elementów wybranych do Sprintu to  **Sprint Backlog**.

Jeżeli nie jest to pierwszy [Sprint](/pl/blog/scrum-events-1-the-sprint/) tego zespołu, powinni oni mieć jakieś informacje potrzebne do planowania Sprintu tj:

* **Capacity - Przewidywana pojemność** - liczba godzin, w których członkowie zespołu będą dostępni podczas [Sprintu](/pl/blog/scrum-events-1-the-sprint/).
* **Velocity - Prędkość zespołu** w poprzednich Sprintach.
* **Ich Definicja Ukończenia** - w jaki sposób zespół wie, że jakiś element Backlogu jest ukończony.

To [Deweloperzy](/pl/blog/scrum-roles-1-development-team) decydują o tym ile elementów z Product Backlogu zostanie wybranych do  [Sprintu](/pl/blog/scrum-events-1-the-sprint/). Jest to jeden z pierwszych, ważnych momentów w [Scrumie](/pl/blog/first-steps-to-learn-scrum), kiedy to [Product Owner](/pl/blog/scrum-roles-2-product-owner) musi zaufać im, że wybiorą właściwą ilość pracy bazując na swojej ekspertyzie i poprzednich doświadczeniach. Nikt nie wie lepiej ile pracy mogą wykonać [Deweloperzy](/pl/blog/scrum-roles-1-development-team) w trakcie [Sprintu](/pl/blog/scrum-events-1-the-sprint/) oprócz ich samych.

## Jak?

Kiedy [Deweloperzy](/pl/blog/scrum-roles-1-development-team) wiedzą już jaki jest cel ich działań i zdecydowali co będzie zrobione, czas najwyższy, aby porozmawiać o tym **jak** to się stanie.

Sprawdźmy co o tym mówi [Przewodnik po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf):

> Dla każdego wybranego elementu Product Backlogu Developerzy planują pracę niezbędną do wytworzenia Incrementu zgodnego z Definicją Ukończenia. Często odbywa się to w ten sposób, że elementy Product Backlogu dzielone są na mniejsze części możliwe do wykonania w ciągu maksymalnie jednego dnia. Decyzja o sposobie tego podziału należy wyłącznie do Developerów. Nikt inny nie narzuca im, jak przekształcić elementy Product Backlogu w wartościowe Incrementy.

Nie jest to tutaj wymienione, ponieważ wydaje się to sprawą oczywistą, ale [Deweloperzy](/pl/blog/scrum-roles-1-development-team) potrzebują zdecydować jak będą **sprawdzać** codziennie czy posuwają się we właściwym kierunku ze swoją pracą. Jak zamierzają **sprawdzać swoją pracę, komunikować się** ze sobą? Będą się spotykać codziennie na Daily Scrumie, ale co więcej?

Są pewne elementy techniczne, które moim zdaniem powinny być przedyskutowane:

* W jaki sposób będą sprawdzać **postępy** swojej pracy? Czy będą używać Tablicy **Kanban**? Jeśli tak, to czy zamierzają używać kolumn “Do zrobienia”, “W trakcie”, “Zrobione” czy też jakichś innych, które lepiej odzwierciedlają ich pracę?
* Czy chcą posługiwać się **narzędziami** takimi jak Sprint Burndown, Burnup, aby sprawdzić, czy przybliżają się do osiągnięcia Celu Sprintu?
* A co z **Bugami**? Czy będą je w ten sposób nazywać? A może w firmie obowiązuje inne słownictwo? Jak zamierzają sobie radzić z jakimikolwiek błędami/problemami w trakcie tworzenia produktu?
* Jak będzie wyglądała **komunikacja** w Zespole Scrumowym? Czy planują się komunikować tylko twarzą w twarz, a może będą używać maili, MS Teams, Zoom, czy też innej platformy?

Jest oczywiście możliwe, że będzie więcej aspektów technicznych, które wymagają przedyskutowania. Myślę, że jest ważne, aby porozmawiać o nich i mieć wspólne zrozumienie zarówno komunikacji, jak i współpracy. Nie musi to być długa dyskusja. Ważne, aby zakończyła się wspólnym zrozumieniem.

![Jak](img/how.webp "Jak")

KIedy to wszystko jest już uzgodnione, [Deweloperzy](/pl/blog/scrum-roles-1-development-team) mogą zdecydować o **rozmiarze** poszczególnych elementów wybranych do Sprintu. Z mojego doświadczenia wynika, że może to być także część regularnego **Backlog Refinementu**. Istnieją różne sposoby estymowania pracy np. Planning Poker (przy użyciu ciągu Fibonacciego), estymowanie rozmiarami T-shirtów, Psów itp. 

Głównym celem tej aktywności jest miejsce na **wnikliwą dyskusję** na temat konkretnych elementów backlogu oraz używanie estymat do **kalkulowania Velocity.** Może ono być świetnym narzędziem w trakcie planowania kolejnego Sprintu.

Jeśli już wszystko jest przedyskutowane, zrozumiałe i zaplanowanie, **czas zabrać się do pracy.** Gdyby [Deweloperzy](/pl/blog/scrum-roles-1-development-team) odkryli, że nie wybrali wystarczająco dużo elementów, albo wybrali za dużo, bądź są jakieś potrzebne zmiany, mogą to negocjować z Product Ownerem. 

## Podsumowanie

Najważniejsze rzeczy do zapamiętania:

* Scrum Team [Deweloperzy](/pl/blog/scrum-roles-1-development-team) , [Product Owner](/pl/blog/scrum-roles-2-product-owner) i [Scrum Master](/pl/blog/scrum-roles-3-scrum-master)) powinni uczestniczyć w Sprint Planningu.
* Sprint Planning ma ograniczenie czasowe do **max 8 godzin** na miesięczny Sprint.
* [Product Owner](/pl/blog/scrum-roles-2-product-owner) powinien wyjaśnić **“Dlaczego?”** Sprintu - jaka jest jego wartość, a cały Zespół Scrumowy tworzy na tej podstawie  [Sprint Goal](/pl/blog/sprint-goal-why-do-we-need-it) - Cel Sprintu.
* PO i [Deweloperzy](/pl/blog/scrum-roles-1-development-team) dyskutują na temat tego, **co może być wybrane do Sprintu,** ale ostateczna decyzja jest po stronie Deweloperów.
* Wkładem do Sprint Planningu mogą być: **przewidywane capacity, velocity, Definicja Ukończenia.**
* [Sprint Goal](/pl/blog/sprint-goal-why-do-we-need-it)l i **Sprint Backlog** są wynikiem Sprint Planningu
* To ważne, aby  [Deweloperzy](/pl/blog/scrum-roles-1-development-team) przedyskutowali **jak zamierzają pracować w trakcie Sprintu** - wszystkie techniczne elementy: narzędzia, tablice, sposoby komunikacji.
* [Deweloperzy](/pl/blog/scrum-roles-1-development-team) mogą także **estymować** elementy Sprint Backlogu podczas tego spotkania (lub podczas **Backlog Refinementu)**.

To już drugi artykuł w serii o Spotkaniach Scrumowych. Pomoże Ci zrozumieć wszystkie aspekty Sprint Planningu: jaki jest cel tego wydarzenia, jak ono wygląda i o czym warto pamiętać na takim spotkaniu.

Wydarzenia Scrumowe #2 Sprint Planning

\*Ten artykuł był zaktualizowany zgodnie z [Przewodnikiem po Scrumie 2020](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf).

## Wstęp

[Scrum](/pl/blog/first-steps-to-learn-scrum/) zawiera **5 spotkań** (wymienionych poniżej), które są **określone czasowo** i mają na celu zminimalizować potrzebę dodatkowych spotkań. Tworzą one pewną stałość, **nawyk**, który zwiększa efektywność pracy.

* Sprint
* Planowanie Sprintu- Sprint Planning
* Daily Scrum
* Sprint Review
* Retrospektywa Sprintu

Kolejne 5 artykułów będzie opisywać każde z tych 5 spotkań. Spotkania [Scrumowe](/pl/blog/first-steps-to-learn-scrum/) nadają strukturę każdej iteracji. W ten sposób tworzymy **bezpieczne** środowisko pracy i stymulujemy **kreatywność** w zespole.

![Scrum Framework](img/scrum_framework.webp "Scrum Framework")

## Sprint - Definicja i Długość

Powołując się na [Przewodnik po Scrumie 2020](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf):

> Sprinty są pulsem Scruma. W Sprintach pomysły są przekształcane w wartość. Są to wydarzenia o ustalonej długości, trwają maksymalnie miesiąc dla uzyskania regularności. Nowy
> Sprint rozpoczyna się natychmiast po zakończeniu poprzedniego. 

Najlepszym sposobem na zrozumienie czym jest Sprint w [Scrumie](/pl/blog/first-steps-to-learn-scrum/) jest porównanie go do **sprintu w sporcie**. Jak wszyscy dobrze wiemy, sprint to **krótkodystansowy** bieg, skupiony na szybkim osiągnięciu celu.

Sprint w [Scrumie](/pl/blog/first-steps-to-learn-scrum/) działa dokładnie w ten sam sposób. Jest to krótki okres czasu (**maksymalnie jeden miesiąc**) skupiony na osiągnięciu **Celu Sprintu**, który wyznaczyliśmy sobie na początku **planowania** Sprintu.

Ważne, aby Sprinty były wystarczająco **krótkie**, aby móc **dostosować się** do zmieniającego się świata i uniknąć **ryzyka** związanego ze zbyt dużą **złożonością**. 

Wyobraź sobie, że biegniesz krótkodystansowo - widzisz metę i to **motywuje** Cię do tego, aby biec szybciej. Tymczasem bieg długodystansowy wymaga dużo więcej **planowania**. Nie chcemy zużywać całej energii na początku, aby móc mieć jej wystarczająco do końca. Łatwo popełnić ten błąd - biec za szybko kiedy zaczynamy i być za bardzo zmęczonym na końcu. Czasami podczas tego planowania możemy nie wziąć pod uwagę ważnego czynnika, który **zmieni** całkowicie nasz wynik końcowy. 

Podczas **tworzenia produktów**, lepiej jest działać w **krótszym okresie czasu.** W ten sposób unikamy ryzyka związanego z nagłymi **zmianami**, których nie wzięliśmy pod uwagę. Dlatego Sprint w [Scrumie](/pl/blog/first-steps-to-learn-scrum/) jest wystarczająco krótki, aby widzieć **horyzont/ Cel Sprintu**, ale wystarczająco długi, aby **stworzyć użyteczny increment.** 

![sprint](img/sprint.webp "sprint")

## Iteracja

W [Scrumie](/pl/blog/first-steps-to-learn-scrum/) promuje się **iteracyjny sposób pracy**, co oznacza, że wszystkie aktywności są w **cyklach**. Podczas **Sprintu** odkrywamy co działa, co powinno się zmienić i zmieniamy to. Kolejny Sprint zaczyna się **od razu** po poprzednim i daje to możliwość używania wiedzy, którą zdobyliśmy w poprzednim Sprincie.

Główną wartością **krótkich cyklów** jest możliwość **wczesnej informacji zwrotnej** od interesariuszy oraz możliwość **dostosowania** do rynku. 

## Rama

Scrum to **uproszczone ramy postępowania**. W związku z czym wyobrażam sobie Sprint jako **ramę,** która mieści wszystkie pozostałe elementy. Podczas **Sprintu**, Zespół Scrumowy jest skupiony na **obecnej iteracji** i wszystkie akcje są związane z **obecnym Sprintem:**

* Sprint Planning - czas do zaplanowania **Sprintu**
* Sprint Goal - co chcemy osiągnąć podczas **Sprintu**
* Sprint Backlog - elementy backlogu zaplanowane na **Sprint**
* Daily Scrum - planowanie codzienne w  **Sprincie**
* Sprint Review - podsumowanie tego co było zrobione w **Sprincie**
* Sprint Retrospective - sprawdzenie co działało i co powinno być usprawnione bazując na ostatnim **Sprincie**.

Jak widzicie, wszystkie akcje są skupione na obecnej iteracji czyli - **Sprincie**.

Oczywiście Produkt Owner potrzebuje mieć **długodystansową wizję** związaną z tworzeniem produktu oraz **kolejnymi Sprintami.** Dlatego też tworzy Product Backlog, który zawiera wszystkie elementy - także te, które są związane z **przyszłymi zmianami** w produkcie. Jego bądź jej rolą jest także utworzenie **Celu Produktu**, aby wskazać każdemu kierunek produktu.

Ważne, aby pamiętać, że Product Backlog jest elastyczny i może być zmieniany, poprawiany, a **Sprint Backlog** jest bardziej stały. Oczywiście może być wyklarowany, zmieniony, ale wymaga to zgody pomiędzy Product Ownerem i Deweloperami. 

Zmiany, które mogłyby wpłynąć **negatywnie na Cel Sprintu**, bądź na **jakość produktu,** nie są akceptowalne w trakcie Sprintu.

## Przerwanie Sprintu

W [Scrumie](/pl/blog/first-steps-to-learn-scrum/) istnieje możliwość **przerwania Sprintu,** jeżeli **Cel Sprintu jest nieaktualny** np. z powodu zmiany technologii, albo innej sytuacji na rynku. Szczerze mówiąc jest to raczej rzadka sytuacja, ale może się wydarzyć i może być zainicjowana tylko ze strony **Product Ownera**- jedynej osoby, która ma **prawo do przerwania Sprintu.**

Z technicznego punktu widzenia, kiedy Sprint jest przerwany, wszystko co jest **“Zrobione” musi zostać sprawdzone.** Jeżeli są jakieś potencjalnie **gotowe do wprowadzenia** elementy, to muszą być zatwierdzone przez Product Ownera. Sposób działania wobec nieskończonej pracy, jest taki sam jak w przypadku normalnego Sprintu tzn. Wracają do Product Backlogu i Deweloperzy je ponownie szacują. 

## Podsumowanie

Reasumując: 

* Sprint to **spotkanie** w  [Scrumie](/pl/blog/first-steps-to-learn-scrum/), które może trwać **maksymalnie 1 miesiąc.** 
* Sprint pomaga Deweloperom **skupić się** na pracy, która ma być zrobiona i na **osiągnięciu wyznaczonego Celu Sprintu.** Jest to także **rama** dla wszystkich innych spotkań, wydarzeń i definicji w Scrumie. 
* **Przerwanie Sprintu** jest możliwe, ale nie jest częste i może się wydarzyć tylko z **inicjatywy Właściciela Produktu.**

Mam nadzieję, że ten artykuł pomógł Ci zrozumieć podstawy związane ze **Sprintem**. W kolejnych postach będę kontynuowała opisywanie pozostałych spotkań Scrumowych.

To pierwszy artykuł w serii o Spotkaniach Scrumowych, który pomoże Ci zrozumieć czym jest Sprint i jaką pełni rolę w Scrumie.

Wydarzenia Scrumowe #1 Sprint

## Wstęp

\*Ten artykuł został zaktualizowany na podstawie [Przewodnika Po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) z 2020 roku.

Pisząc ten artykuł za pierwszym razem, napisałam:

> W obecnym, szybko-zmieniającym się świecie pełnym wyzwań, łatwo zapomnieć o celach.

Obecnie nie zgadzam się z tym zdaniem. Ustalamy wiele celów - w pracy oraz w życiu prywatnym. Czasami problem jest właśnie w tym, że mamy **zbyt wiele celów** i zapominamy o tym co właściwie chcemy osiągnąć. Brniemy do przodu przedzierając się przez kolejne wyzwania. 

Zatem dzisiaj zastąpiłabym tamto stare zdanie nowym: 
“W obecnym, szybko-zmieniającym się świecie pełnym wyzwań, potrzebujemy skupienia i jasnego kierunku.”

W Scrumie sprawa jest prosta. Mamy **Cel Produktu - Product Goal**, który pomaga nam w zrozumieniu **po co tworzymy produkt długoterminowo.** W trakcie Planowania Sprintu tworzymy także **Cel Sprintu** -  Sprint Goal, który pomaga nam w zrozumieniu do czego dążymy krótkoterminowo.

Dzisiaj postaram się przybliżyć Ci powody, dla których **Cel Sprintu** jest bardzo użytecznym artefaktem w Scrumie.

## Skupienie i Kierunek

Jak już wspomniałam **Cel Sprintu** pokazuje nam **kierunek** w nadchodzącym Sprincie. Powinien być utworzony w trakcie **Planowania Sprintu**, aby Deweloperzy na jego podstawie mogli zaplanować swoją pracę. 

Co ważne, Cel Sprintu jest jeden. Miałam wiele rozmów na ten temat z moimi Zespołami Scrumowymi. Liczba pojedyncza w tym wypadku jest kluczowa, ponieważ pozwala Deweloperom na skupienie. Możliwe, że wiecie już, że jedną z **Wartości Scruma** jest właśnie - **SKUPIENIE**. Bez skupienia, Deweloperzy nie będą w stanie być kreatywni. A co za tym idzie, przeszkodzi im to w tworzeniu wysokiej jakości produktów.

## Priorytetyzacja

W Sprincie bardzo łatwo jest rozproszyć się przez dużą liczbę małych zadań. To jest moment, w którym warto pamiętać o **Celu Sprintu** i odpowiedzieć sobie na pytanie:

> Czy to zadanie pomaga naszemu zespołowi w osiągnięciu celu?

Jeśli odpowiedź brzmi: “Tak!”, możesz zacząć nad tym pracować. Ale jeśli nie, to lepiej umieścić to zadanie **niżej** na liście naszych priorytetów.

Bez powtarzania sobie tego pytania, możemy znaleźć się w sytuacji, w której jesteśmy ciągle zajęci, ale wcale nie ruszamy do przodu zgodnie z planami, które mieliśmy. W rezultacie na koniec możemy czuć się zawiedzeni, bo Cel Sprintu nie został osiągnięty, a to co osiągnęliśmy nie jest dla nas satysfakcjonujące.

## Interakcje pomiędzy Deweloperami

**Cel Sprintu** jest także pomocnym narzędziem **wglądu** podczas spotkania **Daily Scrum**. W [Przewodniku po Scrumie z 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Polish.pdf) mogłaś znaleźć przykłady pytań, na które Deweloperzy mogą odpowiadać podczas spotkania Daily Scrum. Usunięto je z ostatniej wersji przewodnika i myślę, że był to dobry pomysł. Wiele zespołów używało tych pytań nieprawidłowo poprzez usunięcie ich nawiązania do Celu Sprintu. Wówczas, Daily Scrum nie był spotkaniem w celu współpracy i planowania dnia. Przemieniał się on w tzw. Status report meeting, czyli w swego rodzaju indywidualny raport każdego Dewelopera.

Dlatego myślę, że warto mieć **wizualną przypominajkę o Celu Sprintu** na Tablicy [Scrumowej](/blog/pl/first-steps-to-learn-scrum/). Pomoże to Deweloperom w skupieniu. Kiedy dyskusja opiera się na Celu Sprintu, zmienia się ona całkowicie. Deweloperzy zaczynają **pracować wówczas razem,** zamiast działać osobno nad oddzielnymi inicjatywami. Zaczynają się skupiać na tym, co jest związane z nimi wszystkimi, zamiast pozostać na poziomie indywidualnych zadań. 

**Cel Sprintu** pomaga im zdecydować co jest **ważniejsze** i na czym potrzebują się skupić w trakcie nadchodzącego dnia. Wciąż pamiętam uczucie dumy, kiedy podczas Daily Scruma jeden z Deweloperów zatrzymał inną osobę, która przeciążała się zadaniami, które były nisko na liście priorytetów. Zapytał go: “Czekaj, ale czy to pomaga nam w osiągnięciu Celu Sprintu? Może zamiast pracować nad tym zadaniem, możesz pomóc w rozwiązaniu problemu XYZ?”. To był moment, w którym wiedziałam, że są oni na **dobrej drodze.**

![Daily-Scrum](img/people.webp "Daily Scrum")

## Rezultat Sprintu

**Cel Sprintu** jest także świetnym narzędziem podczas Sprint Review - spotkania skupionego na **rezultatach Sprintu.** Pomaga Zespołowi Scrumowemu w zrozumieniu co zostało osiągnięte oraz co zatrzymało ich przed osiągnięciem tego, zaplanowanego celu.

Poprzez nawiązanie do Celu Sprintu, Zespół Scrumowy oraz interesariusze mogą pomyśleć o **zmianach** potrzebnych w nadchodzącym Sprincie. Mogą także **celebrować sukces**, który został osiągnięty w trakcie Sprintu.

## Podsumowanie

Kończąc ten post, najważniejsze korzyści płynące z używania Celu Sprintu to:

* **Skupienie** Deweloperów
* Jasny **kierunek** Sprintu
* Klarowność co do tego, co jest **najważniejsze** w trakcie Sprintu
* **Priorytetyzowanie** zadań jest prostsze
* Jest to świetne narzędzie **wglądu**
* Pomaga w **interakcjach** między Deweloperami
* Narzędzie pomagające w odzwierciedleniu **rezultatów Sprintu.**

Jeśli zauważysz, że Twój zespół nie zwraca uwagi na **Cel Sprintu**, zachęcam Cię do używania go we wszystkich aktywnościach, o których wspomniałam i do sprawdzenia jak wpłynie na Waszą pracę. Bazując na moim doświadczeniu, mogę powiedzieć, że z pewnością zobaczysz zmianę!

Ten artykuł wyjaśnia jaki jest cel i korzyści płynące z używania Celu Sprintu w Scrumie. Jeśli nie wiesz czym on jest i jak go używać, wskakuj do tego posta.

Cel Sprintu w Scrumie - dlaczego go potrzebujemy?

## Wstęp

Jest wiele powodów, dla których ludzie decydują się na używanie [Scruma](/pl/blog/first-steps-to-learn-scrum), na przykład:

* wzrost efektywności
* usprawnienie pracy
* tworzenie lepszych produktów
* bycie bardziej interesującym dla klienta
* lepsza pozycja na rynku
* [Scrum](/pl/blog/first-steps-to-learn-scrum) i [Agile](https://agilemanifesto.org/) są “modne”
* mój szef powiedział mi, żeby coś zmienić
* brzmi interesująco, więc w sumie, czemu nie?

Masz swój własny powód, ale wciąż nie wiesz od czego zacząć? W tym poście wypiszę Ci kilka wskazówek, które mogą pomóc.

## 1. Edukacja

Niezależnie od tego dlaczego chcesz wdrożyć [Scruma](/pl/blog/first-steps-to-learn-scrum) w Twojej firmie, powinnaś **zacząć od podstaw - nauki** [Scruma](/pl/blog/first-steps-to-learn-scrum) i [Agile](https://agilemanifesto.org/iso/pl/manifesto.html). 

Zanim ruszysz dalej polecam Ci **przeczytanie** mojego artykułu z [Pierwszymi krokami w nauce Scruma](/pl/blog/first-steps-to-learn-scrum/), gdzie znajdziesz wszystko czego potrzebujesz na początku swojej podróży ze Scrumem. 

## 2. Dlaczego?

Kiedy posiadasz już **podstawową wiedzę** na temat  [Scruma](/pl/blog/first-steps-to-learn-scrum), to czas zrozumieć w pełni **dlaczego** chcesz go wdrożyć w Twojej organizacji. 

**Określ swój cel** zanim zaczniesz jakiekolwiek dalsze kroki. Użyjesz go później w celu sprawdzenia czy idziesz w dobrym kierunku. Wypisz także wszystkie **korzyści**, które wierzysz, że  [Scrum](/pl/blog/first-steps-to-learn-scrum) przyniesie Twojej firmie/zespołowi. Uwierz mi, będziesz ich wkrótce potrzebować. 

Dla jasności - **Scrum nie jest złotym środkiem,** który rozwiąże wszystkie Twoje problemy. To ważne, abyś w tym kroku przeanalizowała, czy aby na pewno Scrum jest dobrym wyborem dla Twojej firmy. 

![DLACZEGO](img/why_pl.webp "DLACZEGO")

## 3. Znajdź sojuszników

W celu **wdrożenia** [Scruma](/pl/blog/first-steps-to-learn-scrum) w Twojej firmie, będziesz potrzebować **sojuszników**, którzy będą Cię **wspierać i pomagać**. Wiem, że ta część może być trudna w tradycyjnie zarządzanych organizacjach. 

Prawdopodobnie będziesz potrzebowała pokazać zarządzającym **dlaczego** [Scrum](/pl/blog/first-steps-to-learn-scrum) będzie dobrym pomysłem dla Twojej firmy i **jakie korzyści dostarczy.** To jest moment, w którym możesz użyć listy, którą miałaś stworzyć czytając poprzedni paragraf. 

Jeśli odpowiedziałaś sobie na pytanie **dlaczego** chcesz wdrożyć [Scruma](/pl/blog/first-steps-to-learn-scrum) i jak on **wpłynie** na Twoją firmę, nie powinnaś mieć problemu z wyjaśnieniem tego Twojemu kierownictwu. Kluczem do sukcesu jest **znać “Dlaczego” i wierzyć** w to co mówisz. 

## 4. Szerz wiedzę i współpracuj

W tym artykule zakładam, że [Scrum](/pl/blog/first-steps-to-learn-scrum) jest całkowicie **nowym pomysłem** w Twojej firmie. Zanim zaczniesz go wdrażać, potrzebujesz **nauczyć innych i szerzyć wiedzę** o tym, czym [Scrum](/pl/blog/first-steps-to-learn-scrum) właściwie jest. Zatem, przekazuj swoją wiedzę dalej! **Wydrukuj** wiele kopii [Przewodnika po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) i **rozdawaj** Twoim kolegom i koleżankom w pracy. 

To ważne, aby z Twoimi współpracownikami przeprowadzić dokładnie to samo ćwiczenie, które zrobiłaś z kierownictwem tzn. **wyjaśnij im jakie są korzyści** ze [Scruma](/pl/blog/first-steps-to-learn-scrum) i w czym może im **pomóc**. 

Pamiętaj, że [Scrum](/pl/blog/first-steps-to-learn-scrum) promuje **współpracę**. Zanim zaczniesz działać, zapytaj Twój zespół o to **co myśli** o tym pomyśle **wdrożenia**, zapisz wszystkie obawy, plusy i minusy. W ten sposób **włączysz ich w cały proces od początku** i będą bardziej zaangażowani w przyszłości. 

Nie używaj [Scruma](/pl/blog/first-steps-to-learn-scrum) tylko po to, żeby go użyć. Jeżeli ludzie **będą przeciwni, w żadnym wypadku nie powinnaś tego na nich wymuszać**. Niektórym ludziom więcej czasu zajmuje zrozumienie, że **zmiana** jest potrzebna. I to jest coś, co potrzebujesz **uszanować i dać na to przestrzeń.** 

## 5. Zdefiniuj warunki oraz akcje

Jeżeli pomysł jest już zaakceptowany przez Twoich współpracowników i **wszyscy zgodziliście się na wdrożenie** [Scruma](/pl/blog/first-steps-to-learn-scrum), czas uzgodnić pewne rzeczy. 

* **Role i obowiązki w Zespole Scrumowym**

Jeśli chcesz używać [Scruma](/pl/blog/first-steps-to-learn-scrum) w swojej firmie, potrzebujesz **utworzyć Zespół Scrumowy.** Polecam zacząć od **jednego Zespołu Scrumowego** i **przetestować** jak im się pracuje, zanim zaczniesz tworzyć kolejne. Pamiętaj, że zespół nie powinien przekraczać **10 osób.** Zespół powinien być **interdyscyplinarny**, co oznacza, posiadanie **różnorodnych umiejętności** potrzebnych do **tworzenia wartości.**

Kolejnym krokiem będzie zdecydowanie o tym kto będzie pełnić konkretne **role** w Zespole Scrumowym - kto będzie [Właścicielem Produktu](/pl/blog/scrum-roles-2-product-owner/), [Scrum Masterem](/pl/blog/scrum-roles-3-scrum-master/), a kto [Developerami](/pl/blog/scrum-roles-1-development-team/). To ważne, aby także zdefiniować **obowiązki** i **oczekiwania** od każdego członka zespołu.

* **Wartości Scrumowe**

**Przeanalizuj** z Twoim zespołem, co każda z [wartości Scrumowych](/pl/blog/the-importance-of-scrum-values/) dla Was znaczy. Jak zamierzacie ich używać w Waszej codziennej pracy?

* **Spotkania Scrumowe**

Jaki jest **cel** każdego ze spotkań? **Kiedy i gdzie** będziecie je organizować? Jaka będzie Wasza **długość** Sprintu?

* **Komunikacja**

Jak zamierzacie się ze sobą komunikować - twarzą w twarz, przez maila, telefon, video calle, komunikatory (Whatsapp, Slack etc)? Co z komunikacją z klientami? Kto będzie się komunikował i jak?

* **Backlog Produktu**

Porozmawiajcie o **narzędziach** dotyczących zarządzania [Backlogiem Produktu](/pl/blog/scrum-artifacts-1-product-backlog/). Czy planujecie używać fizycznej tablicy i karteczek, czy też online narzędzi takich jak MS Teams, Jira itp?

To ważne aby sobie zdefiniować tzw. “Work items”, czyli **elementy Backlogu.** Czy zamierzacie używać Epików, Features, User Stories, Tasks (zadania), Bugs, Impediments (przeszkody)? Jeśli tak, **zdefiniujcie** każdy z nich. To ważne, bo w każdej firmie te rzeczy mogą działać inaczej i ludzie często mają inne definicje danych elementów. 

Oczywiście [Właściciel Produktu](/pl/blog/scrum-roles-2-product-owner/) jest osobą, która jest **odpowiedzialna za zarządzanie** [Backlogiem Produktu](/pl/blog/scrum-artifacts-1-product-backlog/), ale cały Zespół Scrumowy powinien mieć ustalone jasne definicje i zasady z nim związane. 

* **Tablica i inne narzędzia**

A co z **wizualną reprezentacją pracy**? Czy planujecie sprawdzać postęp swojej pracy używając tablicy **Kanban**? Czy chcecie używać narzędzi online, czy też chcecie pozostać przy prostej tablicy papierowej?

Jeśli zdecydujecie się na typ tablicy, zdefiniujcie wszystkie jej elementy. Na przykład możecie mieć kolumny “To do, Active, Test, Done”. Co to dla Was **oznacza** że macie jakieś zadanie w danej kolumnie? Kiedy możecie przenosić elementy z jednej do drugiej kolumny? 

Wiem, że brzmi to jak dużo definicji, klaryfikowania, ale to naprawdę ma duże znaczenie. Komunikacja jest kluczowym elementem kolaboracji. Także upewnij się, że macie wszystko wyjaśnione.

## 6. Rób to!

Ok… Wiem, że brzmi to jak **dużo definicji, klaryfikowania,** ale to naprawdę ma duże znaczenie. **Komunikacja** jest kluczowym elementem **współpracy**. Także upewnij się, że macie wszystko wyjaśnione. 

Wiem z doświadczenia, że **brak tych definicji i wspólnego zrozumienia** [Scrumowych](/pl/blog/first-steps-to-learn-scrum/)  terminów może powodować później wiele problemów. Jeśli to wyjaśnicie, będzie Wam dużo łatwiej działać wspólnie. 

![Start](img/begin.webp "start")

Jeśli zrobiłaś już wszystko, o czym napisałam **Zacznij to Scrumować** (Let’s Scrum it!). 


**Nie czekaj** na moment kiedy wszystko będzie perfekcyjne, ale próbuj **uczyć się z doświadczenia** i poprawiać wtedy kiedy będzie taka potrzeba. Powodzenia na wspaniałej drodze ze [Scrumem!](/pl/blog/first-steps-to-learn-scrum/)

Potrzebujesz wsparcia w implementacji Scruma?  Zapisz się na [konsultacje](https://letsscrumit.com/pl/services/implementation-consulting) ze mną. Chętnie pomogę Ci przygotować się do tego i zacząć używać Scruma.

Jeśli myślisz nad używaniem Scruma w Twojej organizacji, ale nie wiesz od czego zacząć, ten artykuł jest dla Ciebie.

6 wskazówek dotyczących wdrożenia Scruma

## Wstęp

Aby w pełni zrozumieć [Scruma](/pl/blog/first-steps-to-learn-scrum), wiedza o spotkaniach, rolach, czy artefaktach nie jest wystarczająca. Oczywiście są one ważne, ale **sercem**  [Scruma](/pl/blog/first-steps-to-learn-scrum) są wartości: **zaangażowanie**, **odwaga**, **skupienie**, **otwartość** i **szacunek**. 

Jednym z powodów, dla których chciałabym podkreślić jak ważne są wartości, jest to, że często są one pominięte pośród procesów, metod, czy usprawnień. W tym wyścigu, aby osiągnąć sukces, zapominamy **DLACZEGO** właściwie to robimy. Jaki jest **cel** naszych działań? I to jest ten moment, kiedy wartości mogą pomóc nam sprawdzić, czy jesteśmy na dobrej drodze, czy też nie. 

![Wartości Scrumowe](img/values.png "Wartości Scrumowe")

## Zaangażowanie

Kiedy jesteś **zaangażowana**, nie robisz rzeczy dlatego, że **musisz**, ale dlatego, że **chcesz** je robić. W [Scrumie](/pl/blog/first-steps-to-learn-scrum) **zaangażowanie** może być pokazywane na wiele sposobów np. **w stosunku do ludzi, Celu Sprintu, czy własnej pracy.**

**Jak się je okazuje w codziennych aktywnościach?** Poprzez branie odpowiedzialności za zadania, które zobowiązujemy się zrobić, bycie aktywnym we wszystkich spotkaniach. To oznacza także zadawanie pytań, jeśli czegoś nie rozumiemy lub informowanie innych i pytanie o wsparcie w przypadku problemów.  

Dlaczego **zaangażowanie**, to ważny element w  [Scrumie](/pl/blog/first-steps-to-learn-scrum)? Najwyższej jakości produkty nie są tworzone przez ludzi, którzy **muszą**, ale przez ludzi, którzy **chcą** je stworzyć! 

## Odwaga

Ta wartość, jest ściśle połączona z **Przejrzystością** (jednym z 3 filarów empiryzmu w Scrumie). W przypadku mówienia prawdy, zwłaszcza, kiedy nie jest to dla nas komfortowa sytuacja**, potrzebujemy sporo odwagi.** 

Używanie jej na co dzień w [Scrumie](/pl/blog/first-steps-to-learn-scrum) oznacza **mówienie o problemach**, wyrażanie swojej opinii, nawet jeśli jest inna niż wszystkich. Potrzebujesz odwagi, aby mówić o swoich pomyłkach oraz gdy pytasz innych o pomoc. 

Bez **odwagi** nie możemy być **transparentni**, a to utrudnia **dostosowywanie się do zmian,** co jest kluczowym elementem tworzenia produktów/dostarczania wartości.

## Skupienie

W [Scrumie](/pl/blog/first-steps-to-learn-scrum) każde spotkanie ma **swój cel oraz limit czasowy.** Pomaga to każdemu członkowi zespołu być skupionym na pracy oraz na **Celu Sprintu.** 

[Scrum](/pl/blog/first-steps-to-learn-scrum) pozwala nam na **skupienie na najważniejszych elementach**: potrzebach użytkowników (przedstawionych w Celu Sprintu), pracy która musi być wykonana, aby je zaspokoić oraz współpracy z innymi członkami zespołu, aby je osiągnąć. 

Skupienie oznacza także **brak dodatkowych rozproszeń.**  [Scrum Master](/pl/blog/scrum-roles-3-scrum-master) powinien chronić Zespół Scrumowy przed nimi i powodować usuwanie napotkanych przeszkód.

![Skupienie](img/focus.webp "Skupienie")

## Otwartość

Ta wartość jest także częścią **Przejrzystości**. Może oznaczać **dzielenie się Twoimi pomysłami i wiedzą z innymi.** **Otwartość** jest także związana z byciem transparentną w związku z codziennymi aktywnościami i wyzwaniami, na które napotykamy w trakcie pracy. 

Ważną częścią [Scruma](/pl/blog/first-steps-to-learn-scrum) jest bycie **otwartym na zmiany** i **dostosowywanie** się do nich. Podczas spotkań takich jak [Retrospektywa](/pl/blog/scrum-events-5-sprint-retrospective), **otwartość** może pomóc zrozumieć co poszło dobrze w trakcie [Sprintu](/pl/blog/scrum-events-1-the-sprint), a co powinno być usprawnione. W ten sposób zespół może się lepiej rozumieć i rozwijać. 

## Szacunek

**Szacunek**, to zdecydowanie moja ulubiona wartość w [Scrumie](/pl/blog/first-steps-to-learn-scrum). Bazując na moich obserwacjach, to właśnie brak szacunku jest **najczęstszym powodem problemów komunikacyjnych lub związanych z dostarczaniem produktu.** Tylko poprzez szacunek wobec innych ludzi możemy naprawdę z nimi **współpracować** i mieć **otwarte głowy** na ich pomysły. 

W Zespole Scrumowym szacunek wobec innych jest kluczowy: **wobec tego co myślą, jak pracują oraz na jakim poziomie są ich umiejętności**. Okazywanie **szacunku** oznacza także nie obwinianie innych, kiedy popełnią błąd, ale pomaganie w naprawianiu. Ta wartość ma także spore znaczenie jeśli chodzi o interakcje z klientem/interesariuszami. Szacunek pomaga stworzyć **relacje oparte na zaufaniu** i wzajemnym zrozumieniu. 

![Szacunek](img/respect.webp "Szacunek")

## Zapamiętaj

Najlepsza, a zarazem najtrudniejsze w wartościach jest to, że mogą być w różny sposób **okazywane i interpretowane**. Każdy Zespół [Scrumowy](/pl/blog/first-steps-to-learn-scrum) ma trochę inną wizję powyższych wartości. 

Dlatego **ważne jest aby rozmawiać o wartościach i rozumieć ich wpływ**. 

Podsumowując: ciało ludzkie nie może przeżyć bez **serca**, a [Scrum](/pl/blog/first-steps-to-learn-scrum) nie zadziała bez **wartości**.

Masz **problemy z używaniem wartości Scrumowych w praktyce?**  Zapisz się na [konsultacje](https://letsscrumit.com/pl/services/implementation-consulting) ze mną. Chętnie pomogę Ci zrozumieć jak możesz używać ich na co dzień w Twoim Zespole Scrumowym.

Naucz się czym są Wartości Scrumowe - to ważny, aczkolwiek niedoceniany temat. Odkryj dlaczego mają znaczenie i jak łączą się ze Scrumem.

Znaczenie Wartości Scrumowych

## Wstęp

* Ten artykuł został zaktualizowany na podstawie [Przewodnika Po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) z 2020 roku.

Wiedza na temat **Scruma bez zrozumienia Agile/Zwinności** (Będę używała tych terminów na zmianę w tym artykule) jest jak nauka tańca bez muzyki. Możesz to robić, ale nie wydaje się mieć to sensu na dłuższą metę. 

Dokładnie to odkryli twórcy [Manifestu programowania zwinnego](https://agilemanifesto.org/iso/pl/manifesto.html) w 2001 roku. Mieli już wiele pomysłów jak usprawnić tworzenie oprogramowania np: [Scrum](/pl/blog/first-steps-to-learn-scrum), Adaptive Software Development, Crystal, Extreme Programming itp., ale czuli, że **brakuje im czegoś ważnego w tej układance.** 

Podczas dyskusji w górach Wasatch w stanie Utah, napisali  [Manifest programowania zwinnego](https://agilemanifesto.org/iso/pl/manifesto.html), podsumowując zwinne wartości i zasady. 

## Czym dokładnie jest Agile - zwinność?

[Agile](https://agilemanifesto.org/history.html) opisane przez Jima Highsmith jest o:

> dostarczaniu dobrych produktów do klientów, przez funkcjonowanie w środowisku, które robi więcej niż tylko mówi o “ludziach jak o najważniejszych zasobach”, ale rzeczywiście “zachowuje się” w ten sposób traktując ludzi jako najważniejszych i traci słowo “zasób”. 

[Agile](https://agilemanifesto.org/iso/pl/manifesto.html) to **sposób myślenia i filozofia,** która podąża za wartościami opisanymi w [Manifeście](https://agilemanifesto.org/iso/pl/manifesto.html). 

Najważniejsze elementy zwinności to: **zorientowanie na ludzi, promowanie współpracy oraz zdolność adaptacji procesu.**
Agile jest skoncentrowane na aspekcie ludzkim związanym z pracą, który jest często niedoceniany.

![Agile Mindset](img/agile.webp "Agile Mindset")

##### Źródło: https://www.agilesherpas.com/agile-mindset-marketing-agility

## Scrum w Zwinności/Agile

Ok, świetnie, znamy już pewne podstawy [Agile](https://agilemanifesto.org/iso/pl/manifesto.html), ale jak możemy to połączyć, ze [Scrumem](/pl/blog/first-steps-to-learn-scrum)?
Wiemy już, że [Agile](https://agilemanifesto.org/iso/pl/manifesto.html) to pewien **sposób myślenia** i może być używany podczas **wdrażania różnych praktyk.** [Scrum](/pl/blog/first-steps-to-learn-scrum) **jest jedną z nich.** 

Jak możemy przeczytać w [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf):

> Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.

Zatem [Scrum](/pl/blog/first-steps-to-learn-scrum), to pewien **zestaw wartości i zasad,** które mogą być używane w **dostarczaniu produktów/wartości.** Jest to w takim razie świetna okazja do używania [Zwinnego](https://agilemanifesto.org/iso/pl/manifesto.html) sposobu myślenia. 

## Co mają wspólnego Scrum i Agile?

* Reprezentują pewną zmianę z pracy opartej na zarządzaniu, kontroli i procesach na skupioną na **ludziach i interakcjach** między nimi. 
* **Działające oprogramowanie** (działający produkt) jest ważniejsze niż obszerna dokumentacja. Nie oznacza to, że dokumentacja nie jest ważna, ale istnieje tylko wtedy, kiedy przynosi jakąś wartość. Dlatego też w [Scrumie](/pl/blog/first-steps-to-learn-scrum) wszystkie wymagania dotyczące produktu są w uproszczonej formie **Product Backlogu.** 
* **Współpraca z klientem** jest ważna. Klienci i użytkownicy nie są traktowani jak “maszynki do robienia pieniędzy”. Traktujemy ich z szacunkiem i słuchamy ich potrzeb oraz informacji zwrotnej. Aby stworzyć wysokiej jakości produkty, klienci/interesariusze i deweloperzy muszą pracować razem. 
* **Zmiana** - pojawia się wszędzie i zawsze. Dlatego też zarówno w [Agile](https://agilemanifesto.org/iso/pl/manifesto.html) jak i w [Scrumie](/pl/blog/first-steps-to-learn-scrum) jest ona kluczowym elementem. Przykładem może być to, że w [Scrumie](/pl/blog/first-steps-to-learn-scrum) sprawdzamy jak idzie praca w trakcie Sprintu i dostosowujemy się, aby jak najszybciej odpowiedzieć na pojawiające się zmiany. Jest to ważna różnica pomiędzy starymi praktykami, które były w pełni skupione na planie, najczęściej bez możliwości dostosowania w przypadku zmian.
* **Iteracyjne i przyrostowe** podejście - zamiast dostarczania pełnego produktu na raz, po długim procesie tworzenia, zarówno w [Agile](https://agilemanifesto.org/iso/pl/manifesto.html) jak i w [Scrumie](/pl/blog/first-steps-to-learn-scrum) promuje się rozdzielenie go na małe kawałki oraz dostarczanie ich często. Dzięki temu klient otrzyma więcej wartości i będzie miał możliwość sprawdzenia produktu oraz dostosowania się do rynku. 

![Współpraca](img/collaboration.webp "Współpraca")

## Nie jest to złoty środek

Muszę podkreślić, że zarówno **[Agile](https://agilemanifesto.org/iso/pl/manifesto.html), jak i [Scrum](/pl/blog/first-steps-to-learn-scrum) nie są złotym środkiem,** który magicznie rozwiąże za nas wszystkie problemy. Polecam jednak praktykować [Zwinny](https://agilemanifesto.org/iso/pl/manifesto.html) sposób myślenia w połączeniu ze [Scrumem](/pl/blog/first-steps-to-learn-scrum). To połączenie zwiększy szansę na dostarczanie lepszej wartości.

Czy wciąż masz problemy ze zrozumieniem jak możesz używać **Agile w połączeniu ze Scrumem?** Zapisz się na [konsultacje ](https://letsscrumit.com/pl/services/scrum-consulting)ze mną. Chętnie pomogę Ci zrozumieć jak możesz to wdrożyć w praktyce.

Określenie “Agile”- zwinność stało się bardzo popularne w ostatnich latach. Dowiedz się co oznacza i w jaki sposób wiąże się ze Scrumem.

Scrum i Agile - jak się łączą?

## Wstęp

\* Ten artykuł został zaktualizowany na podstawie \[Przewodnika Po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) z 2020 roku.

Jeśli nigdy nie słyszałaś o **Scrumie**, ani nie widziałaś go w praktyce, początkowo może Ci sprawiać trudność zrozumienie go. Byłam w tym miejscu chwilę temu, kiedy usłyszałam o **Scrumie** po raz pierwszy w życiu. Dla jasności, jeszcze wtedy nie miałam doświadczenia w IT. Pracowałam w firmie finansowej i próbowałam znaleźć swoją nową drogę. W pewnym momencie dowiedziałam się o **Scrumie** i zaczęłam go **odkrywać**. 

Obecnie mam już trochę **wiedzy i doświadczenia** związanego z tym sposobem pracy i chciałabym się z Tobą nimi podzielić. 
Jeśli jesteś totalnie nowa w tym temacie, albo po prostu chcesz lepiej zrozumieć **Scruma**, wykonaj poniższe kroki. 

## 1. Otwórz swoją głowę

“Czekaj, co takiego? Ja chciałam się uczyć o Scrumie, a Ty mi coś mówisz o otwieraniu głowy?”

Tak, dobrze czytasz. Powód jest bardzo prosty. **Scrum** jest prawdopodobnie czymś innym niż to co do tej pory znałaś i może Ci sprawić trudność nauczenie się go **bez otwartej głowy** (To zdanie nie jest w pełni prawdziwe w przypadku nauczycieli. Scrum używany w edukacji ([eduScrum](https://letsscrumit.com/discover-eduscrum)) ma sporo podobieństw do metody Montessori). 

Wiem, że często łatwiej jest podążać utartymi ścieżkami myślenia, ale spróbuj **otworzyć się na nowy sposób myślenia,** aby lepiej zrozumieć czym jest **Scrum**. 

## 2. Przeczytaj Scrum Guide - Przewodnik po Scrumie

[Przewodnik po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf) jest podsumowaniem **Scruma** stworzonym przez **Kena Schwabera i Jeffa Sutherland.** To oni stworzyli ten sposób tworzenia wartości we wczesnych latach 90 i opublikowali pierwszy [Przewodnik po Scrumie](https://www.qagile.pl/wp-content/uploads/2017/01/Scrum-Guide-Feb-2010.pdf) w 2010. Od tamtej pory był już wiele razy zmieniany, aby dostosować się do **szybko zmieniającego się świata.** 

Jeśli naprawdę chcesz **zrozumieć Scruma**, ten dokument powinien być Twoją Biblią na najbliższe miesiące i później. Znam wielu ludzi, którzy zdecydowali się używać Scruma bez tego i nie poszło im dobrze. Przez sporą popularność tematu, jest wiele nieprawdziwych źródeł, które głoszą koncepty sprzeczne z ideą Scruma. 

Zatem, **przeczytaj go wiele razy** i miej zawsze przy sobie w przypadku jakichkolwiek wątpliwości lub pytań. Możesz go znaleźć w wielu językach na [scrumguides.org](https://www.scrumguides.org/).

## 3. Ucz się od innych

Jest wiele osób, którzy używają **Scruma** i mają naprawdę sporą wiedzę praktyczną związaną z tym tematem. Jeśli chcesz ich poznać i dowiedzieć się o ich doświadczeniu związanym ze Scrumem, polecam być częścią społeczności na [scrum.org](https://www.scrum.org). Jest to wiarygodna strona, stworzona przez **Kena Schwabera - współtwórcę Scruma**. Możesz na niej znaleźć wiele **interesujących artykułów** w części blogowej oraz obserwować, bądź dołączyć do **dyskusji na forum.** 

Co więcej, na stronie zobaczysz ogrom **źródeł na temat Scruma**, które są dobrze zorganizowane i bazują na [Przewodniku po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf). Spędziłam wiele godzin na tej stronie i bardzo mi to pomogło w lepszym rozumieniu **Scruma**. 

Jeśli masz możliwość, dołącz także do swoich **lokalnych społeczności.** W Polsce jest sporo ludzi zajmujących się tym tematem. 

![Ucz się od innych](img/learn_others.webp "Ucz się od innych")

## 4. Przeczytaj Manifest Agile

Możesz używać Scruma bez przeczytania [Manifestu programowania zwinnego](https://agilemanifesto.org/iso/pl/manifesto.html), ale moim zdaniem jego znajomość pomaga **umieścić Scruma w szerszym kontekście.** 

[Manifest programowania zwinnego](https://agilemanifesto.org/iso/pl/manifesto.html) został stworzony przez 17 reprezentantów związanych z tworzeniem oprogramowania, którzy spotkali się, aby stworzyć ich nowy **“zwinny” sposób myślenia.** Zawarli go w **4 wartościach i 12 zasadach**. Więcej detalu znajdziesz na utworzonej przez nich [stronie z manifestem](https://agilemanifesto.org/iso/pl/manifesto.html).

## 5. Bądź gotowa na trudności

Jak to pięknie określono w wersji [przewodnika z 2017 roku](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Polish.pdf): 

> Scrum jest lekki, łatwy do zrozumienia, ale trudny do opanowania. 

Jest to wciąż **dobry opis Scruma,** ponieważ używanie go na co dzień i rzeczywiście **działanie w zgodzie z nim** może być trudne. Dlatego warto być **mentalnie przygotowaną** na te trudności. 

Jestem przekonana, że nie jesteś w stanie przygotować się na wszystko, co może Cię spotkać, ale **przygotuj swoją głowę**. Wypisz wszystkie tematy, które mogą Ci **przysporzyć problemów i zastanów się** jak będziesz mogła ich uniknąć, lub zminimalizować efekty. 

## 6. Zacznij go wdrażać i nigdy nie przestawaj się uczyć!

Mogłabym kontynuować ten artykuł i wypisać wszystkie źródła, z których możesz korzystać, ale prawda jest taka, że najlepiej **nauczysz się praktykując Scruma!** W każdej firmie sposób wdrażania jest inny. Możesz posiadać całą wiedzę teoretyczną, ale nic nie zastąpi **nauki opartej na działaniu.** Jeśli już przeczytałaś [Przewodnik po Scrumie](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf), to wiesz, że:

> Fundamentem Scruma jest empiryzm i koncepcja lean. Istotą empiryzmu jest to, że wiedza wynika z doświadczenia, a decyzje podejmowane są na podstawie tego, co można zaobserwować.

Oznacza to, że **w Scrumie (i nie tylko!) uczysz się poprzez doświadczanie.** W ten sposób odkryjesz najlepsze rozwiązania i usprawnisz swoją pracę na co dzień. 

Mam nadzieję, że te proste kroki pomogą Ci z**acząć przygodę ze Scrumem i cieszyć się nią.** Wiem, że możesz znaleźć wiele źródeł na ten temat w Internecie, ale pamiętaj - lepiej stworzyć solidne podstawy, a potem odkrywać więcej. 

Jeśli znasz już podstawy, ale wciąż **zmagasz się z używaniem Scruma,** odezwij się i zapisz się na moje [konsultacje Scrumowe](https://letsscrumit.com/pl/services/scrum-consulting).

Powodzenia!

Chcesz odkryć czym jest Scrum, ale nie za bardzo wiesz od czego zacząć. Ten post jest w sam raz dla Ciebie. Wskakuj!

Pierwsze kroki w nauce Scruma

Wskakuj tutaj, aby dowiedzieć się o tym czym jest Scrum i jak możesz go wdrożyć. 

Jako Scrum Masterka miałam okazję używać wiedzy teoretycznej na temat Scruma w praktyce i chciałabym się nią z Tobą podzielić.

Artukuły o Scrumie!

Wpisy z kategorii Scrum

Artukuły o .css-vk70jt{margin:0;background:-webkit-linear-gradient(45deg, #09626A 30%, #20dbec 90%);-webkit-background-clip:text;-webkit-text-fill-color:transparent;}Scrumie!

Wpisy z kategorii Scrum

Artukuły o Scrumie!