Sprints de 1 semana, daily de 5 minutos (não precisa mais), retrospectiva de 1 hora, planejamento de 2 horas (talvez esse precisasse de mais).
Prioridades vem da equipe de negócio ou diretoria, mas equipe de dev dá alguns palpiptes.
O backlog é grande mesmo, acredito que isso seja comum em todos os lugares.
Algumas coisas no processo até funcionam, outras são só para cumprir a burocracia.
Sprint de 1 semana já ajuda bastante. O problema do Scrum na maioria das empresas é que virou ritual obrigatório sem ninguém questionar o porquê de cada cerimônia.
Daily de 5 minutos só funciona de verdade se o time se comunica fora dela, senão é só uma daily de 30 minutos comprimida.
O backlog grande eu vejo como sintoma: normalmente significa que o time virou executor de demandas em vez de resolver problemas reais. Itens que entram e nunca saem costumam ser o sinal mais claro disso.
Como seu time decide o que realmente entra na sprint versus o que fica parado no backlog?
A equipe de negócios passa o que eles precisam, às vezes tem prazo legal etc.
Nós definimos a complexidade e uma estimativa de tempo de cada item.
Montamos baseado no tempo disponível e nas necessidades e urgências de cada coisa.
Esse modelo funciona quando tem respeito mútuo entre as partes. O problema que vejo mais comum é o business definir complexidade junto com a prioridade: 'preciso disso amanhã e tem que ser simples'. O Scrum não quebra por falta de processo, quebra por falta de confiança entre as áreas.