Na Invillia, toda quarta-feira, ao meio dia, paramos uma hora para nos nutrir com as dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Esta troca de experiências tem o propósito de conectar pessoas dispostas a compartilhar conhecimentos através de um evento online e descontraído. Somente para quem adora agilidade, novidade e inovação. Se a tecnologia está no sangue, a gente faz questão de deixá-la circulando cada vez mais_
NA VEIA_ Construção de “Backlog”: planejamento ágil em apoiar o trabalho do Product Owner (PO)
5 minutos de leitura
No artigo de hoje, compartilhamos os principais aprendizados da incrível edição sobre a “Construção de backlog”, apresentada pela especialista Renata Ortega, que possui vasta experiência no assunto.
Construção de “backlog” saudável através do fatiamento de itens
Um backlog saudável faz com que um time de desenvolvimento possa iniciar e finalizar suas tarefas sem impedimentos, realizando o que precisa ser feito e com sentido para todos, não apenas ao Product Owner (PO) ou ao usuário do produto.
Para a construção do backlog, no entanto, é necessário planejar toda a qualidade do produto propondo o “fatiamento” de itens dentro de uma história.
Questionamento inicial: se o PO do meu time não escreve histórias, como meu backlog será saudável?
Muito se fala sobre a necessidade de realizar uma dinâmica envolvendo stakeholder, pesquisa, UX, e uma parede grande com post-its coloridos para construir um backlog sem documentação, afinal, é só ter um “card” com uma frase e pronto.
Entretanto, um backlog saudável não deve possuir uma história que seja do tamanho de um épico, ou seja, uma história não deve levar mais do que uma sprint para ser desenvolvida. Sem a construção deste backlog, é difícil saber qual o trabalho deve ser feito, seja ele de back, front, qualidade etc., cada um com suas atividades, sem esclarecimentos quanto ao prazo das tarefas e, principalmente, sem saber exatamente qual o objetivo não conseguimos saber se o time está remando para o mesmo lado, precisamos ter objetivos claros e únicos em cada história de usuário, para que possamos saber qual o trabalho deve ser realizado visando atingir um único objetivo e assim termos realmente um trabalho em equipe.
Técnicas para construir o backlog
Há técnicas muito faladas para a construção do backlog que podem ser resumidas em três principais caraterísticas:
- O backlog deve ser DEEP, ou seja, profundo, detalhado, emergente e priorizado;
- As histórias devem ser INVEST, um acrônimo que significa independentes, negociáveis, com valores de demanda, estimáveis, pequenas (para caber dentro da SPRINT) e testáveis;
- As tarefas sejam SMART, portanto, específicas, mensuráveis, alcançáveis, relevantes e temporais, visando atingir o objetivo final dentro do planejamento.
Além disso, há outras características e técnicas igualmente importantes para as técnicas de construção do backlog que são sugeridas pelo escritor Mike Cohn como a técnica S.P.I.D.R.:
- Spike, para quebra da história e planning poker;
- Paths, descrevendo os passos de um fluxo, de modo que, ao olhar para a demanda de entrega, se considere o caminho que será percorrido pelo usuário;
- Interfaces, com tudo mapeado em telas;
- Dados, que dizem respeito aos seus tipos, ou seja, cálculos complexos de acordo com algum tipo de dado;
- Regras de negócio bem detalhadas e vinculadas por trás do back end.
Com essas técnicas, é possível olhar para um fluxograma, diagrama ou fluxo de interação do usuário e quebrá-lo visualmente através de caminhos, telas, dados criando quebras de histórias para chegar ao backlog ideal, que pode ser ordenado no formato de uma pirâmide:
Na figura, a iniciativa superior, denominada Canva, traduz o objetivo da companhia; deste Canva, há vários épicos, por meio dos quais é possível inserir, de maneira “macro”, todos os tópicos necessários para se trabalhar; para cada épico, posteriormente, é necessário criar e entender o que se deseja fazer e criar um fluxo lógico e assim quebrá-lo em histórias utilizando a técnica do Spider, pos exemplo; para que se originem tarefas, que são o plano para desenvolver as histórias e se chegue ao épico visando atingir o objetivo final do produto e da companhia.
Esta pirâmide é a maneira mais simples de manter o backlog DEEP (detalhado e priorizado, atendendo às demandas emergentes) e “quebrando” o maior objetivo que a companhia quer alcançar (que pode ser OKR’s, iniciativa etc.).
Backlog DEEP
- O que é o Canva
Uma iniciativa do produto ou da companhia.
Exemplo: Chegar à Lua! Um objetivo grande que deve ser quebrado e é inalcançável.
- Épico
Um passo do plano para chegar até o objetivo final do Épico.
Exemplo: Criar um foguete. Afinal, para atingir o objetivo de chegar à Lua, é necessário utilizar um foguete, desenvolver o combustível para o foguete, fazer com que seja possível engatar a ré, a direita, esquerda etc.
- História de usuário
Um plano um pouco mais detalhado, que faz parte do Épico.
Exemplo: Colocar cadeiras no foguete para o astronauta se sentar. Porque ninguém aguentaria ir até a Lua em pé. Assim, esta seria a história do usuário: para construir o foguete, é necessário ter cadeiras com quatro pés e encosto, volante e cinto de segurança.
- Critérios de aceitação
Algo descritivo, ou seja, descrever como deve ser a cadeira para o astronauta – que neste caso é o usuário.
Exemplo: É necessário ter três cadeiras para que o astronauta possa se sentar durante o voo para a Lua. Para isso, envolve critérios de aceitação para negociação com o PO de modo que o resultado seja um cenário de teste a fim de aplicar um Test Driven Development (TDD) para prever o que vai acontecer.
Assim, além de um plano, a história de usuário é uma “negociação” do time com o PO, e, por isso, é importante que se tenha um mínimo de documentação que ofereça um “Norte” de tudo o que se espera daquele produto. Para tanto, há um cenário de teste e planejamento, considerando a qualidade das entregas, desde o começo da história, até o alinhamento de expectativas com o PO e a previsão do que será entregue pelo time. O objetivo é manter as expectativas alinhadas com o time trabalhando de maneira concisa do começo ao fim.
- Tarefa
Um plano para cumprir e entregar a história.
Exemplo: Criar uma estrutura da cadeira. Ou seja, o time cria uma tarefa para criar os pés da cadeira, outra tarefa para criar o encosto da cadeira (que, segundo o cenário de teste no critério de aceitação, vai constar que o encosto deve ser almofadado e de madeira) etc. Com isso, cria-se um plano para a execução e cumprimento de todas as tarefas por meio da história que será desenvolvida, sendo que a tarefa significa o “plano” para se cumprir a entrega da história.
Compartilhamento de histórias: “pontes” de tarefas
Toda companhia possui seus objetivos, sendo que os épicos são definidos a partir de iniciativas “quebradas” em vários planos e as histórias onde o time vai atuar com o detalhamento para o PO.
Assim, a ideia da construção do backlog pode ser exemplificada com a criação de várias “pontes”: das tarefas do time com a história, da história com o time e o PO, e do PO e do épico com o Canva – que é a companhia. Além disso, para conseguir “fatiar” histórias, é necessário usar e abusar de artefatos com o time e PO, utilizando ferramentas de compartilhamento de telas.
No final, é tudo sobre comunicação! Isso porque as histórias que o time cria em conjunto com o PO significam “negociação”, ou seja, comunicação e interação entre pessoas para saber o que cada um está fazendo e o que será entregue no final, baseados em um plano de tarefas.
Para quem utiliza a metodologia ágil de trabalho KANBAN, a construção do backlog permite saber qual tarefa e por quê cada desenvolvedor está trabalhando e entregando, para a mesma história. Já para usuários de SCRUM, a construção possibilita saber quais histórias serão entregues dentro de uma SPRINT e quais tarefas são necessárias e fazem parte de cada história.
Como a Invillia escreve histórias
Na Invillia, os times desenham esta “ponte”, escrevendo histórias de modo que o PO saiba o que o time está desenvolvendo e entregando, além de manter o cuidado e atenção com o cliente e o produto por meio das seguintes informações:
- Descrição, para que o time saiba o que a história vai tratar, ou seja, um resumo do porquê foi criada e o que visa atender, como estava e como vai ficar;
- História, para saber quem quer, o que, como, porquê e para quê – trazendo o objetivo final;
- Critérios de aceitação, que descrevem o que realmente vai acontecer e o que precisa ser feito e entregue, visando partir para os cenários de teste que garantirão o alinhamento de entrega, com tudo o que foi cumprido para atingir o objetivo final.
Na Invillia temos o know-how e a experiência nas tecnologias, abordagens e metodologias mais inovadoras do mercado, sugerindo e aplicando </ a melhor > em cada caso. Estamos sempre estudando, enriquecendo conhecimentos, antecipando o que está por vir, testando, indo mais além. Criamos e continuamente aprimoramos ao lado de quem está revolucionando seus mercados com produtos e serviços digitais inovadores, resilientes, robustos, escaláveis e com a melhor experiência de utilização. E tudo isso a partir de um ponto: nosso Global Growth Framework _
