Publicado em

The Role and Outcomes of Agile Review Meetings

An agile review meeting, often referred to as a sprint review, is a key event in the agile framework that focuses on assessing the work completed during a sprint. This meeting serves as an opportunity for the team to showcase their accomplishments to stakeholders and gather valuable feedback. The primary goal is to ensure that the product increment aligns with the expectations and requirements of the stakeholders, and to make necessary adjustments for future sprints.

During the agile review meeting, the team presents the completed user stories and demonstrates the functionality of the product increment. Stakeholders, including the Product Owner, customers, and other interested parties, are invited to provide feedback and discuss the progress made. This interaction is crucial for maintaining transparency and fostering collaboration between the development team and stakeholders.

sprint review, is a key event in Agile development where the team showcases the completed work of a sprint to stakeholders and gathers feedback
Sprint review, is a key event in Agile development where the team showcases the completed work of a sprint to stakeholders and gathers feedback

Expected Outcomes of an Agile Review Meeting

  • Validation of Work: The meeting provides a platform for stakeholders to validate the work completed during the sprint, ensuring it meets their expectations and requirements.
  • Feedback Collection: Gathering feedback from stakeholders is a critical outcome, as it helps the team understand any changes or improvements needed for the product.
  • Alignment on Goals: The review meeting ensures that the team and stakeholders are aligned on the product goals and priorities, facilitating better planning for future sprints.
  • Demonstration of Progress: By showcasing the product increment, the team demonstrates tangible progress, building confidence and trust with stakeholders.
  • Identification of Improvements: The feedback and discussions during the meeting can lead to the identification of areas for improvement, helping the team refine their processes and enhance product quality.

In summary, agile review meetings are essential for validating work, collecting feedback, aligning goals, demonstrating progress, and identifying improvements. By engaging stakeholders and fostering open communication, these meetings contribute to the continuous improvement of the product and the overall success of the project.

Publicado em

Sete desperdícios do Lean.

Lean é uma metodologia que consiste em melhorar o fluxo de trabalho deixando-o mais enxuto possível de forma a diminuir possíveis desperdícios sem prejudicar a qualidade final das entregas. Podemos classificar os tipos desperdícios em 7 categorias.

  • Superprodução: Produção antes que exista uma necessidade a ser endereçada, essa situação contraria a boa prática conhecida como Just in Time (JIT) aonde cada item é produzido conforme a existência da demanda.
  • Tempo de espera: Devemos sempre prestar atenção na duração do tempo em que uma atividade fica parada no fluxo de produção/desenvolvimento e se possível diminuir este tempo ao máximo possível melhorando o cycle time.
  • Transporte: Isso pode aumentar os custos quando pensamos no manuseio de materiais entre processos de produção, o mapeamento de fluxo de valor é extremamente útil nesse cenário para a identificação de pontos de melhoria.
  • Processamento inapropriado: É necessário usar a abordagem apropriada para cada cenário de forma que não haja utilização de recursos mais caros do que o necessário, soluções simples devem ser priorizadas sempre que possível, mesmo que seja uma abordagem mais antiga mas que se mantém eficiente por exemplo.
Eliminar o desperdício é uma das maneiras mais eficientes de melhorar vários aspectos de uma operação, os sete desperdícios é uma ferramenta originalmente desenvolvida pelo Sistema Toyota de Produção.
  • Estoque desnecessário: Este é um resultado da superprodução, isso dificulta a identificação de problemas e comunicação por exemplo, alcançando a condição de manter um fluxo contínuo (otimizado) conseguimos melhorar os custos associados a produção, existem algumas estratégias Lean que podem propiciar este tipo de melhoria.
  • Movimento desnecessário: Este tema está relacionado á ergonomia, trabalhos com movimentação excessiva devem ser analisados e reprojetados através de análise considerando os atores envolvidos para a redução de desperdício no ambiente de trabalho.
  • Defeitos: Tendo um impacto direto nos resultados os defeitos de qualidade resultam em retrabalho, muitas vezes o custo total gerado pelos defeitos é uma porcentagem significativa do custo total de produção.

