Logo Agile SchoolLogo Agile School
Logo Agile SchoolLogo Agile School
0
R$0.00 0 item

Nenhum produto no carrinho.

Entenda melhor um dos três artefatos do Scrum e como ele deve estar estruturado

O Backlog do Produto é um dos 3 artefatos do Scrum (os outros são o Sprint Backlog e o Incremento) e consiste numa lista ordenada de tudo o que é necessário para maximizar o valor do produto. Tal lista é composta por Itens do Backlog que geralmente representam melhorias, correções e débitos técnicos.

Product free icon

É importante que o Backlog do Produto esteja visível para o Time Scrum (Time) e Stakeholders a fim de promover transparência sobre o que será construído e em qual ordem será construído.

O Backlog do Produto é a única fonte de requisitos do Produto. Ou seja, tudo o que for relativo ao Produto deve estar contido apenas nele.

O único responsável pelo Backlog do Produto é o Product Owner (PO) e, embora ele possa delegar a ordenação do Backlog para alguém do Time de Desenvolvimento, ele continua sendo o responsável por ele. Portanto, a fim de evitar conflitos de interesses, todo Backlog deve mantido por apenas um Product Owner.

Como o Backlog do Produto está estruturado?

Os primeiros Itens do Backlog são aqueles que são mais importantes para o produto em dado momento. Eles devem estar mais detalhados e serem mais bem compreendidos por todos do Time. Dessa forma, são os Itens mais elegíveis a serem desenvolvidos nas próximas Sprints.

Por sua vez, os Itens mais ao fundo são aqueles que ainda não estão bem compreendidos, precisam ser refinados para melhor detalhamento e serão desenvolvidos mais tardiamente, sem previsão esperada para as próximas Sprints. Imagina-se que com mais detalhes, a estimativa seja mais assertiva e seja mais fácil atingir o Objetivo da Sprint dentro do Timebox.

O critério utilizado para ordenação do Backlog é definido pelo PO, que pode utilizar diversas técnicas conforme a necessidade, como por valor, por prazo (caso seja uma ação de marketing ou determinação legal), por risco, por dependência técnica ou de negócio…

Os critérios são muitos e cabe ao Product Owner decidir qual o melhor critério para o momento vivido pelo Produto. Já a estimativa é de responsabilidade do Time de Desenvolvimento que são os executores. Contudo, o PO ajuda na determinação e entendimento do escopo.

Uma imagem contendo uma explicação sobre o Backlog do Produto

Por seu dinamismo, o Backlog do Produto é considerado um artefato vivo uma vez que está em constante mudança a fim de garantir a adequação e maximização do valor do Produto.

Os Itens de Backlog geralmente são escritos como Histórias de Usuários, embora o Scrum não especifique um formato padrão. Qualquer que seja a forma escolhida é uma boa prática conter uma descrição, qual a estimativa de esforço, qual o valor pretende gerar ao negócio, quais são os critérios de aceite e quais testes devem ser realizados. Esses atributos contribuem para comprovar a completude do PBI quando “Pronto”.

Características de um bom Backlog do Produto

Um bom Backlog do Produto deve ser DEEP e o PO deve ser um bom FDP. Calma, não é isso que você está pensando! Te explico abaixo cada conceito.

DEEP é o acrônimo que significa que o backlog deve ser: Detalhado apropriadamente, Estimado, Emergente e Priorizado.

Quando dizemos que o PO deve ser um bom FDP estamos nos referindo a ação do PO: Fatiar, Descartar e Priorizar.

Conclusão

O Backlog do Produto é um artefato vivo e a entrada para todo o fluxo de Eventos do Scrum. Enquanto existir Produto, existirá Backlog para ele. A priorização de melhorias, correções, débitos técnicos e refinamento é de responsabilidade do PO, que deve ser uma única pessoa para evitar conflito de interesses e dificuldade na tomada de decisão quanto ao escopo do Produto e a prioridade na sua execução.

Eleve o nível de seus conhecimentos com treinamentos oficiais da Scrum.org. Clique aqui e confira a agenda completa!

