Clarity Canvas: Ramy Estymacji Czterech Czynników

✅ Clarity Canvas - Podejście Miro do modelu rozbicia na cztery czynniki dla estymacji

Model ten pomaga nam ocenić gotowość i estymować bardziej dokładnie poprzez wykraczanie poza rozmiar i zrozumienie tego, co mogłoby nas spowolnić.

Opisz opis i kryteria akceptacji dla user story. Bez tych elementów nie możemy nawet rozpocząć user story. Podziel każdą user story na:

🔗 1. Zależności

Czy ta historyjka zależy od innego zespołu?

Lub innej historyjki?

Czy czekamy na projekt / API / środowisko?

Przykład oceny:

0 = brak

1 = mała zależność (wewnętrzna, łatwa do rozwiązania)

2 = umiarkowana zależność

3 = zewnętrzna zależność (platforma, dostawca, inny zespół)

🚧 2. Blokady

Czy coś powstrzymuje nas od rozpoczęcia tej historyjki?

Coś, czego zespół nie może rozwiązać w ramach sprintu?

Ocena:

0 = brak blokady

2 = potencjalna blokada

3 = aktywna blokada

⚠️ 3. Ryzyka

Czy istnieje ryzyko, że coś może nie działać zgodnie z oczekiwaniami?

Czy dotyka czułych obszarów kodu?

Czy są potencjalne problemy z wydajnością lub bezpieczeństwem?

Ocena:

0 = brak ryzyka

1 = niskie ryzyko

2 = średnie ryzyko

3 = wysokie ryzyko

❓ 4. Nieznane

Niepewność co do implementacji?

Konieczność eksploracji/analiz?

Brak jasności co do kryteriów akceptacji?

Punktacja:

0 = brak nieznanych

1 = niewielka nieznana kwestia

2 = pewne badania potrzebne

3 = poważna nieznana kwestia / niejasne kryteria akceptacji

📊 Zbierz to wszystko: „Wynik Gotowości Historii”

Dla każdej historii zespół wypełnia siatkę 4-pól i przyznaje puntu.

Następnie całkowity wynik =

Zależności + Ryzyko + Nieznane + Blokady

Przykład:

Zależności → 3

Nieznane → 1

Ryzyko → 0

Blokada → 3

Łącznie = 7

🚦 „Sygnalizacja świetlna” na Gotowość Sprintu

Użyj całkowitego wyniku do szybkiej oceny gotowości historii:

🟩 0–3 → BEZPIECZNE do włączenia w sprint

Historie są proste, niskorisksumują, mało zależności.

🟨 4–6 → PRZEGLĄD przed zobowiązaniem

Wymagają one rozmowy:

Czy możemy zmniejszyć zależności?

Czy możemy to podzielić?

Czy możemy usunąć niewiadome przed wprowadzeniem do sprintu?

🟥 7+ → NIE GOTOWE (wymaga dopracowania)

Ta historia jest problematyczna.

Zwykle dostrzeżesz:

Zbyt wiele zależności

Niewiadome, które w rzeczywistości są blokadami

Brakujące doprecyzowania

To zapewnia, że twój zespół nie wprowadza ryzykownych historii do sprintu i zamiast tego najpierw je odpowiednio dopracowuje.

💡 Na przykład

Mamy 3 zależności, ale 1 niewiadomą, która jest blokadą → prawdopodobnie ta historia nie może zostać włączona do sprintu.

Przekształcone do modelu:

Zależności = 3

Niewiadome = 3 (niewiadome = blokada)

Ryzyko = może 0

Blokada = 3

Łącznie = 9 →

🟥 CZERWONY → nie gotowe.

🔥 Dlaczego to działa

• Uczynić estymację obiektywną

• Pomaga zespołowi powiedzieć „nie” niejasnym historiom

• Zmniejsza niespodzianki w trakcie sprintu

• Pomaga Product Ownerowi wiedzieć dokładnie, co naprawić

• Przemienia refinowanie w dyskusję opartą na danych, a nie domyślanie się