Sprint review: Różnice pomiędzy wersjami
Z Encyklopedia Zarządzania
m (Infobox update) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 23 wersji utworzonych przez 3 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''[[Przegląd]] Sprintu''' (ang. ''Sprint Review Meeting'') - to spotkanie zespołu Scrumowego oraz interesariuszy, które jest organizowane i odbywa się po zakończeniu każdego Sprintu. Jest to takie kluczowe [[zdarzenie]], pewny mechanizm kontroli i oceny postępów w danym projekcie (Bukłacha E., 2017, s. 6). Podczas tego zebrania [[zespół]] Scrumowy pokazuje wszystkie zadania, które zostały ukończone i w jaki sposób zostały ukończone podczas Sprintu, także jeżeli jest to niezbędnym, zostaje dopasowany [[Backlog produktu|Rejestr Produktowy]] (ang. ''Product [[Backlog]]'') - spis wszystkich produktów wymaganych i potrzebnych przez klienta (Schwaber K., 2005, s. 11). Zazwyczaj to spotkanie ma formę demonstracji nowych funkcji istniejącego produktu lub prezentacji przyrostu. | |||
Podczas Sprint Review Meeting [[projekt]] jest oceniany w stosunku do celu Sprintu ustalonego w trakcie spotkania [[Planowanie sprintu|Planowania Sprintu]] (Jędrzejewski K., Dąbrowski W., 2012, s. 16). | |||
==TL;DR== | |||
Przegląd Sprintu to spotkanie zespołu Scrumowego i interesariuszy, które odbywa się po zakończeniu każdego Sprintu. Celem spotkania jest ocena postępów projektu, prezentacja zadań ukończonych w Sprintcie oraz uzyskanie informacji zwrotnej. Spotkanie powinno trwać maksymalnie cztery godziny i uczestniczyć w nim Właściciel produktu, zespół deweloperski, Scrum Master, kierownictwo firmy, klient i inni developerzy. Zespół powinien przygotować się do spotkania i zapewnić infrastrukturę do demonstracji produktu. Spotkanie ma określoną agendę, w tym demonstrację, informację o zadaniach wykonanych oraz pomiar prędkości Sprintu. Interesariusze mają możliwość przedstawienia swojej opinii na temat produktu. Po spotkaniu aktualizowany jest Rejestr produktu, a następnie odbywa się Retrospektywa Sprintu. | |||
''' | ==Cel Sprint Review== | ||
'''Celem''' Sprint Review jest określenie co zostało wyprodukowane w Sprincie oraz sprawdzenie jakości wyprodukowanego produktu, zidentyfikowanie ulepszeń, które są dodawane do Backlogu Produktu w trakcie Sprintu i priorytetowo ustalane przez Właściciela Produktu, a także uznanie czy zespół spełnił swoje [[zobowiązania]] dotyczące danego Sprintu. Bardzo istotnym jest to, że przegląd powinien odbywać się w zintegrowanym środowisku. | |||
Na podstawie współpracy uczestników spotkania mogą być wprowadzone pewne zmiany w Backlogu Produktu, także znaczącym i niezbędnym jest uzyskanie potrzebnej informacji zwrotnej między członkami zebrania w stosunku do przedstawionego przyrostu (Kuchta D., Skowron D., 2011, s. 313) | |||
<google>n</google> | |||
<google> | |||
==Częstotliwość i czas trwania== | ==Częstotliwość i czas trwania== | ||
Sprint Review Meeting odbywa się zawsze w końcu Sprintu i powinno wynosić maksymalnie cztery godziny dla czterotygodniowego Sprintu, ten termin jest proporcjonalny dla innych czasów Sprintu - przykładowo dla dwutygodniowego Sprintu czas trwania Przeglądu będzie wynosić dwie godziny (Kaczor K., 2018, s. 138), (Skomra A., Kuchta D., 2017, s. 7). | |||
Sprint Review Meeting odbywa się zawsze w końcu Sprintu i powinno wynosić maksymalnie cztery godziny dla czterotygodniowego Sprintu, ten termin jest proporcjonalny dla innych czasów Sprintu | |||
==Uczestnicy== | ==Uczestnicy== | ||
Uczestnikami przeglądu Sprintu przeważnie są [[Właściciel]] produktu (ang. ''Product Owner''), zespół wytwórczy (ang. ''Development Team''), [[Scrum]] Master, kierownictwo firmy, bezpośrednio [[klient]] ([[użytkownik]] końcowy stworzonego produktu lub [[usługi]]) oraz developerzy z innych projektów (M.Kieruzel, 2015, s. 489). | |||
Uczestnikami przeglądu Sprintu przeważnie są Właściciel produktu (ang. ''Product Owner''), zespół wytwórczy (ang. ''Development Team''), Scrum Master, kierownictwo firmy, bezpośrednio klient (użytkownik końcowy stworzonego produktu lub usługi) oraz developerzy z innych projektów (M.Kieruzel, 2015, s. 489). | |||
'''Przygotowanie do spotkania''' | '''Przygotowanie do spotkania''' | ||
Zespół powinien spędzić nie więcej niż godzinę, przygotowując się do Przeglądu Sprintu. Musi także być przygotowana infrastruktura do demonstracji Produktu, na przykład dla przedstawienia działającego oprogramowania każdy uczestnik spotkania musi mieć laptopa. | Zespół powinien spędzić nie więcej niż godzinę, przygotowując się do Przeglądu Sprintu. Musi także być przygotowana [[infrastruktura]] do demonstracji Produktu, na przykład dla przedstawienia działającego oprogramowania każdy uczestnik spotkania musi mieć laptopa. | ||
== | ==Agenda Sprint Review Meeting== | ||
* ''Demonstracja'' | * ''Demonstracja'' - zespół Deweloperski demonstruje [[Przyrost]] produktu potencjalnie możliwy do wysłania oraz wykorzystania przez klienta, | ||
* ''Co jest zrobione?'' | * ''Co jest zrobione?'' - [[właściciel produktu]] deklaruje (ogłasza) co zostało zrobione, | ||
* ''Velocity'' | * ''[[Velocity]]'' - zespół Deweloperski mierzy velocity (prędkość) dla danego Sprintu, | ||
* ''Feedback'' | * ''Feedback'' - [[Informacja]] zwrotna od interesariuszy oraz zainteresowanych osób, zamykanie Sprintu | ||
==Demonstracja== | ==Demonstracja== | ||
* Bezpośrednie przedstawienie Produktu dla uczestników | * Bezpośrednie przedstawienie Produktu dla uczestników | ||
* Powinna się odbywać na podstawie zadań, które są opisane w Backlogu Produktu | * Powinna się odbywać na podstawie zadań, które są opisane w Backlogu Produktu | ||
* Zademonstrowane zadania muszą być całkiem wykonane, a nie "w | * Zademonstrowane zadania muszą być całkiem wykonane, a nie "w połowie" wykonane, | ||
* Właściciel produktu może zadeklarować jakie zadania uzna za zakończone. | * Właściciel produktu może zadeklarować jakie zadania uzna za zakończone. | ||
Podczas demonstracji Zespół Deweloperski identyfikuje wszelkie niekompletne pozycje zaległości (ang. ''Backlog items''). | Podczas demonstracji Zespół Deweloperski identyfikuje wszelkie niekompletne pozycje zaległości (ang. ''Backlog items''). | ||
==Co jest zrobione?== | ==Co jest zrobione?== | ||
| Linia 54: | Linia 40: | ||
* Właściciel produktu ma ostatnie słowo i decyduje o tym, co dokładnie zostało zrobione. | * Właściciel produktu ma ostatnie słowo i decyduje o tym, co dokładnie zostało zrobione. | ||
Właściciel Produktu przenosi i / lub dzieli niekompletne zaległości na kolejny Sprint lub Backlog Produktu, jeśli nie jest to priorytet. | Właściciel Produktu przenosi i / lub dzieli niekompletne zaległości na kolejny Sprint lub Backlog Produktu, jeśli nie jest to [[priorytet]]. | ||
==Velocity== | ==Velocity== | ||
* Na Spotkaniu Refleksji Backlogu (ang. ''Backlog Refinement meeting'') zostały wyznaczone Punkty Opowieści (ang. ''Story points'') dla każdego Przedmiotu Backlogu Produktu (ang. ''Product Backlog Item''); | * Na Spotkaniu Refleksji Backlogu (ang. ''Backlog Refinement meeting'') zostały wyznaczone Punkty Opowieści (ang. ''Story points'') dla każdego Przedmiotu Backlogu Produktu (ang. ''Product Backlog Item''); | ||
* Dla obliczenia prędkości dla bieżącego Sprintu trzeba zsumować wszystkie punkty z ukończonych funkcjonalności. | * Dla obliczenia prędkości dla bieżącego Sprintu trzeba zsumować wszystkie punkty z ukończonych funkcjonalności. | ||
Na danym etapie ocenia się prędkość Sprintu oraz prawdopodobna data zakończenia Sprintu | Na danym etapie ocenia się prędkość Sprintu oraz prawdopodobna data zakończenia Sprintu | ||
==Feedback== | ==Feedback== | ||
* Interesariusze mają możliwość przedstawienia swojej opinii na temat przyrostu, | * [[Interesariusze]] mają możliwość przedstawienia swojej opinii na temat przyrostu, | ||
* Wspólne rozumienie stanu produktu, | * Wspólne rozumienie stanu produktu, | ||
* Mogą być zidentyfikowane nowe funkcje i/lub zadania produktu; | * Mogą być zidentyfikowane nowe funkcje i/lub zadania produktu; | ||
* Te nowe zadania I wszystkie zmiany, które zostały omówione na Sprint Review przez uczestników spotkania muszą zostać dodane do Backlogu Produktu, | * Te nowe zadania I wszystkie zmiany, które zostały omówione na Sprint Review przez uczestników spotkania muszą zostać dodane do Backlogu Produktu, | ||
* Właściciel produktu zamyka Sprint i akceptuje dostarczoną funkcjonalność. | * Właściciel produktu zamyka Sprint i akceptuje dostarczoną funkcjonalność. | ||
Przykładowe problemy, które zdarzają się podczas Sprint Review Meeting, mogą być następne: | Przykładowe problemy, które zdarzają się podczas Sprint Review Meeting, mogą być następne: | ||
# Zespół nie zgadza się z tym, co pozostało wyznaczone przez Product Ownera jako " | # Zespół nie zgadza się z tym, co pozostało wyznaczone przez Product Ownera jako "ukończone", | ||
# Awarie oprogramowania, | # Awarie oprogramowania, | ||
# Dostępna jest zła wersja systemu. | # Dostępna jest zła wersja systemu. | ||
Po zakończeniu Sprint Review Meeting zostaje zaktualizowany i unowocześniony plan rozwoju Rejestru produktu (ang. Product Backlog). Zatem przed rozpoczęciem następnego planowania Sprintu odbywa się [[Retrospektywa|Retrospektywa Sprintu]] (ang. ''Sprint Retrospective'') (Bukłaha E., 2013, s. 56). | Po zakończeniu Sprint Review Meeting zostaje zaktualizowany i unowocześniony [[plan]] rozwoju Rejestru produktu (ang. Product Backlog). Zatem przed rozpoczęciem następnego planowania Sprintu odbywa się [[Retrospektywa|Retrospektywa Sprintu]] (ang. ''Sprint Retrospective'') (Bukłaha E., 2013, s. 56). | ||
{{infobox5|list1={{i5link|a=[[Sprint]]}} — {{i5link|a=[[Backlog produktu]]}} — {{i5link|a=[[Metodyka SCRUM]]}} — {{i5link|a=[[Planowanie sprintu]]}} — {{i5link|a=[[Backlog sprintu]]}} — {{i5link|a=[[Inicjowanie Projektu]]}} — {{i5link|a=[[Kamień milowy]]}} — {{i5link|a=[[Testowanie w projekcie]]}} — {{i5link|a=[[Zarządzanie zleceniami wg PMBOK]]}} }} | |||
==Bibliografia== | ==Bibliografia== | ||
* Bukłaha E. (2013), Ocena sukcesu projektu na podstawie wytycznych metodyki Scrum, | <noautolinks> | ||
* | * Bukłaha E. (2013), ''Ocena sukcesu projektu na podstawie wytycznych metodyki Scrum'', Prace Naukowe Wyższej Szkoły Bankowej w Gdańsku, nr 22 Nowe koncepcje w zarządzaniu organizacją wobec wyzwań otoczenia | ||
* Chrapko M. ( | * Bukłaha E. (2017), ''[https://journalmmp.com/index.php/jmmp/article/view/30/30 Project controlling in the adaptive perspective of project management]'', Journal of Modern Management Process, nr 1 Współczesne instrumenty zarządzania projektami I procesami, SCH Warsaw School of Economics | ||
* Ćwiklicki M. (2010), Scrum | * Chrapko M. (2015), ''Scrum: o zwinnym zarządzaniu projektami'', Wydawnictwo Helion, Gliwice | ||
* James M., Walter L., | * Ćwiklicki M. (2010), ''Scrum - nowa metoda zarządzania złożonymi projektami'', Przegląd Organizacji, nr 4 | ||
* Jędrzejewski K., Dąbrowski W. (2012), Zarządzanie Projektami informatycznymi w metodyce Scrum, Politechnika Warszawska, | * James M., Walter L. (2010), ''[https://scrumreferencecard.com/ScrumReferenceCard.pdf Scrum Reference Card]'' | ||
* Kaczor K. (2018), Scrum i nie tylko. Teoria i praktyka w metodach Agile | * Jędrzejewski K., Dąbrowski W. (2012), ''Zarządzanie Projektami informatycznymi w metodyce Scrum'', Politechnika Warszawska, Warszawa | ||
* Kieruzel M. (2015), '' [http://www.wzieu.pl/zn/852/ZN_852.pdf Integracja metodyki PRINCE2 oraz Scrum przy realizacji informatycznych projektów wytwarzania oprogramowania w e-administracji]'', | * Kaczor K. (2018), ''Scrum i nie tylko. Teoria i praktyka w metodach Agile'', Wydawnictwo naukowe PWN, Warszawa | ||
* Kuchta D., Skowron D. (2011), ''[ | * Kieruzel M. (2015), ''[http://www.wzieu.pl/zn/852/ZN_852.pdf Integracja metodyki PRINCE2 oraz Scrum przy realizacji informatycznych projektów wytwarzania oprogramowania w e-administracji]'', Zeszyty Naukowe Uniwersytetu Szczecińskiego. Ekonomiczne Problemy Usług, nr 117 Wirtualizacja gospodarki - spojrzenie interdyscyplinarne | ||
* Schwaber K. (2004), Agile Project Management with Scrum, Microsoft Press, | * Kuchta D., Skowron D. (2011), ''[https://yadda.icm.edu.pl/yadda/element/bwmeta1.element.ekon-element-000171232653 Zastosowanie modelu Time-Driven Activity-Based Costing w metodyce Scrum]'', Studia Ekonomiczne, Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach, nr 96 | ||
* Schwaber K. (2005), Sprawne zarządzanie projektami metodą Scrum, Microsoft Press, Warszawa | * Schwaber K. (2004), ''Agile Project Management with Scrum'', Microsoft Press, Warszawa | ||
* Skomra A., Kuchta D. (2017), Model dojrzałości dla podejścia Scrum, | * Schwaber K. (2005), ''Sprawne zarządzanie projektami metodą Scrum'', Microsoft Press, Warszawa | ||
* Sutherland J.(2004 | * Skomra A., Kuchta D. (2017), ''Model dojrzałości dla podejścia Scrum'', Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach, Nr 340 | ||
* Sutherland J., Schwaber K. (2013 | * Sutherland J. (2004), ''[https://csis.pace.edu/~marchese/CS616/Agile/Scrum/FirstScrum2004.pdf Agile Development: Lessons Learned from the First Scrum]'' | ||
* Sutherland J. (2015), ''Scrum Czyli jak robić dwa razy więcej dwa razy szybciej'', Wydawnictwo Naukowe PWN, Warszawa | |||
* Sutherland J., Schwaber K. (2013), ''[https://www.scrumguides.org/ The Scrum guide]'' | |||
</noautolinks> | |||
{{a|Inga Rasniuk}} | {{a|Inga Rasniuk}} | ||
[[Kategoria: | [[Kategoria:Techniki zwinne]] | ||
{{#metamaster:description|Przegląd Sprintu - spotkanie zespołu Scrumowego i interesariuszy po zakończeniu Sprintu. Zespół prezentuje ukończone zadania i dopasowuje Backlog produktu. Ocena postępów projektu i celu Sprintu.}} | |||
Aktualna wersja na dzień 23:51, 9 sty 2024
Przegląd Sprintu (ang. Sprint Review Meeting) - to spotkanie zespołu Scrumowego oraz interesariuszy, które jest organizowane i odbywa się po zakończeniu każdego Sprintu. Jest to takie kluczowe zdarzenie, pewny mechanizm kontroli i oceny postępów w danym projekcie (Bukłacha E., 2017, s. 6). Podczas tego zebrania zespół Scrumowy pokazuje wszystkie zadania, które zostały ukończone i w jaki sposób zostały ukończone podczas Sprintu, także jeżeli jest to niezbędnym, zostaje dopasowany Rejestr Produktowy (ang. Product Backlog) - spis wszystkich produktów wymaganych i potrzebnych przez klienta (Schwaber K., 2005, s. 11). Zazwyczaj to spotkanie ma formę demonstracji nowych funkcji istniejącego produktu lub prezentacji przyrostu. Podczas Sprint Review Meeting projekt jest oceniany w stosunku do celu Sprintu ustalonego w trakcie spotkania Planowania Sprintu (Jędrzejewski K., Dąbrowski W., 2012, s. 16).
TL;DR
Przegląd Sprintu to spotkanie zespołu Scrumowego i interesariuszy, które odbywa się po zakończeniu każdego Sprintu. Celem spotkania jest ocena postępów projektu, prezentacja zadań ukończonych w Sprintcie oraz uzyskanie informacji zwrotnej. Spotkanie powinno trwać maksymalnie cztery godziny i uczestniczyć w nim Właściciel produktu, zespół deweloperski, Scrum Master, kierownictwo firmy, klient i inni developerzy. Zespół powinien przygotować się do spotkania i zapewnić infrastrukturę do demonstracji produktu. Spotkanie ma określoną agendę, w tym demonstrację, informację o zadaniach wykonanych oraz pomiar prędkości Sprintu. Interesariusze mają możliwość przedstawienia swojej opinii na temat produktu. Po spotkaniu aktualizowany jest Rejestr produktu, a następnie odbywa się Retrospektywa Sprintu.
Cel Sprint Review
Celem Sprint Review jest określenie co zostało wyprodukowane w Sprincie oraz sprawdzenie jakości wyprodukowanego produktu, zidentyfikowanie ulepszeń, które są dodawane do Backlogu Produktu w trakcie Sprintu i priorytetowo ustalane przez Właściciela Produktu, a także uznanie czy zespół spełnił swoje zobowiązania dotyczące danego Sprintu. Bardzo istotnym jest to, że przegląd powinien odbywać się w zintegrowanym środowisku. Na podstawie współpracy uczestników spotkania mogą być wprowadzone pewne zmiany w Backlogu Produktu, także znaczącym i niezbędnym jest uzyskanie potrzebnej informacji zwrotnej między członkami zebrania w stosunku do przedstawionego przyrostu (Kuchta D., Skowron D., 2011, s. 313)
Częstotliwość i czas trwania
Sprint Review Meeting odbywa się zawsze w końcu Sprintu i powinno wynosić maksymalnie cztery godziny dla czterotygodniowego Sprintu, ten termin jest proporcjonalny dla innych czasów Sprintu - przykładowo dla dwutygodniowego Sprintu czas trwania Przeglądu będzie wynosić dwie godziny (Kaczor K., 2018, s. 138), (Skomra A., Kuchta D., 2017, s. 7).
Uczestnicy
Uczestnikami przeglądu Sprintu przeważnie są Właściciel produktu (ang. Product Owner), zespół wytwórczy (ang. Development Team), Scrum Master, kierownictwo firmy, bezpośrednio klient (użytkownik końcowy stworzonego produktu lub usługi) oraz developerzy z innych projektów (M.Kieruzel, 2015, s. 489).
Przygotowanie do spotkania
Zespół powinien spędzić nie więcej niż godzinę, przygotowując się do Przeglądu Sprintu. Musi także być przygotowana infrastruktura do demonstracji Produktu, na przykład dla przedstawienia działającego oprogramowania każdy uczestnik spotkania musi mieć laptopa.
Agenda Sprint Review Meeting
- Demonstracja - zespół Deweloperski demonstruje Przyrost produktu potencjalnie możliwy do wysłania oraz wykorzystania przez klienta,
- Co jest zrobione? - właściciel produktu deklaruje (ogłasza) co zostało zrobione,
- Velocity - zespół Deweloperski mierzy velocity (prędkość) dla danego Sprintu,
- Feedback - Informacja zwrotna od interesariuszy oraz zainteresowanych osób, zamykanie Sprintu
Demonstracja
- Bezpośrednie przedstawienie Produktu dla uczestników
- Powinna się odbywać na podstawie zadań, które są opisane w Backlogu Produktu
- Zademonstrowane zadania muszą być całkiem wykonane, a nie "w połowie" wykonane,
- Właściciel produktu może zadeklarować jakie zadania uzna za zakończone.
Podczas demonstracji Zespół Deweloperski identyfikuje wszelkie niekompletne pozycje zaległości (ang. Backlog items).
Co jest zrobione?
- Powinno to zostać określone w Backlogu Refinement lub na spotkaniu Planowania Sprintu,
- Każdy z uczestników powinien dobrze rozumieć istotę Sprintu,
- Właściciel produktu ma ostatnie słowo i decyduje o tym, co dokładnie zostało zrobione.
Właściciel Produktu przenosi i / lub dzieli niekompletne zaległości na kolejny Sprint lub Backlog Produktu, jeśli nie jest to priorytet.
Velocity
- Na Spotkaniu Refleksji Backlogu (ang. Backlog Refinement meeting) zostały wyznaczone Punkty Opowieści (ang. Story points) dla każdego Przedmiotu Backlogu Produktu (ang. Product Backlog Item);
- Dla obliczenia prędkości dla bieżącego Sprintu trzeba zsumować wszystkie punkty z ukończonych funkcjonalności.
Na danym etapie ocenia się prędkość Sprintu oraz prawdopodobna data zakończenia Sprintu
Feedback
- Interesariusze mają możliwość przedstawienia swojej opinii na temat przyrostu,
- Wspólne rozumienie stanu produktu,
- Mogą być zidentyfikowane nowe funkcje i/lub zadania produktu;
- Te nowe zadania I wszystkie zmiany, które zostały omówione na Sprint Review przez uczestników spotkania muszą zostać dodane do Backlogu Produktu,
- Właściciel produktu zamyka Sprint i akceptuje dostarczoną funkcjonalność.
Przykładowe problemy, które zdarzają się podczas Sprint Review Meeting, mogą być następne:
- Zespół nie zgadza się z tym, co pozostało wyznaczone przez Product Ownera jako "ukończone",
- Awarie oprogramowania,
- Dostępna jest zła wersja systemu.
Po zakończeniu Sprint Review Meeting zostaje zaktualizowany i unowocześniony plan rozwoju Rejestru produktu (ang. Product Backlog). Zatem przed rozpoczęciem następnego planowania Sprintu odbywa się Retrospektywa Sprintu (ang. Sprint Retrospective) (Bukłaha E., 2013, s. 56).
| Sprint review — artykuły polecane |
| Sprint — Backlog produktu — Metodyka SCRUM — Planowanie sprintu — Backlog sprintu — Inicjowanie Projektu — Kamień milowy — Testowanie w projekcie — Zarządzanie zleceniami wg PMBOK |
Bibliografia
- Bukłaha E. (2013), Ocena sukcesu projektu na podstawie wytycznych metodyki Scrum, Prace Naukowe Wyższej Szkoły Bankowej w Gdańsku, nr 22 Nowe koncepcje w zarządzaniu organizacją wobec wyzwań otoczenia
- Bukłaha E. (2017), Project controlling in the adaptive perspective of project management, Journal of Modern Management Process, nr 1 Współczesne instrumenty zarządzania projektami I procesami, SCH Warsaw School of Economics
- Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
- Ćwiklicki M. (2010), Scrum - nowa metoda zarządzania złożonymi projektami, Przegląd Organizacji, nr 4
- James M., Walter L. (2010), Scrum Reference Card
- Jędrzejewski K., Dąbrowski W. (2012), Zarządzanie Projektami informatycznymi w metodyce Scrum, Politechnika Warszawska, Warszawa
- Kaczor K. (2018), Scrum i nie tylko. Teoria i praktyka w metodach Agile, Wydawnictwo naukowe PWN, Warszawa
- Kieruzel M. (2015), Integracja metodyki PRINCE2 oraz Scrum przy realizacji informatycznych projektów wytwarzania oprogramowania w e-administracji, Zeszyty Naukowe Uniwersytetu Szczecińskiego. Ekonomiczne Problemy Usług, nr 117 Wirtualizacja gospodarki - spojrzenie interdyscyplinarne
- Kuchta D., Skowron D. (2011), Zastosowanie modelu Time-Driven Activity-Based Costing w metodyce Scrum, Studia Ekonomiczne, Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach, nr 96
- Schwaber K. (2004), Agile Project Management with Scrum, Microsoft Press, Warszawa
- Schwaber K. (2005), Sprawne zarządzanie projektami metodą Scrum, Microsoft Press, Warszawa
- Skomra A., Kuchta D. (2017), Model dojrzałości dla podejścia Scrum, Zeszyty Naukowe Uniwersytetu Ekonomicznego w Katowicach, Nr 340
- Sutherland J. (2004), Agile Development: Lessons Learned from the First Scrum
- Sutherland J. (2015), Scrum Czyli jak robić dwa razy więcej dwa razy szybciej, Wydawnictwo Naukowe PWN, Warszawa
- Sutherland J., Schwaber K. (2013), The Scrum guide
Autor: Inga Rasniuk
