segunda-feira, 25 de março de 2019

Product Backlog e Scrum Master. Uma ligação mais próxima do que se pensa

De acordo com o framework Scrum, o Product Owner (P.O.) é o responsável pela criação, priorização e gestão, do Product Backlog (P.B.). Este é um fator importante, para uma boa gestão do produto. Entretanto, o mesmo framework diz que o Scrum Master "serve" o P.O. na busca por técnicas, que resultem numa gestão eficaz do Product Backlog e garantir que o P.O. entenda como maximizar seu valor. Mas o que este "servir" significa, então?!

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. 

Resultado de imagem para Product Backlog e Scrum MasterRefinamento, é 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.

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.