O Product Backlog é, no Scrum, o repositório dos requisitos de um projeto, ou seja, o que precisa ser feito para o desenvolvimento do produto. Esses requisitos são, de uma forma geral, representados como histórias, ou melhor, histórias de usuários. Histórias de usuários assumem normalmente uma forma "um usuário quer que o produto tenha uma determinada funcionalidade ou capacidade, com um determinado propósito". Logicamente, outros detalhes e documentação podem e devem ser fornecidos.
No entanto, nem todo item do Product Backlog necessariamente representa uma história. O Product Owner pode inserir no product backlog itens que representam partes do produto, mas que ele ainda não detalhou o que deve ser implementado. Esses itens são chamados de épicos.
O product backlog é composto de épicos e histórias; os épicos estão num nível mais baixo de prioridade, e as histórias estão num nível mais alto de prioridade. Na realidade, não é a diferença que define a prioridade, mas a prioridade que permite a diferença. Itens de maior prioridade contêm descrições mais detalhadas e estão preparados para compor uma sprint. Os épicos, de menor prioridade, definem as futuras releases.
Quanto menor a prioridade de um item, menor a preocupação com a descrição do mesmo, mas quanto maior a prioridade de um item, maior deve ser a preocupação em detalhá-lo e descrevê-lo no Product Backlog. O nível de detalhamento das descrições das histórias interfere diretamente nas estimativas de esforço informadas pela equipe. Isso não quer dizer que quanto mais bem descrita e detalhada estiver uma história menor será a estimativa de esforço. Significa que é menos provável a equipe errar na estimativa de esforço dada para uma história, ou seja, quanto mais bem detalhada uma história, melhor será a sua estimativa.
A equipe deve a
valiar se o detalhamento da história a ser pontuada respeita a definição de história preparada. Estimativas mais precisas implicam em maior segurança da equipe na implementação da história, pois a equipe conseguiu alcançar o entendimento da necessidade do Product Owner. Maior segurança implica em maior produtividade e eficiência, e maior eficiência implica na definição da velocidade da equipe com mais precisão. O benefício da equipe ter uma velocidade média constante e precisa é a possibilidade de planejar melhor as sprints e também as releases, que dão a visão de médio e longo prazo da preparação do produto. É importante o compromentimento do Product Owner com o projeto de forma a manter o Product Backlog atualizado e com as histórias mais prioritárias descritas com maior nível de detalhe, para que a equipe trabalhe melhor na pontuação de cada item do product backlog. Se necessário, o Product Owner pode e deve possuir uma equipe sua, de apoio, para o detalhamento e a preparação da documentação necessária para a implementação da história. Além é claro, de contar com a ajuda do Scrum Master para tratar o Product Backlog, como já previsto no Scrum. Mais isso fica para uma próxima conversa.
Suas estimativas são precisas? Você consegue definir épicos e prever releases? Traga para cá a sua experiência também.
Estou passando por um dilema na minha empresa que tem a ver com as perguntas lançadas no final deste post.
Temos um projeto complexo de grande porte para desenvolver e o conselho deseja obter uma “noção” de prazo para a entrega deste projeto ao mercado, até porque isto envolve decisões estratégicas. Porém levaremos vários meses elaborando somente o backlog (no nível de histórias) para se chegar a esta noção de prazo.
Então estamos encurtando este tempo, elaborando o backlog apenas com épicos e a partir dele estimando com a equipe para se chegar nesta noção de prazo. Sabemos que com isto o percentual de desvio será maior comparado a decomposição destes épicos no nível de histórias.
Mas pegando o caso de uma fábrica de software que precisa dar uma resposta rápida frente ao pedido do cliente, é assim que é praticado?
Quais recomendações vocês sugerem quanto ao nível de decomposição de um épico (sem chegar na história de fato) para que seja possível de ser estimado pelo time?
Vocês conhecem algum material relevante ou alguém com pedigree que possa dar embasamento no caminho que deve ser seguido para esta situação?
Olá Marcos!
Se você já tem esses épicos, usá-los para definir o prazo para esse projeto é uma opção válida sim, porém a equipe pode sim ter dificuldades para estimá-las. Se ainda não houvessem esses épicos, mas sim uma ideia do escopo o prazo poderia ser definido como se faz nos métodos tradicionais. Ou seja, isso independeria de estar usando ou não Scrum.
Definido o prazo e o custo, na agilidade a diferença é que o dono do produto estará junto da equipe definido e priorizando o que tem de mais valor para ser desenvolvido dentro do prazo e do custo previamente definido. Dessa forma o que teremos ao final não é seguir escopo, mas sim reagir a mudanças e entregar um produto que tenha valor, que será usado, e não um produto que atende escopo.
Se vocês tiverem dificuldades em definir o prazo, tente pensar em releases. Planejando-as com os épicos pode ficar mais fácil chegar ao prazo. Lembrando que na agilidade a variável é o escopo da release e não a data.
E respondendo a sua pergunta: "Vocês conhecem algum material relevante ou alguém com pedigree que possa dar embasamento no caminho que deve ser seguido para esta situação?" Sim, que tal uma conversa inicial por email? Acho que poderemos ajudá-lo.
Se tiver interesse nosso email é: comercial@gpetec.com.br