Entrega de Valor e Trabalho de Valor – Entenda a diferença e como isso pode afetar seus gráficos Burn-Up e Burn-Down
Entrega de Valor ao cliente é o principal objetivo de uma sprint. Mas para gerar um entregável de valor, é preciso que muito trabalho seja feito pelo time. Isso envolve arquitetura, UX, testes, codificação etc. Mas ainda é muito comum encontrarmos “faseamento” de projetos em formato de Sprints e o efeito colateral disso é Muito Trabalho e Pouca Entrega.
Mas o trabalho do time só tem valor quando gera um entregável?
Não, todo trabalho para gerar o entregável tem muito valor! Mas não tem valor para o cliente final. Já tive essa discussão com várias pessoas, em projetos diferentes, com níveis hierárquicos diferentes.
Entregar um protótipo de tela não agrega valor algum ao cliente final e nem a empresa, não gera receita, não reduz custo. É apenas uma parte da Entrega de Valor. Assim como entregar um código complexo, não adianta de nada se a parte de UX não estiver pronta.
Mas então nunca vai ter uma estória de UX ou de Arquitetura (por exemplo)?
Não. Pelo menos não deveria. Até porque, a estória não é uma entrega de um único membro do time e é sempre focada em resolver um problema do usuário. A entrega deve ser de TODO o time.
O Scrum Master precisa reforçar muito bem esses conceitos. Principalmente quando está trabalhando com um time que ainda não é maduro ou desconhece o Scrum.
“Não existe estória técnica ou faseada. Estórias são de usuário e são fatiadas. “
Impacto direto no Burn-Down e Burn-Up
O problema pode fica ainda maior quando o PO coloca no backlog “estórias faseadas” ou “estórias técnicas”, pontuam essas estórias, montam um gráfico Burn-down ou Burn-up e mostram para a alta gerência acompanhar o andamento do projeto. A leitura do gráfico fica distorcida, pois parece que o time está entregando muito e na verdade não está entregando nada. As Sprints contêm muito trabalho de valor mas não entregaram nenhum valor.
Os gráficos Burn-down e Burn-up são os principais reports de um time Scrum. A distorção deles é como mostrar um relatório de acompanhamento de projetos “Maquiado”, ou seja, os números não traduzem a realidade.
Resultado:
- Falta de transparência
- Cobrança por cronograma
- Falta de confiança no time
- Resistência ao Ágil
- Demora para obter feedback do cliente
- Maior as chances de haver mais custo do que receita
Como corrigir essa disfunção?
Não existe receita de bolo, mas o primeiro passo é rever o backlog e o fatiamento dele. Trabalho para o Scrum Master e o Product Owner. Além de trabalhar bem com o time todos os conceitos que o envolve o Ágil e o Scrum.
Essa não é a única medida a ser tomada, mas ao meu ver, é uma das principais.
Esse post abordou muitos conceitos, como : Estória de Usuário ou User Story, fatiamento de backlog, gráficos Burn-Up e Burn-Dow, Story Points, Entrega de Valor. Então ainda temos muito para discutir e trocar sobre esses assuntos. Mas quem tiver dúvidas, pode me procurar que será um prazer ajudar no que estiver ao meu alcance!
Informações sobre a autora:
Carla Bertrand é Agile Coach, Apaixonada por transformação ágil,
transformação digital, otimização de processos e Kanban.