É Product Owner ou pretende atuar neste papel? Baixe agora nosso e-book gratuito “8 instâncias do Product Owner” e aprenda as diferentes formas de atuaçãono trabalho de criação de produtos/serviços e na geração de valor ao cliente.

Leia também:

Entenda como a agilidade pode ajudar neste momento, que não é novidade para alguns, mas para muitos está sendo uma realidade repentina e não programada

Um dos assuntos mais falados nos últimos dias é como encarar o home office e manter a produtividade e suporte aos times sem ter o contato físico. A situação pode parecer simples, mas o home office ainda não é uma realidade para muitos. E aí surge a dúvida, como usar a agilidade no trabalho remoto?

Para facilitar um pouco este momento atípico e repentino, separamos alguns pontos importantes que podem ajudar todas as pessoas envolvidas a trabalharem melhor e com mais agilidade no trabalho remoto.

 

 

Lembrando que se você já estava estudando sobre Agilidade e precisa dar um próximo passo, seja com treinamentos práticos ou com foco em certificação, estamos com turmas ONLINE e AO VIVO para Professional Scrum Master I e Professional Scrum Product Owner

Clique aqui e confira nossa agenda completa de treinamentos.

 

O que é a Sprint Review?

A Sprint Review é o penúltimo evento da Sprint, geralmente acontece no seu último dia e tem por objetivo a inspeção do Incremento de Produto desenvolvido naquela Sprint e adaptação do Product Backlog caso necessário.

Esse é o único evento no qual, por definição, temos a participação de pessoas externas ao Time Scrum. Esses “envolvidos” na criação do produto, seja um patrocinador, membro da área usuária, parte da governança corporativa, compliance ou qualquer papel que tenha interesse e influência sobre o escopo da solução, devem ser convidados pelo PO para estarem presentes.

Portanto, o fórum participante da Sprint Review é todo o Scrum Team (PO, SM e Dev Team) e os Stakeholders. A ideia é que todos deem feedback sobre o que já foi feito, troquem informação, discutam as oportunidades de mercado para o produto e colaborarem sobre o que vem a seguir.

Como acontece a dinâmica?

A Sprint Review tem uma dinâmica sugerida pelo Scrum Guide. O evento começa com o Product Owner falando sobre o Objetivo da Sprint e quais itens estão “Prontos” – ou seja, aqueles que atenderam a definição de pronto estabelecida – e quais não estão, caso o Sprint Backlog não tenha sido completamente concluído. Contudo, esta não é uma reunião de status e a apresentação do incremento destina-se a motivar, coletar feedback e promover a colaboração.

Em seguida, o Time de Desenvolvimento apresenta o que foi bem dentro da Sprint, que problemas ocorreram e como estes foram resolvidos, e por fim realiza uma demonstração do incremento “Pronto” e que estará disponível para ser lançado.

Por fim, o PO fornece uma visão de budget, roadmap de produto e prováveis próximas datas de entrega. Além de ser mais uma oportunidade para todos colaborarem sobre os próximos passos, possíveis dependências externas e débitos técnicos previamente conhecidos devem estar mapeados e dar transparência para todos os presentes.

Cabe ao Scrum Master garantir que o evento ocorra e que os participantes entendam o seu propósito, ensinando a todos os envolvidos a manter a reunião dentro do time-box (limite máximo de tempo). Como referência, para Sprints de 4 semanas, o time-box da Review é de 4 horas e proporcionalmente menor para Sprints menores.

 

Nenhum incremento pode ser mostrado? E agora?

Mesmo na ocasião do time Scrum não ter um incremento pronto para inspecionar, a Sprint Review deve ser mantida como uma forma de:

1º) dar transparência aos stakeholders do trabalho desenvolvido, não é porque não houve entrega de incremento pronto, que o time não trabalhou;

2º) obter feedback dos stakeholders;

3º) mostrar os avanços e problemas encarados pelo time, como esses problemas impactaram a entrega e como foram resolvidos.

Conclusão

