Categorias
Sem categoria

Como montar um Product Backlog?

Recebo muitas dúvidas sobre o ágil, Scrum, Kanban e outros frameworks. No nosso dia a dia na Sunsetti, vemos muitos times com dificuldades logo no início da aplicação do Scrum e por isso, deixo aqui nossa experiencia de como montar um Backlog do produto.

  • Por onde começar a montar um product backlog? Como faço isso? Tem que ser com histórias de usuário? Tem outras formas de fazer?
  • Como priorizar? No que podemos nos basear para que isso seja feito de forma coerente?
  • Quem é responsável? Quem pode ajudar?

Fazendo um dê / para do que aprendemos com a engenharia de software (ES): dividir os sprints (na grande maioria das vezes) em duas semanas – onde, na ES fala que não tem como entregar valor percebido com prazo menor do que esse.

Respondendo a primeira pergunta “Por conde começar a montar um product backlog?” Tudo se inicia de uma visão de produto (documento onde temos praticamente um business case daquele produto que vamos trabalhar e que foi escolhido de forma estratégica pela empresa). Aqui espera-se ver para quem esse produto está destinado (público / cliente-alvo); que os mesmos estão insatisfeitos ou que tem a necessidade de…; o que será ele; diferente do que temos hoje no mercado (da própria empresa e concorrentes) e qual diferencial. Depois disso, construímos o PB com itens necessários para desenvolver o que é necessário.

Seguindo a ordens das perguntas, as próximas são “como faço isso? Tem que ser com histórias de usuário? Tem outras formas de fazer?”

Geralmente nós usamos as famosas histórias de usuários (users stories) que facilita, e muito, a vida do time Scrum, pois deixa claro para quem estamos trabalhando, qual ação necessária e o porquê. Acredite, isso ajuda muito, pois dependendo o produto que vamos trabalhar, tem usuários que podem ter x opções de acesso enquanto tem outros que não podem ter a mesma visão.

Existem outras formas de construir este artefato (documento) PB, umas delas pode ser com os próprios itens como requisitos lá da engenharia de software, como costumamos montar em projetos tradicionais. Há também várias técnicas para se chegar nesta construção, uma delas que se tornou muito conhecida é a inception, onde reúne várias ferramentas (principalmente de marketing), como mapa de empatia com a criação de personas, jornadas do cliente, features e outros. Também podemos trabalhar com roads maps e muitas outras técnicas de mercado que facilite a elaboração do mesmo.

Depois que temos o PB construído até a parte que conseguimos enxergar (sim, não precisamos criar um PB gigantesco e passar meses tentando imaginar o produto inteiro – lembre-se de um dos valores do ágil: respostas as modificações mais do que seguir um plano) temos um passo de extrema importância para a agilidade, que é:

Como priorizar? No que podemos nos basear para que isso seja feito de forma coerente?

Priorização é parte fundamental para conseguimos fugir do “cascágil” que está acontecendo muito por aí, ou seja, geralmente os times Scrum estão trabalhando com todos os eventos certinho, como está no Scrum Guide, porém, o PB está priorizado em ordem de facilidade. O que temos que fazer aqui e na minha visão é o mais desafiador é encontrar quais requisitos (histórias dos usuários ou outra técnica) são os mais valiosos ao nosso cliente. O que os nossos clientes estão esperando receber em um menor espaço de tempo. Aqui trabalhamos o famoso MVP (em português: mínimo produto viável) – o que faz sentido e o que tem valor de mercado para focarmos e desenvolvermos de forma prioritária. Isso faz toda diferença!

Agora, quem é responsável? Quem pode ajudar?

Essa é uma responsabilidade do Product Owner (PO) e quem pode auxilia-lo é o Scrum Master (SM) – também conhecido como o líder servidor / líder coach que colabora com todos no time para que o Scrum seja adotado conforme está escrito no Guia.

Vou parar por aqui, mas em outros artigos traremos mais e mais detalhes sobre esse mundo maravilhoso do ágil com frameworks que entregam com esse mindset.

Espero que tenha gostado de ficar até aqui comigo e que realmente isso faça sentido para você e sua equipe.

Grande abraço e até mais!

Adriane Colossetti – Família Sunsetti

Categorias
Sem categoria

Você sabe ouvir?

Você sabe ouvir?

Como já comentei, para que possamos nos comunicar de forma eficiente e eficaz, uma dica importantíssima é aprender ouvir e começo esse artigo com algumas perguntas a respeito:

  • Você sabe ouvir?
  • Entende o que os outros falam?
  • Quando os outros falam, você fica pensando nos problemas que precisa resolver?

Muitos ouvem o que querem ouvir e não o que realmente o outro está falando, além desse mal habito, muitos deixam os “filtros” internos e suas experiências interpretarem o que os outros falam. É… isso, definitivamente, não é saudável!

Então, o que podemos fazer para melhorar eficazmente sua capacidade de ouvir de verdade e sem filtros?

  • Aprenda a permitir que os outros expressem seus pensamentos sem interrompê-los;
  •  Aprenda a ouvir nas “entrelinhas”, pois nem sempre o outro diz tudo só com palavras;
  •  Concentre-se em desenvolver sua capacidade de retenção do que ouve;
  •  Não ignore seu interlocutor se você acha que aquilo que ele está dizendo não lhe interessa;
  •  Não se exalte ou se irrite se as ideias do outro forem contrárias às suas convicções;
  •  Aprenda a não prestar atenção às interferências do ambiente.

“Para nos comunicar com clareza e eficiência, devemos entender que somos todos diferentes na maneira como percebemos o mundo e usar esse entendimento como um guia para nossa comunicação com os outros.” Anthony Robbins (Poder sem limites)

Deixo aqui um teste (Dr. Joel Mapheo – Amil) para saber se você sabe ou não ouvir. Faça-o e só depois olhe a tendência da resposta.

Abraços e até a próxima.

Adriane Colossetti – Família Sunsetti