To działa, bo Scrum nie narzuca hierarchii służbowej — narzuca ramę pracy. Hierarchia u Ciebie dotyczy delegacji i eskalacji, a nie “zarządzania ludźmi”.
W Scrumie nie chcesz, żeby kanał #officialOrders stał się backlogiem.
Dlatego:
• Backlog sprintu trzymasz w CRM (np. AgentTask / backlog item)
• Order jest formalnym poleceniem wykonania konkretnego elementu backlogu lub zadania wspierającego sprint.
Praktycznie:
• Sprint Planning: Maya/PM tworzy pakiet orderów powiązanych z elementami sprintu
• Daily: update_order_status działa jak krótkie “co robię / co blokuje”
• Review: review_order to “Definition of Done + ocena jakości”
• Retro: my_orders + statystyki = dane do usprawnień
Watchdog jest świetny, ale w Scrumie trzeba uważać, żeby:
• nie wprowadzać “ukrytego managera”
• nie wymuszać mikro-zarządzania
Twoje reguły są ok, tylko 1 drobna korekta Scrumowa:
• RESOLVED bez review > 48h → auto-review (3/5)
✅ OK jako “safety net”, ale w Scrum lepiej traktować to jako:
• tymczasowe zamknięcie administracyjne, a nie realne “DONE”
• i dodać flagę autoReviewed=true (albo w notes)
To utrzyma jakość i nie będzie fałszowało “Definition of Done”.
⸻
Minimalny Scrumowy rytm (2 tygodnie) – jak to wygląda w Twoim systemie
• Sprint Planning (Day 1)
Maya/PM: create_order pakietowo (na podstawie backlogu)
• Daily (codziennie)
agenci używają update_order_status + BLOCKED kiedy trzeba
• Refinement (1–2x w sprincie)
BA/PM/Tech Lead – doprecyzowanie opisów orderów (nie tworzenie nowych “na dziko”)
• Sprint Review (Day 14)
review_order dla wszystkiego co “DONE”
• Retro (Day 14)
my_orders + ratingi + czasy → wnioski procesowe