"Czy możemy wrócić do poprzedniej wersji?" Jeszcze jedna rzecz... Czy wszyscy są na callu? Możemy to zautomatyzować? Rozbijmy to na mniejsze zadania. Niech Product Owner zdecyduje. Mamy już podobne rozwiązanie. To techniczny dług. To blocker. Nie mamy capacity. Poczekajmy na decyzję biznesu. To zależy. "Klient na pewno tego nie zauważy." Dodajmy to do kolejnego sprintu. Kto zatwierdził tę zmianę? "A da się to zrobić bez kodowania?" Sprawdźmy to na Daily. Wrócimy do tego później. To było poza zakresem. To było na wczoraj. Kto jest właścicielem tematu? Musimy to doprecyzować. Nie reprodukuję tego błędu. "Na demo jakoś przejdzie." "Zróbmy jeszcze jedno Daily." U mnie działa. Story jest za duże. Nie było tego w wymaganiach. "To jest najwyższy priorytet... do jutra." "Ktoś usunął moje zmiany." To będzie tylko 5 minut. "Czy to jest już na Jirze?" Bonus – bardziej humorystyczne W dokumentacji jest inaczej. To quick win. Czy mamy akceptację? "To tylko zmiana jednego przycisku." "Przecież to jedno kliknięcie." Musimy dowieźć. Kto to wdrażał? Dopiszmy taska. Klient zmienił wymagania. Zróbmy PoC. To temat na retro. Nie zdążyliśmy przetestować. Trzeba zrefaktoryzować. SM nie jest potrzebny w zespole. To nie bug, to feature. Po co nam raporty? Zróbmy szybki sync. Czy mamy estimate? Priorytety się zmieniły. "To było ustalone... chyba." Czy to jest zgodne z procesem? To tylko mała zmiana. To powinno być proste. Działało przed deployem. Nie mamy na to czasu. Weźmy to offline. Zróbmy refinement. Na produkcji działa inaczej. "To nie mój komponent." To kwestia komunikacji. To nie jest MVP. Wrzućmy to do backlogu. To edge case. "Możemy to zrobić w tym sprincie?" To pilne. a "To wymaga jeszcze jednego spotkania." "Nie dostałem zaproszenia na spotkanie." Mamy zależność od innego zespołu. "Czy możemy wrócić do poprzedniej wersji?" Jeszcze jedna rzecz... Czy wszyscy są na callu? Możemy to zautomatyzować? Rozbijmy to na mniejsze zadania. Niech Product Owner zdecyduje. Mamy już podobne rozwiązanie. To techniczny dług. To blocker. Nie mamy capacity. Poczekajmy na decyzję biznesu. To zależy. "Klient na pewno tego nie zauważy." Dodajmy to do kolejnego sprintu. Kto zatwierdził tę zmianę? "A da się to zrobić bez kodowania?" Sprawdźmy to na Daily. Wrócimy do tego później. To było poza zakresem. To było na wczoraj. Kto jest właścicielem tematu? Musimy to doprecyzować. Nie reprodukuję tego błędu. "Na demo jakoś przejdzie." "Zróbmy jeszcze jedno Daily." U mnie działa. Story jest za duże. Nie było tego w wymaganiach. "To jest najwyższy priorytet... do jutra." "Ktoś usunął moje zmiany." To będzie tylko 5 minut. "Czy to jest już na Jirze?" Bonus – bardziej humorystyczne W dokumentacji jest inaczej. To quick win. Czy mamy akceptację? "To tylko zmiana jednego przycisku." "Przecież to jedno kliknięcie." Musimy dowieźć. Kto to wdrażał? Dopiszmy taska. Klient zmienił wymagania. Zróbmy PoC. To temat na retro. Nie zdążyliśmy przetestować. Trzeba zrefaktoryzować. SM nie jest potrzebny w zespole. To nie bug, to feature. Po co nam raporty? Zróbmy szybki sync. Czy mamy estimate? Priorytety się zmieniły. "To było ustalone... chyba." Czy to jest zgodne z procesem? To tylko mała zmiana. To powinno być proste. Działało przed deployem. Nie mamy na to czasu. Weźmy to offline. Zróbmy refinement. Na produkcji działa inaczej. "To nie mój komponent." To kwestia komunikacji. To nie jest MVP. Wrzućmy to do backlogu. To edge case. "Możemy to zrobić w tym sprincie?" To pilne. a "To wymaga jeszcze jednego spotkania." "Nie dostałem zaproszenia na spotkanie." Mamy zależność od innego zespołu.
(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.
"Czy możemy wrócić do poprzedniej wersji?"
Jeszcze jedna rzecz...
Czy wszyscy są na callu?
Możemy to zautomatyzować?
Rozbijmy to na mniejsze zadania.
Niech Product Owner zdecyduje.
Mamy już podobne rozwiązanie.
To techniczny dług.
To blocker.
Nie mamy capacity.
Poczekajmy na decyzję biznesu.
To zależy.
"Klient na pewno tego nie zauważy."
Dodajmy to do kolejnego sprintu.
Kto zatwierdził tę zmianę?
"A da się to zrobić bez kodowania?"
Sprawdźmy to na Daily.
Wrócimy do tego później.
To było poza zakresem.
To było na wczoraj.
Kto jest właścicielem tematu?
Musimy to doprecyzować.
Nie reprodukuję tego błędu.
"Na demo jakoś przejdzie."
"Zróbmy jeszcze jedno Daily."
U mnie działa.
Story jest za duże.
Nie było tego w wymaganiach.
"To jest najwyższy priorytet... do jutra."
"Ktoś usunął moje zmiany."
To będzie tylko 5 minut.
"Czy to jest już na Jirze?"
Bonus – bardziej humorystyczne
W dokumentacji jest inaczej.
To quick win.
Czy mamy akceptację?
"To tylko zmiana jednego przycisku."
"Przecież to jedno kliknięcie."
Musimy dowieźć.
Kto to wdrażał?
Dopiszmy taska.
Klient zmienił wymagania.
Zróbmy PoC.
To temat na retro.
Nie zdążyliśmy przetestować.
Trzeba zrefaktoryzować.
SM nie jest potrzebny w zespole.
To nie bug, to feature.
Po co nam raporty?
Zróbmy szybki sync.
Czy mamy estimate?
Priorytety się zmieniły.
"To było ustalone... chyba."
Czy to jest zgodne z procesem?
To tylko mała zmiana.
To powinno być proste.
Działało przed deployem.
Nie mamy na to czasu.
Weźmy to offline.
Zróbmy refinement.
Na produkcji działa inaczej.
"To nie mój komponent."
To kwestia komunikacji.
To nie jest MVP.
Wrzućmy to do backlogu.
To edge case.
"Możemy to zrobić w tym sprincie?"
To pilne.
a
"To wymaga jeszcze jednego spotkania."
"Nie dostałem zaproszenia na spotkanie."
Mamy zależność od innego zespołu.