Ciclos curtos permitem que o Time Scrum foque no objetivo da entrega de valor. A Sprint Review tem o objetivo de mostrar a entrega sem causar “distúrbios” ao time ao longo da Sprint, ou seja, como as Sprints são curtas, o loop de feedback é rápido, o stakeholder não fica descolado do andamento do produto e assim o time consegue manter o foco naquilo que é importante, evitando interrupções ao longo do desenvolvimento, e as Reviews passam a ser uma oportunidade tanto de inspecionar o incremento, quanto de adaptar o Backlog do Produto caso seja necessário corrigir o seu curso, seja por estratégia, mudança de mercado ou tecnologia.

Se por outro lado, não houvesse essa oportunidade de ao menos uma vez ao mês, stakeholders estarem alinhados, o risco do time trabalhar em algo desalinhado com a entrega de valor cresceria de forma acentuada. Se assumirmos que o plano inicial está sempre certo e não fizermos esses alinhamentos intermediários, provavelmente ao final da entrega teremos surpresas e frustrações por parte do cliente.

Durante treinamentos, conversas e no dia a dia com os clientes, vejo que muitas pessoas entendem que ser ágil está relacionado a rapidez na entrega.

Enquanto no modelo cascata, vamos na linha de levantar todos os cenários possíveis e fazer um plano muito detalhado antes de iniciar a execução, no Scrum por outro lado fala que, em cenários complexos, essa não é a melhor opção.

Num mundo VUCA, os cenários mudam com uma frequência muito grande. Neste contexto, ser adaptativo faz toda a diferença na construção de produtos complexos, como por exemplo desenvolvimento de software.

Durante minha jornada como agilista, pude observar times dizendo as frases abaixo:
Será que faz sentido fazer a Daily Scrum todos os dias?
Será que faz sentido fazermos em todas as Sprints, as Reviews e Retrospectivas?

Muitos destes questionamentos acontecem porque o Scrum Team não está enxergando valor nestes eventos.

A Daily Scrum, Sprint Review e Sprint Retrospective são os principais momentos de inspeção e adaptação do Scrum e perder esta oportunidade é um desperdício.

A grande questão que tenho visto é que a maioria dos times não está preocupada em se adaptar. Eles apenas querem ver o produto pronto.

Desta forma, estamos perdendo diversas oportunidades de melhorar como um time e entregar um produto melhor ao final de cada Sprint.

Não é a toa que, em uma das últimas atualizações do Scrum Guide, foi colocado a necessidade de priorizar ao menos um item da Sprint Retrospective e colocá-lo como plano de ação no Sprint Backlog da Sprint seguinte.

Acredito que isto tenha acontecido exatamente pelos exemplos dados acima; os times estão inspecionado e não estão adaptando nada. A regra foi colocada para incentivar a melhoria contínua.

Muitos times usam a Sprint Review para demonstrar para o P.O. os itens construídos durante a Sprint. Desta forma, o P.O. valida os itens que estão prontos ou não.

Neste cenário, gostaria de salientar dois pontos:

Como o P.O. é um membro do Time Scrum, ele deve estar junto com todos na maior parte do tempo. Desta forma, porque esperar até a Sprint Review, para validar se um item está pronto ou não?

Antecipar esta validação durante a Sprint, nos possibilita fazer os ajustes necessários e ter um incremento mais próximo de “pronto” ao final da Sprint.
Alguns times, por exemplo, colocam a validação do P.O. dentro do DoD (Definição de Ponto).

A Sprint Review é o principal evento Scrum para inspeção e adaptação do incremento gerado ao final da Sprint.
Quem são as melhores pessoas para trazer os feedbacks necessários para o time?

As pessoas que estão utilizando o produto que estamos construindo!

Desta forma, é muito importante que o P.O. convide os stakeholders (os usuários do produto estão inclusos aqui) para a Sprint Review e estimule o engajamento deles.
Uma das formas de se obter esse engajamento é disponibilizar o produto para eles utilizarem (testarem) durante a Sprint Review e assim coletar os feedbacks.

Se sua Sprint Review não conta com a participação dos stakeholders, você não está tirando o máximo de proveito deste evento do Scrum, e em muitos casos, os times que não contam com a participação ativa dos stakeholders veem a Sprint Review apenas com uma burocracia necessária por conta do Scrum.