Muitas organizações estão adotando o Lean, para começar a atingir esse objetivo é essencial mapear o fluxo de trabalho e atacar os tipos de desperdícios citados na busca do aumento da eficiência, você pode olhar para o seu processo e identificar formas de tornar mais eficiente algum aspecto de sua operação considerando um ou mais dos sete itens citados.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Utilizando e descobrindo com Spike

Muitas vezes precisamos propor soluções com ferramentas que nem sempre temos dominio, para diminuir o risco de se assumir uma demanda sem que se tenha o minimo necessário para que o mesma possa ser colocada em andamento criamos itens no backlog com o objetivo de adquirir conhecimento de forma a esclarecer os aspectos que não conhecemos.

SPIKE é um tipo de história de usuário para ganhar o conhecimento necessário para execução de uma nova demanda.

Atualmente está convencionado chamar essa atividade de Spike, a adoção deste tipo de expediente reduz o risco de uma abordagem técnica inadequada seja implementada, aumentando a confiabilidade do time sobre o tema trazendo mais segurança para que se possa decidir como o item será operacionalizado evitando retrabalho.

Existem vários formatos que podemos considerar, um estudo, experimento ou mesmo uma prova de conceito, o objetivo é obter informações considerando o contexto do problema para tomada de decisão.

Esta abordagem é uma forma de manter o time angariando novos conhecimentos sempre com o foco para tomar as melhores decisões sem impactar entregas planejadas na sprint conforme a necessidade corrente estabelecida.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

A importância do Product Owner no time.

O papel do Product Owner é vital em um time ágil, ele define o direcionamento tomando decisões que determinam a estratégia do produto em questão, isso colabora diretamente para manter o time na direção certa.

Neste papel algumas das principais características/habilidades devem ser observadas:

  • Tomador de decisões
  • Definidor da visão
  • Detemina o valor de negócio
  • Responsável pelo produto

É importante que o PO dê visão ao time fazendo-o entender dentro do possível o negócio ou seja os motivos do porque uma demanda foi criada, isso aumentará o compromisso do time elevando o desempenho já que o time também terá a mentalidade voltada para o negócio. Com esses “ingredientes” o time tenderá a ser mais resiliente em relação a pressões externas além de facilitar a adaptação entre os sprints.

O direcionamento do PO é decisivo para o sucesso do time, existem uma série de aspectos que precisam ser dominados pela pessoa que exerce este papel, isto influência diretamente na organização, funcionamento e resultados gerados.

É muito importante que o PO evite os “anti-patterns”, ações que ele deve resistir em fazer:

  • Dizer “como” o trabalho será realizado e não o “que”
  • Focar apenas nas entregas a curto prazo
  • Não ter olhar para adaptabilidade do escopo
  • Demandar mudanças antes de se tornarem reais
  • Ter como regra mudanças durante a sprint

A saúde do time e do produto dependem do comprometimento do PO, ele precisa estar autorizado a tomar decisões, ser colaborativo e capacitado para discernir entre os trade-offs que surgem no caminho do time.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Você sabe a diferença entre Wireframe, Mockup e Protótipo ?!

Um recurso muito utilizado nos dias de hoje e que pode evitar muita dor de cabeça e desperdício de dinheiro é a utilização de Wireframe, Mockup e Protótipos, antes de começar a codificar, isso alinha o entendimento das partes envolvidas, evita retrabalho e dependendo da necessidade do projeto você pode usar um deles ou os três em conjunto, cada um com características específicas, veja a seguir.

É muito comum antes de começarmos um desenvolvimento que exista a necessidade de confirmação de como serão as telas que serão criadas, desenha-las logo de cara exatamente como serão pode ser um desperdício de tempo, neste caso o rápido é mais devagar e o devagar é mais rápido.

Wireframes mostram apenas um ideia geral de como deverá ser o que está sendo projetado, são muito simples e tem um custo baixo, tem baixa fidelidade e neste ponto ainda não estamos pensando como será viabilizado tecnicamente, neste ponto queremos fechar a estrutura e layout básicos.

