Primeiro, não significa que o Scrum Master atuará na escrita dos Product Backlog Items (P.B.I.) - ou histórias -, na priorização de itens ou intercederá, nas conversas entre o P.O. e seus Stakeholders. Isto deve ser responsabilidade do P.O.
Além disso, devemos lembrar que o time de desenvolvimento é responsivo ao P.O. Isto é, ele deve esperar que o P.O crie e priorize os itens, em que o time trabalhará - salvo exceções. E é neste ponto, que o Scrum Master torna-se importante, no processo.
O Scrum Master deve certificar-se, que o P.O. possui um backlog preparado e priorizado. Parece trivial, que isso ocorra; mas é impressionante o número de times que trabalham sem um backlog mínimo. Uma boa prática, é ter um backlog com itens para 2 Sprints. Assim, o time poderá antecipar dependências e bloqueios e, caso o projeto / produto tome uma nova direção, não haverá muito trabalho perdido. Vale lembrar que, ter um bom backlog significa que todos seus itens possuem o nível de informações necessárias, para que o time entenda o que deve ser feito - o que varia entre times e itens do backlog.
Porém, apenas ter um backlog não garante que este esteja apto à ser desenvolvido. Para tal, é importante que o time o conheça bem, assim como que estime o esforço necessário, para sua entrega. O framework Scrum sugere um evento chamado de Refinamento, como forma de preparar o backlog, para seu desenvolvimento.
Refinamento, é um evento que deve ocorrer durante toda Sprint, com tempo máximo de 10% de todo seu tempo útil. Assim, se uma Sprint tem prazo de 2 semanas, o Refinamento deverá tomar, no máximo, 8 horas (10% de 80 horas). Nele, o P.O. apresenta o backlog para o time, para que este possa tirar dúvidas, validar que possui toda habilidade necessária, para entrega, e estimar seu esforço.
Portanto, novamente o Scrum Master deve garantir que os eventos de refinamento ocorram, durante a Sprint. Quanto mais cedo na Sprint este evento iniciar, mais rico será seu resultado; pois o time poderá ter mais tempo para entender os itens, do backlog, e estudá-los, antes da reunião de planejamento - ou Planning.
Há, ainda, outros pontos onde o Scrum Master apoia, ou "serve" o P.O, em relação ao Product Backlog. Através do acompanhamento da velocidade do time - ou capacidade de entregas, por Sprint - o P.O. pode avaliar o prazo necessário, para finalização de uma funcionalidade, MVP ou release.
Há, ainda, outros pontos onde o Scrum Master apoia, ou "serve" o P.O, em relação ao Product Backlog. Através do acompanhamento da velocidade do time - ou capacidade de entregas, por Sprint - o P.O. pode avaliar o prazo necessário, para finalização de uma funcionalidade, MVP ou release.
Enfim, o Scrum Master não é o guardião do Product Backlog, tão pouco seu representante. Mas é certo que suas relações são bem próximas.
Sempre acompanho o blog e indico aos professores do gestão agil de projetos, orgulho de acompanhar. Ótimo blog
ResponderExcluirOlá Helloiza, obrigado pelo feedback.
ResponderExcluirPalavras assim nos motivam, a continuar com o blog :)