Todos os dias, durante a Sprint temos a oportunidade de adaptarmos o planejamento feito durante a Sprint Planning e corrigir o curso para o atingirmos o Objetivo da Sprint.

A Daily Scrum, por exemplo, é o momento em que o Development Team deve refletir sobre como ele vem trabalhando e se desta forma irão atingir o Objetivo da Sprint. Não é apenas dizer o que fizemos no dia anterior, e o que vamos fazer nas próximas 24 hora, mas sim, uma conversa colaborativa entre os membros do Development Team para identificar se existe algum ajuste necessário a ser feito no planejamento. E assim, fazer um plano de trabalho para as próximas 24 horas.

Scrum = Transparência + Inspeção + Adaptação!

Se o seu Scrum Team não está se adaptando, talvez não faça sentido fazer todos os eventos na cadência descrita pelo Scrum Guide. Além de ser muito provável que ele não esteja rodando Scrum e muito menos sendo ágil.

Não desperdice as oportunidades de inspeção e adaptação previstas no Scrum, pois isso ajudará seu time a entregar produtos melhores.

Um abraço e Scrum On!

Os estágios de Tuckman no desenvolvimento de equipes

Quantas vezes você já trocou de empresa, de departamento ou projeto? Tem gente nova em sua equipe? Como você lida com a situação de mudança? E aquele sentimento de pisar em cascas de ovos que temos quando começamos uma nova equipe? Você está envolvido com a causa? Existe o laço de confiança?

Bruce Wayne Tuckman (não, ele não é o Batman!), realizou pesquisas sobre a teoria da dinâmica em pequenos grupos de pessoas. Em 1965, (sim, eu escrevi mil novecentos e sessenta e cinco) publicou uma de suas teorias chamadas “estágios de Tuckman no desenvolvimento de grupo”, formada pelas fases Forming, Storming, Norming, Performing e Adjourning.

Segundo Tuckman, as equipes passam por essas etapas para que possam trabalhar bem juntas. Os estágios não são estritamente lineares, algumas equipes simplesmente ignoram um estágio e outras oscilam entre essas etapas.

Vamos lá, o que seria cada uma dessas etapas?

1. Forming

Esse é o primeiro estágio a qual a equipe se reúne. Todo mundo está em seu melhor comportamento e principalmente focado em si mesmo, tentando descobrir o objetivo da equipe, papel e responsabilidade. Para contextualizar, sabe aquela foto de bom moço no primeiro almoço na casa dos pais da namorada? O que falar e o que não falar? Postura e comportamento? Esse é o momento em que todos ainda estão observando e se conhecendo.

2. Storming

Estilos de trabalho e confronto de personalidades podem predominar nesta fase e somente 50% das equipes entram nesta etapa, enquanto os outros vão direto para Norming. Neste ponto, os membros da equipe desenvolveram confiança inicial suficiente e agora estão confortáveis ​em expor seus pontos de vista sobre o que gosta ou não gosta sobre as opiniões de outros membros da equipe, porém não ao ponto de expressar a opinião livremente.

Storming não é necessariamente algo ruim, pois desacordos ou conflitos dentro da equipe podem tornar as pessoas mais fortes, mais versáteis e capazes de trabalhar de forma mais eficaz como uma equipe.

Nesta fase é muito importante a cautela para que mudanças de pessoas ou metas não sejam realizadas, pois podem impactar negativamente na consolidação da equipe.

3. Norming

Os membros da equipe resolvem suas diferenças e crescem para respeitar e apreciar uns aos outros aprendendo a tolerar certos caprichos. Este é o momento em que você e os membros de sua equipe se adaptaram um ao outro e você é mais tolerante com suas diferenças ou aprendeu a gerenciá-las melhor.

Podem pedir ajuda, dar feedback construtivo e juntos compartilham um objetivo comum e assumem a responsabilidade. Neste momento, a equipe começa a oferecer mais a favor do objetivo proposto.

4. Performing