Mockups são imagens estáticas de como a versão final do produto irá se parecer, é importante no apoio da definição de coisas como tipografia, estilo, representação visual, cores e etc. É um design representando o que foi desenhado na forma de wireframe (que é o passo anterior) porém com uma fidelidade maior especificando mais detalhes, esse tipo de artefato tipicamente é produzido por designers.

Protótipos nos permitem explorar a interface do usuário procurando possíveis problemas no fluxo além de deixar mais clarificado (já que é possível interagir) o que deve ser feito facilitando também melhorias no que foi planejado até então. Esse artefato é fundamental para realização de pesquisa de usabilidade, também fica mais fácil pra vender caso precise convencer alguém que o que está fazendo é uma boa ideia.

Cada artefato tem o seu papel e valor no passo em que o design da aplicação está, são interrelacionados e vão aumentando a fidelidade conforme o avanço no processo, para resumir:

  • Wireframe trata a estrutura; (Baixa fidelidade)
  • Mockup a parte visual; (Média fidelidade)
  • Protótipos são para interação e usabilidade; (Alta fidelidade)

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Facilite a Planning !!!

A planning é a primeira cerimônia de uma sprint, para que ela alcance seus objetivos com sucesso algumas ações precisam ocorrer antes desta reunião, são atividades que envolvem todo o time.

É necessário garantir que o Product Owner esteja com itens do backlog preparados de forma que todo o time possa entender o valor de negócio e o porque foram priorizados, para tanto o time precisa ter conhecimento desses itens do backlog em um momento anterior a planning, pode ser feito na reunião de refinamento.

Na reunião de refinamento, o Product Owner explica os itens que estão sendo preparados em busca da colaboração do próprio time para essa tarefa, o time de desenvolvimento deve contribuir durante o entendimento dos itens que estão sendo explicados pelo Product Owner.

A Planning é um dos eventos mais importantes do Scrum, antes desta reunião deve haver uma preparação que compreende algumas atividades que devem ser executadas pelo próprio time e que impactam diretamente a consistência e a dinâmica da reunião.

O time deve estimar o esforço determinando quais seriam as principais tarefas a serem executadas em cada item. Aproveite para observar as oportunidades de aprendizado que irão surgir, faça perguntas para ajudar a clarificar o entendimento do está sendo tratado, questione sobre o entendimento do valor agregado de cada história e qual o benefício para o usuário final.

Lembre-se dos limites entre os papéis, o Product Owner determina o que deve ser feito e o time de desenvolvimento define o como será feito, apesar da colaboração entre todo o time que deve ser incentivada, não podemos esquecer quem é responsável pelo quê, ajude-os a se organizar.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Treine o Product Owner.

Quando precisamos começar a trabalhar com ágil com equipes que não tem experiência com o assunto temos várias iniciativas que precisam ser colocadas em andamento para suportar esse objetivo, um deles é treinar as pessoas que foram indicadas para se tornarem Product Owners.

É necessário levar em consideração o background da pessoa pois isso influência diretamente como o treinamento será estruturado ao longo do caminho, o treinamento deve ajudar essas pessoas a fazer a transição para o novo papel.

Devemos orientá-los para que possam começar a direcionar o valor de negócio sendo responsável pela visão do produto tomando decisões diárias protegendo o produto de investidas externas que não estão de acordo com os objetivos estabelecidos.

Ser um bom Product Owner vai além de preparar o backlog, trabalhar em equipe e suportar a visão do produto de forma convincente, outras habilidades são necessárias e precisam ser desenvolvidas por quem desempenha o papel durante a jornada.

Devemos abordar os aspectos mais importantes que possam colaborar com a capacidade do time de entregar e melhorar assim como os aspectos que podem afetar essas questões de forma negativa e como mitigar os impactos, isso varia de um lugar para o outro.

O treinamento a ser ministrado deve levar em consideração a maturidade não só da pessoa em questão mas do ambiente em que está inserido assim como experiência e expertise nos negócios e na metodologia ágil, considere que o treinamento acontece durante a jornada e não apenas dentro de uma sala.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Já ouviu falar em 5W2H !?

