To quick win. To kwestia komunikacji. Zróbmy refinement. Czy mamy akceptację? "To tylko zmiana jednego przycisku." Możemy to zautomatyzować? Story jest za duże. "To jest najwyższy priorytet... do jutra." To edge case. U mnie działa. Klient zmienił wymagania. Poczekajmy na decyzję biznesu. "Klient na pewno tego nie zauważy." Dodajmy to do kolejnego sprintu. Nie mamy capacity. Wrócimy do tego później. "Nie dostałem zaproszenia na spotkanie." Nie reprodukuję tego błędu. "Możemy to zrobić w tym sprincie?" Bonus – bardziej humorystyczne To było na wczoraj. "Ktoś usunął moje zmiany." Nie było tego w wymaganiach. To nie bug, to feature. Nie mamy na to czasu. Zróbmy szybki sync. Dopiszmy taska. To będzie tylko 5 minut. To było poza zakresem. "Na demo jakoś przejdzie." Nie zdążyliśmy przetestować. Po co nam raporty? Na produkcji działa inaczej. To zależy. Sprawdźmy to na Daily. Czy wszyscy są na callu? Trzeba zrefaktoryzować. Priorytety się zmieniły. "Przecież to jedno kliknięcie." To tylko mała zmiana. a SM nie jest potrzebny w zespole. To pilne. "To nie mój komponent." To blocker. "Czy możemy wrócić do poprzedniej wersji?" Wrzućmy to do backlogu. "Zróbmy jeszcze jedno Daily." "Czy to jest już na Jirze?" Musimy to doprecyzować. To nie jest MVP. Rozbijmy to na mniejsze zadania. Mamy zależność od innego zespołu. W dokumentacji jest inaczej. "To było ustalone... chyba." Jeszcze jedna rzecz... Weźmy to offline. Czy mamy estimate? Kto zatwierdził tę zmianę? Kto jest właścicielem tematu? Niech Product Owner zdecyduje. Zróbmy PoC. Czy to jest zgodne z procesem? Mamy już podobne rozwiązanie. Musimy dowieźć. To temat na retro. Działało przed deployem. To powinno być proste. Kto to wdrażał? "A da się to zrobić bez kodowania?" "To wymaga jeszcze jednego spotkania." To techniczny dług. To quick win. To kwestia komunikacji. Zróbmy refinement. Czy mamy akceptację? "To tylko zmiana jednego przycisku." Możemy to zautomatyzować? Story jest za duże. "To jest najwyższy priorytet... do jutra." To edge case. U mnie działa. Klient zmienił wymagania. Poczekajmy na decyzję biznesu. "Klient na pewno tego nie zauważy." Dodajmy to do kolejnego sprintu. Nie mamy capacity. Wrócimy do tego później. "Nie dostałem zaproszenia na spotkanie." Nie reprodukuję tego błędu. "Możemy to zrobić w tym sprincie?" Bonus – bardziej humorystyczne To było na wczoraj. "Ktoś usunął moje zmiany." Nie było tego w wymaganiach. To nie bug, to feature. Nie mamy na to czasu. Zróbmy szybki sync. Dopiszmy taska. To będzie tylko 5 minut. To było poza zakresem. "Na demo jakoś przejdzie." Nie zdążyliśmy przetestować. Po co nam raporty? Na produkcji działa inaczej. To zależy. Sprawdźmy to na Daily. Czy wszyscy są na callu? Trzeba zrefaktoryzować. Priorytety się zmieniły. "Przecież to jedno kliknięcie." To tylko mała zmiana. a SM nie jest potrzebny w zespole. To pilne. "To nie mój komponent." To blocker. "Czy możemy wrócić do poprzedniej wersji?" Wrzućmy to do backlogu. "Zróbmy jeszcze jedno Daily." "Czy to jest już na Jirze?" Musimy to doprecyzować. To nie jest MVP. Rozbijmy to na mniejsze zadania. Mamy zależność od innego zespołu. W dokumentacji jest inaczej. "To było ustalone... chyba." Jeszcze jedna rzecz... Weźmy to offline. Czy mamy estimate? Kto zatwierdził tę zmianę? Kto jest właścicielem tematu? Niech Product Owner zdecyduje. Zróbmy PoC. Czy to jest zgodne z procesem? Mamy już podobne rozwiązanie. Musimy dowieźć. To temat na retro. Działało przed deployem. To powinno być proste. Kto to wdrażał? "A da się to zrobić bez kodowania?" "To wymaga jeszcze jednego spotkania." To techniczny dług.
(Print) Use this randomly generated list as your call list when playing the game. There is no need to say the BINGO column name. Place some kind of mark (like an X, a checkmark, a dot, tally mark, etc) on each cell as you announce it, to keep track. You can also cut out each item, place them in a bag and pull words from the bag.
To quick win.
To kwestia komunikacji.
Zróbmy refinement.
Czy mamy akceptację?
"To tylko zmiana jednego przycisku."
Możemy to zautomatyzować?
Story jest za duże.
"To jest najwyższy priorytet... do jutra."
To edge case.
U mnie działa.
Klient zmienił wymagania.
Poczekajmy na decyzję biznesu.
"Klient na pewno tego nie zauważy."
Dodajmy to do kolejnego sprintu.
Nie mamy capacity.
Wrócimy do tego później.
"Nie dostałem zaproszenia na spotkanie."
Nie reprodukuję tego błędu.
"Możemy to zrobić w tym sprincie?"
Bonus – bardziej humorystyczne
To było na wczoraj.
"Ktoś usunął moje zmiany."
Nie było tego w wymaganiach.
To nie bug, to feature.
Nie mamy na to czasu.
Zróbmy szybki sync.
Dopiszmy taska.
To będzie tylko 5 minut.
To było poza zakresem.
"Na demo jakoś przejdzie."
Nie zdążyliśmy przetestować.
Po co nam raporty?
Na produkcji działa inaczej.
To zależy.
Sprawdźmy to na Daily.
Czy wszyscy są na callu?
Trzeba zrefaktoryzować.
Priorytety się zmieniły.
"Przecież to jedno kliknięcie."
To tylko mała zmiana.
a
SM nie jest potrzebny w zespole.
To pilne.
"To nie mój komponent."
To blocker.
"Czy możemy wrócić do poprzedniej wersji?"
Wrzućmy to do backlogu.
"Zróbmy jeszcze jedno Daily."
"Czy to jest już na Jirze?"
Musimy to doprecyzować.
To nie jest MVP.
Rozbijmy to na mniejsze zadania.
Mamy zależność od innego zespołu.
W dokumentacji jest inaczej.
"To było ustalone... chyba."
Jeszcze jedna rzecz...
Weźmy to offline.
Czy mamy estimate?
Kto zatwierdził tę zmianę?
Kto jest właścicielem tematu?
Niech Product Owner zdecyduje.
Zróbmy PoC.
Czy to jest zgodne z procesem?
Mamy już podobne rozwiązanie.
Musimy dowieźć.
To temat na retro.
Działało przed deployem.
To powinno być proste.
Kto to wdrażał?
"A da się to zrobić bez kodowania?"
"To wymaga jeszcze jednego spotkania."
To techniczny dług.