A equipe está executando as atividades em sua plenitude e é incrivelmente produtiva. É como se os planetas estivessem se alinhado e grandes coisas acontecem. Finalmente!

As equipes que são bem sucedidas em alcançar esta fase podem funcionar como uma unidade, pois podem encontrar maneiras de fazer o trabalho de forma suave e eficaz, sem conflitos inadequados ou a necessidade de supervisão externa.

A cautela nesta fase é para a estagnação (não é um estágio oficial de Tuckman), mas uma equipe pode atingir este estágio quando permanecem juntos por muito tempo, bem como podem reverter para estágios anteriores em determinadas circunstâncias. Por exemplo, uma mudança de pessoa pode fazer com que a equipe retorne a outro estágio enquanto as novas pessoas desafiam as normas e dinâmicas existentes da equipe.

5. Adjouring

Aqui os sentimentos de realização e perda se cruzam. Os membros da equipe fizeram as entregas e sabem que estão seguindo caminhos separados, pois o projeto está quase concluído ou a organização está mudando. Para evitar qualquer sofrimento, é muito importante um plano de continuidade em outra equipe ou produto para que seja possível gerenciar e controlar as expectativas das pessoas.

Em linhas gerais

Agora que sabemos o que é cada fase, segue abaixo um resumo para que possamos identificar as principais questões em torno da Teoria de Tuckman:

CONCLUSÃO

Por que eu devo saber sobre os estágios Tuckman na formação de equipes?

Porque lidamos com pessoas para desenvolver produtos ou prestar serviços. Parece óbvio, mas as pessoas não são objetos e precisamos identificar lacunas e oportunidades de melhoria em torno de todo o ambiente continuamente. Além disto, saber o momento em que cada pessoa se encontra durante a formação de equipe é muito importante para chegarmos a coesão e, consequentemente, alta performance.

Para muitas organizações, uma prática comum é que as pessoas sejam gerenciadas como máquinas. Comando e controle predominando minuciosamente em sua essência. Neste estilo de gestão, chefes assumem que melhoramentos do todo requer monitorar, reparar e trocar as partes, quando na verdade deveriam trabalhar como líderes servidores para manter as pessoas ativas, criativas, motivadas e engajadas.

Segundo o comandante Amaro Rolim (Setembro,1942 – Julho 2001), pessoas são as matérias primas mais valiosas e importantes numa empresa, portanto temos que lapidá-las e saber identificar cada fase para atuarmos rapidamente, seja com treinamento ou através do exemplo.

Ficou interessado em ler a teoria do Tuckman na íntegra?

É fácil, basta acessar o site da Associação Americana de Psicologia e comprar através do link psycnet.apa.org/journals/bul/63/6/384

Gostou? Não esqueça de curtir e compartilhar 😉

Até a próxima!

Definir as prioridades na vida pessoal ou profissional muitas vezes não é tarefa fácil, pois normalmente as variáveis como tempo e dinheiro são “dimmers” que devemos ajustar de acordo com a sua disponibilidade, raramente encontrada em fartura em tempos de globalização e alta competitividade.

Nos anos 90” aprendi arduamente com um amigo engenheiro que tempo, qualidade, custo e escopo são variáveis cruciais para a tomada de decisão e muitas vezes a corporação entendia que poderia resolver apenas com aportes no projeto. Se o tempo fosse o inimigo, investia-se em escalar times para tentar viabilizar a antecipação de uma entrega, o que pode trazer grandes riscos de comunicação e sincronização entre os times, mas essa é uma outra questão que poderei abordar em outro post.

Diante de muitos fatores que podem impactar positivamente ou negativamente no desenvolvimento de um produto digital, quero citar algumas técnicas que podemos utilizar para nos auxiliar no processo de tomada de decisão que muitas vezes é um desafio para o Product Owner,  que deve equilibrar as necessidades das partes interessadas, bem como buscar o melhor retorno para o produto.

MATRIZ DE PRIORIDADES

A Matriz de Prioridades é um exemplo que podemos utilizar para relacionar algumas possíveis funcionalidades a serem implementadas para um aplicativo mobile:


FUNCIONALIDADE

Tendo em mente o contexto de classificação do maior para menor, partindo de Épico > Histórias > Tarefas e Sub-tarefas, liste nesta coluna todos os itens que estão mapeados em seu backlog e que você deseja que estejam disponíveis em seus próximos releases. É muito importante que as funcionalidades sejam compostas da real motivação para que seja realizada para que possamos identificar o “custo x benefício”.

ESFORÇO

Durante o Sprint Planning ou até mesmo durante o Refinement das funcionalidades, o time de desenvolvimento realiza a pontuação de cada funcionalidade. A pontuação pode seguir por exemplo o método T-Shirt (Pequeno, Médio, Grande) ou Fibonacci. Como a nossa matriz realiza cálculo simples, utilizei a sequência de Fibonacci para demonstrar o nível de esforço para cada funcionalidade. Vale lembrar que essa sequência é composta pela soma do número atual com o número anterior, ou seja 0, 1, 2, 3, 5, 8, 13, 21 e assim por diante.

Neste contexto, é uma boa prática limitar o tamanho da sequência para que seja possível identificar as lacunas no entendimento da funcionalidade que será desenvolvida pelo time, bem como compreender que se o time pontuou a funcionalidade “Como cliente vip, gostaria de “Pagar com Cartão Fidelidade” para resgatar os pontos que tenho acumulado” com 5 pontos, estão querendo dizer que o intervalo dessa pontuação pode ser entre 3 e 8 pontos, ou seja, o nível de assertividade está no intervalo e não na pontuação cravada.

Observe que quanto maior a pontuação, maior será a incerteza que o time possui em realizar a implementação da funcionalidade e neste caso o Product Owner deve atuar para fatiá-la em partes menores.

VALOR DO NEGÓCIO

Digamos que o seu background é financeiro, então digamos que uma boa forma de entendimento se um projeto é atrativo financeiramente, você poderia aplicar a formula de Taxa Interna de Retorno (TIR) acompanhado do Valor Presente Líquido (VPL), pois seriam informações que auxiliariam para a sua tomada de decisão. O campo de valor do negócio (business value) pode ser composto por TIR, VPL ou um valor que simbolize a importância daquela funcionalidade.

Neste cenário escolhi valorizar em reais aleatoriamente para simbolizar essa importância, porém muitas vezes a importância de uma determinada funcionalidade para mim é diferente para um patrocinador ou outra parte interessada. Neste caso, podemos aplicar uma dinâmica que venha a equilibrar o entendimento de valor de cada funcionalidade, o qual cada integrante do exercício recebe uma quantidade igual de moedas de igual valor e a cada rodada “investe” suas moedas em cada funcionalidade. Ao término das moedas, as funcionalidades são classificadas do maior para o menor valor.

ROI

O Return On Investiment (ROI) é a relação da quantidade de dinheiro ganho (ou perdido) em um aporte realizado. Em nosso contexto, queremos saber o resultado do valor do negócio dividido pelo esforço, desta forma poderemos ordenar do maior para o menor valor a funcionalidade mais atrativa para aquele momento. Observando a tabela podemos identificar que as funcionalidades mais prioritárias seriam na ordem (ID) de 3,4,2,1.

CONCLUSÃO

O uso de ferramentas simples podem ser úteis para alcançar consenso e propriedade coletiva. Simplicidade pode ajudar um grupo diversificado a permanecer focado no trabalho a ser realizado e evita que todos fiquem perdidos apenas em detalhes.

Em último caso   e quando todas as funcionalidades são urgentes e devem ser feitas de imediato e você não consegue abrir mão de funcionalidade alguma – pense que você morreu e encontra-se de frente para o Capiroto com todas as funcionalidades escritas em post-it e apenas uma das funcionalidades te levaria para o céu. Qual você escolheria?

O importante é entendermos que nem tudo é prioridade máxima e você deve exercitar atividades ao decorrer do seu dia de trabalho que venham a dar cadência ao time e visibilidade do Roadmap. Lembre-se, o product backlog é dinâmico!

menu