Uma das missões do Product Owner é obter e traduzir para o time de desenvolvimento as necessidades da área de negócio e/ou os clientes a serem atendidos pelo seu produto, existem várias formas, você já ouvir falar de 5W2H !?

É um acrônimo em inglês que representam as perguntas que podem ser respondidas em um levantamento de informações/requisitos, é uma ferramenta que pode ser utilizada em qualquer área profissional, é bem conhecida em gerenciamento de produtos.

  • Who ? (Quem ?)
  • What ? (O quê ?)
  • Where ? (Aonde ?)
  • When ? (Quando ?)
  • Why ? (Por que ?)
  • How ? (Como ?)
  • How Much ? (Quanto ?)

Uma ferramenta que pode ser utilizada em qualquer área profissional, é bem conhecida em gerenciamento de produtos.

É um recurso muito interessante quando falamos em levantamento de requisitos, vários aspectos de uma questão podem ser capturados com a utilização deste expediente.

São perguntas abertas que exigem respostas mais elaboradas e geram uma oportunidade para se obter informações preciosas, muito se fala sobre os usuários não saberem o que querem, mas eles não podem esconder suas necessidades com esse tipo de abordagem, seja gentil.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Já ouviu falar de “Planning Onion” !?

Planning onion representa os níveis de planejamento que podemos considerar durante a execução do projeto para nos organizar conforme o nível de detalhamento de cada fase, veja a seguir uma sugestão dos níveis que geram informações que dão sustentação ao nível subsequente.

Cada camada tem ações executadas seguindo seu nível de detalhamento, as ações de cada nível ocorrem em paralelo, conforme vamos seguindo o nível de planejamento fica mais específico.


O planejamento em vários níveis ou planning onion tem o conceito da realização de planejamento que retroalimenta todos os níveis conforme o projeto evolui e as ações vão acontencendo.
  • Visão do produto: são as razões do produto existir e que devem nortear todas as ações do projeto, fornece informações para o Roadmap do produto;
  • Roadmap do produto: coordena o desenvolvimento do produto estabelecendo as datas, fornece direcionamento para determinar as Releases;
  • Planejamento de Releases: determina quando o resultado de um conjunto de sprints e quais assuntos serão publicados considerando o Roadmap do produto, fornece informações para o detalhamento das Sprints.
  • Planejamento das Sprints: revela as tarefas de desenvolvimento referente a um determinado grupo de histórias que endereçarão parte do planejamento da release que está em desenvolvimento.
  • Planejamento Diário: Mostra o status do trabalho e identifica as tarefas remanecentes para que o objetivo da Sprint seja alcançada.

O planejamento em vários níveis ou planning onion tem o conceito da realização de planejamento que retroalimenta todos os níveis conforme o projeto evolui e as ações vão acontencendo.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Definição de Preparado, use com bom senso !!!

A definição de preparado (Definition of Ready) é um acordo entre o product owner e o time de desenvolvimento que serve para orientar quando uma história está pronta para ser executada em uma Sprint.

A boa prática orienta que o Product Owner tenha um “estoque” de histórias preparadas equivalente a 3 sprints conforme a velocidade medida historicamente do time, assim quando houver algum imprevisto que evite a elaboração e o refinamento de novas histórias, não se corre o risco do time ficar parado.

Entretanto precisamos tratar com cuidado esse tema, pois o que se vê em algumas situações é o time utilizar a definição de pronto como escudo, afirmando que algo não pode ser iniciado devido a falta de alguma condição determinada na DoR, isso afeta a colaboração entre o time de desenvolvimento e o product owner.

O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva, não deixe que .
O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva.

É necessário que se use o bom senso, uma definição de preparado pode ser estabelecida como um contrato e servir como uma referência. Porém não quer dizer que se alguma demanda não alcançar todas as características determinadas nesta lista, não se deva trabalhar na demanda.

Se o time tiver o entendimento sobre o que precisa ser feito com as informações disponíveis para execução, devemos seguir. Aproveite os benefícios da utilização da definição de preparado (DoR), mas não deixe que isso se torne uma parede entre o time e o PO.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!!