O que é DEEP?
DEEP é um acrônimo para: Detalhada, Estimada, Emergente e Priorizada. Originalmente: Detailed, Estimated, Emergent and Prioritised.
Esses são alguns conceitos que são usados para definir se o Backlog do Produto (Product Backlog) “está bom”.
Claro que para um Produto ser bem sucedido não basta apenas ter um Backlog de Produto DEEP.
Um produto bem sucedido é – teoricamente – aquele que possui um Backlog do Produto com items DEEP, que estejam alinhados com a visão/objetivo do produto.
Vamos aos detalhes:
Detalhada
- As histórias que estão na parte de cima do Backlog do Produto precisam ter o detalhamento suficiente para que ela seja entendida e desenvolvida pela equipe responsável. Entenda que “detalhamento suficiente” varia de atividade para atividade. Para algumas somente algumas palavras são necessárias, para outras pode conter wireframes, modelos relacionais ou uma série de outras informações.
- As histórias que estão no meio do Backlog do Produto já devem possuir algum nível de detalhamento, mas ainda muito superficial.
- As histórias que estão do meio para baixo podem ser entendidas como épicos. Elas devem conter apenas algumas palavras para que ela seja amplamente entendida.
Essa ideia também é chamada de “Product Backlog Iceberg”. Pois apenas os itens que estão acima da superfície “da água” são “visíveis” e por isso estão bem detalhados e o nível de detalhamento vai diminuindo quanto menor a prioridade do item.
Abaixo uma imagem para uma melhor visualização deste conceito.
O nível da água seria a linha horizontal mais alta dentro da pirâmide.
Fonte da Imagem: https://leanpub.com/site_images/MasteringBacklogs/IcebergSlide.jpg
Como referência eu diria que você precisa ter detalhadas as histórias que estão previstas para serem desenvolvidas nos próximos 2 sprints.
Estimada
Todas as histórias do Backlog do Produto devem estar estimadas pelo time de desenvolvimento. O ideal é que seja usada alguma unidade de estimativa de medidas como por exemplo “Esforço” ou “Pontos de Histórias” – fuja de horas :).
Claro que quanto menor o detalhamento da história mais imprecisa será sua estimativa. Para contornar isso, a medida que as histórias vão “subindo no Iceberg” – ou seja, sendo detalhadas – elas também vão sendo re-estimadas pela equipe.
Mas então, qual é o objetivo em estimar algo que não está pronto?
Essas estimativas são usadas pelo Product Owner para desenhar um Plano de Release ou o Roadmap, claro que ele não pode se comprometer com uma data exata por causa das estimativas imprecisas, mas com certeza ele consegue prever se a entrega de determinada história será feita no próximo mês, trimestre, semestre ou ano. 🙂
Emergente
Novas histórias vão emergindo a todo o momento no Backlog do Produto, isso natural acontecer a medida que o produto vai sendo melhor entendido por todos os envolvidos. Estas “novas necessidades”, em modelos tradicionais de gestão de projetos, seriam tratados como mudanças de escopo. No modelo ágil não existe este conceito pois o Backlog do Produto é re-priorizado constantemente e por isso, se uma história emergiu, e ela é essencial para o produto, ela poderá ser colocada para desenvolvimento no próximo sprint.
Priorizada
Uma importante característica é a constante (re-)priorização do Backlog do Produto como já citei anteriormente. Geralmente as histórias devem ser priorizadas levando em consideração o valor dela para o negócio.
Você pode estar se perguntando: “Atividades de performance ou alterações na configuração dos servidores não trazem valor ao negócio. Como vou priorizar isso?” Qualquer atividade pode trazer valor ao negócio.
Sem um ajuste de performance um site e-commerce pode cair e, consequentemente, os clientes não conseguirão comprar. Se você ajustar a performance isso não ocorrerá. Neste caso, o ajuste de performance não traz valor imediato para o negócio mas evita prejuízo no futuro. O que é certamente valor para o negócio 🙂
Um último ponto, como o Backlog do Produto é uma lista única priorizada, não existem duas histórias com a mesma prioridade.
Uma história é menos prioritária do que aquela que está acima dela e mais prioritária do que a que está abaixo dela.:)
Aqui finalizo o conceito DEEP.
Prometo em breve fazer um artigo explicando a frase “O ideal é que seja usada alguma unidade de estimativa de medidas como por exemplo “Esforço” ou “Pontos de Histórias” – fuja de horas :)” que usei na Estimativa.
Achou interessante? Tem dúvidas ou discorda de algo?
Me adicione ao 
e vamos conversar.
Outros dois posts relacionados à este: