Bugi się zdarzają. Ignorowanie ich albo traktowanie jak obywateli drugiej kategorii to prosta droga do rozwalenia sprintu. Pogadajmy o tym, jak poprawnie szacować błędy w Scrumie, nie zabijając przy tym flow zespołu ani jego velocity.
Czy w ogóle szacować bugi?
Tak. Bugi zabierają czas. Czas to wysiłek. Wysiłek warto oszacować.
Ale nie każdy bug to to samo:
- 🐛 Drobna kosmetyka? Może lepiej po prostu naprawić.
- 🐞 Złożony regres? Traktuj jak normalną historyjkę.
- 🚨 Krytyczny w produkcji? Napraw od razu, oszacuj później.
W skrócie: Szacuj błędy, jeśli mają wpływ na velocity albo zajmą więcej niż ~15 minut.
Jak szacować bugi w Story Pointach
Błędy są często mniej przewidywalne niż nowe funkcje. Oto, jak sobie z tym radzić:
- 📊 Używaj tej samej skali, co dla nowych funkcji (np. Fibonacci).
- 🧠 Szacuj czas potrzebny na analizę, nie tylko fix.
- ⚖️ Balansuj precyzję i tempo — nie jesteś pewien? Daj przybliżoną wartość i wróć później.
Przykład:
Bug: "Login zwraca 500 po flow OAuth" Story Points: 3 (w tym debugowanie, fix, retesty)
Gdzie wrzucać bugi w sprincie
Masz kilka opcji:
- ⏩ Do sprintu — jeśli znany przed planowaniem.
- ⛔ Poza sprintem — dla krytycznych hotfixów (trackowane osobno).
- 📥 Do backlogu — jeśli nie pilny, traktuj jak każdą inną taskę.
Trzymaj board w ryzach: nie zaskakuj zespołu ukrytymi bugami w trakcie sprintu.
Częste błędy przy szacowaniu bugów
- ❌ Brak szacowania — rozwala velocity tracking.
- ❌ Wszystkie bugi są „pilne” — zespół traci skupienie.
- ❌ Wrzucanie wszystkiego do jednego „bugfix taska” — ukrywa złożoność.
Nie bądź leniwy. Każdy bug jest inny. Potraktuj go jak należy.
Jak ScrumPoker.it może pomóc
Tak, bugi też możesz estymować na ScrumPoker.it. Sprawdza się świetnie przy:
- 🔒 Anonimowym głosowaniu, jak nikt nie chce powiedzieć „8”
- ⏱️ Szybkich estymatach na groomingach
- 💬 Wywoływaniu dyskusji przy trudniejszych błędach
Wrzucasz buga do sesji — i po chwili masz konsensus.
🎯 Spróbuj oszacować buga
FAQ
❓ Czy bugi liczą się do velocity?
Tak. Jeśli są oszacowane i są częścią sprintu — liczymy.
❓ Jak szacować nieoczekiwane bugi?
Nie szacujesz. Trackuj osobno (np. tag „unplanned work”) i omawiaj na retro.
❓ Co jeśli QA znajdzie buga po starcie sprintu?
Zrób triage. Jeśli poważny — napraw i zaloguj. Jeśli nie — wrzuć do backlogu na następny sprint.
Na koniec
Bug to nie dopisek na końcu sprintu — to część devu. Szacuj go jak story i Twoje planowanie będzie miało sens.
🛠️ Szanuj buga. Oszacuj. Zaloguj. Napraw. Zespół (i wykres velocity) Ci za to podziękują.