Hi,

Today’s post is adapted from the original "Five Things a Product Owner Needs to Know", available on this link.

For many times the importance of the Product Owner (PO) may be overlooked in relation to other actions os Scrum project. If it happens, it is certain that the project will not have the expected success. So, this role is as important as the others and requires a professional able to perform it.

The text of this post is directed to the PO and brings five tips to contribute to the successful performance of its role in Scrum projects. Let’s get right to these tips!

1. Trust is key

The PO has the knowledge of business rules of backlog items. However, since the PO has no development experience, maybe here are backlog items with technical knowledge difficult to understand. The tip here is to have the support of development team to explain the technical details of such stories, so that the PO can prioritize them correctly.

Also, if development team (from here I will only call "team") suggest changes, probably they will bring benefits that can accelerate development, make the code more reliable, and increase product performance. In other words, listen to the feedback of your team, as it can be a valuable complement to the product.

2. PO’s job is to serve the team

The ultimate goal of development is to launch, in time, an excellent product. The PO should try to be available as soon as possible and answer question from team.

If the team is working with Sprint of 2 weeks (10 working days), imagine if there is an impediment to paralyze the work for 1 day, it means that 10% of available work time was thrown away.

3. User insights are essential

It is essential PO understand the people who will use the product. The better understanding of end user, better will be direction of the product, its features and business rules. Nothing is more important than spending time understanding the end user.

Although it seems difficult, the goal is to achieve the best balance between what you know the product needs and what is value to users.

4. The team often fails

Even the team is very productive in a Sprint, it does not necessarily mean that the next will also be a success. The ups and downs of the development process are normal, unpredictable and can occur due to various internal and external factors.

The truth is that success or failure of Sprint is not as important as the team capacity to deliver value. Thus, there is no reason to despair if one or two backlog items are not approved at end of Sprint.

Scrum teams are always trying to improve at every Sprint. The PO should trust the team and know that, eventually, failures may occur because team decided to test new techniques, or defined a very ambitious goal.

5. PO is not project manager

This tip is for PO not try to embrace the world with their arms. This is impossible!

The PO does not need and should not worry about team schedule, how they allocate their work, or how they plan Sprints. PO job is only to set priorities and provide valuable feedback to team.

Only developers fully understand details of their work. If the PO tries to control aspects of development past these levels, then the project may be fated to frustration and unhappiness.

To let the team be self-organizing and rely on their way to work will save time and make life and work easier for everyone.

Did you like the tips? Disagree? Got any more tip to add? You are invited to comment and share your thoughts and ideas with us.

Till next post!

The post What Product Owner needs to know appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

1 – The meeting is very time consuming and lasts much longer than planned.

After all, it is not anyone who manages to remain 100% focused on a very long meeting. When participants lose focus (or interest) in what is being presented, the review meeting loses its purpose.

2 – The team leaves the review meeting demotivated.

There are times when the P.O. feels the need to "shake" the team a little bit. This is normal, but sometimes these are so frequent or intense that make the team feel demotivated or discouraged. The P.O. needs to be careful here to direct the criticism to the problems and not the people.

3 – Discussions at the review meeting are not productive.

It is extremely easy to make a meeting misdirect with unproductive discussions. For some people, the temptation to just take the time to address an issue on some business rule controversy when a certain story of the same topic is being presented is too overwhelming. The Scrum Master should remind everyone that the purpose of the review meeting is the inspection of what was done and not inquiries on requirements.

4 – The team leaves the meeting without the understanding of why the stories have been reproved.

The P.O. should be able to explain to the team why a story was rejected and the team should be concerned about what will be needed to correct it. Without this understanding, the necessary corrections will not be possible, and the story can be rejected again.

5 – People in the meeting pointing out whose fault is that the story have been reproved.

A failed story is not the fault of a specific individual, but the team as a whole. The purpose of the review meeting is not to point out who is guilty of what. This kind of discussion should happen in the retrospective meeting, if appropriate.

6 – People are not aware of what is happening in the sprint.

If any team member arrives at the sprint review meeting without knowing that a story wasn't finished, why a decision has been taken, or other significant events that occurred, this person will not be able to actively participate in what is being presented, nor will pose relevant questions and will thus not benefit from the discussions.

The post 6 signs to show that your review meeting is inefficient appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Olá Pessoal, essa semana irei falar sobre priorização do Product Backlog, irei passar algumas dicas que podem ser bastante úteis na priorização do mesmo.

Como todos sabem, o Product Backlog é o artefato do Scrum que representa o que deve ser desenvolvido no projeto, ou seja, ele possui todo o trabalho a ser realizado. Por outro lado, como também sabemos, em um projeto Scrum, a mudança no rumo é esperada, logo, o conjunto inicial de funcionalidades para atender ao produto pode ir variando de prioridade conforme o tempo passa, e, com isso, manter o Product Backlog priorizado e atualizado é de suma importância para o sucesso do projeto. Nesse post irei listar 10 dicas para auxiliar à priorização do Product Backlog. 

1. Mantenha o Product Backlog atualizado

Histórias que não estejam mais alinhadas à visão do produto devem ser descartadas do Product Backlog. Quanto menor for o conjunto de histórias que devem ser priorizadas, mais simples será a tarefa. Por mais que seja dificil "desapegar" de uma história pensada e, até certo ponto, especificada, é importante que isso seja feito, pois ela estando no Product Backlog, mesmo que com uma prioridade baixa, pode influenciar na priorização das demais histórias e alterar o rumo do produto.

2. Dê importância a DoR (Definition of Ready – Definição de Preparado)

A definição de história preparada é outro fator que pode auxiliar bastante na priorização do Product Backlog. Sem ela, a equipe de desenvolvimento pode não saber estimar corretamente uma história, passando uma falsa noção de tamanho da história para o PO, que irá tomar decisões sobre priorização com base em uma informação pouco confiável.

3. Qual o conhecimento, incerteza e risco sobre uma história?

Como esses fatores influenciam diretamente o sucesso do produto, histórias com baixo grau de conhecimento e alto grau de incerteza e risco devem ter uma prioridade alta, pois quanto antes forem desenvolvidas, antes pode-se perceber o melhor caminho a se seguir, caso contrário pode não haver o tempo necessário para desenvolver a história e colher os frutos do apredizado do desenvolvimento da mesma.

4. Qual a influência da história na próxima release?

Histórias que permitam um lançamento mais rápido do produto tambem devem estar no topo do Product Backlog. Por exemplo, em um software de geração de nota fiscal, a geração da nota em si é muito mais importante que o cadastro dos produtos, logo, ela deve possuir uma maior prioridade.

5. Atenção ao tamanho das histórias

Lembre-se, a história deve ser pequena suficiente (s de small do INVEST) para ser independente e agregar valor para o software e para o cliente, dessa forma, busque uma uniformidade no tamanho das histórias, de modo que o Product Backlog, principalmente em seu topo, possua apenas histórias na menor unidade possível, e, a medida que avançamos no Product Backlog, podemos encontrar histórias maiores. Assim, evitamos que a equipe estime histórias muito grandes, que possuem maior risco de apresentar surpresas em seu desenvolvimento e que possuem estimativas mais suscetíveis a erros.

6. Atenção à dependência entre as histórias

Apesar da definição de que as histórias devem ser independentes (i de independent do INVEST), muitas vezes não conseguimos evitar a dependência entre as histórias. Nesse caso a melhor opção é deixar visivel essa dependência, com uma anotação, uma cor diferente, qualquer coisa que chame a atenção para isso. Se a história A depende da história B, não agrega valor para o negócio fazer a A antes da B e isso deve estar visível para todos os envolvidos no Projeto.

7. Ouça todos os interessados no Projeto

A decisão sobre a prioridade do Product Backlog é única e exclusiva do Product Owner, entretanto, ele deve ouvir todos os interessados (stakeholders) no Projeto para auxiliar o seu processo de tomada de decisão. Isso é importante pois o produto sendo desenvolvido não deve agradar somente ao PO, mas sim à todos os envolvidos no Projeto, principalmente interessados e clientes.

8. Utilize Técnicas de Priorização

Novamente, apesar da decisão sobre a prioridade do Product Backlog ser única e exclusiva do Product Owner, a utilização de técnicas, como a técnica de KANO pode ser bastante útil quando existe dúvida na prioridade de um pequeno conjunto de histórias. Uitlize as técnicas de priorização como sua aliada para ajudar a resolver esses pequenos conflitos.

9. Considere a priorização por temas

Como falei na dica #6, a dependência entre histórias muitas vezes é inevitável. Dessa forma, agrupar as histórias dependentes em um tema e priorizar o tema também pode ajudá-lo, assim a priorização pode ser dividida em 2 passos, primeiro se prioriza os temas e, em sequência, as históias dentro de cada tema, evitando assim que histórias de um mesmo tema fiquem espalhadas por todo o Product Backlog.

10. Se mantenha atualizado!!!

Como sempre, nunca pare de estudar e se atualizar. A cada dia novas técnicas aparecem, e, estarmos de cabeça aberta para absorver novos conhecimentos é sempre importante para nos ajudar a melhorar nosso trabalho.

Gostaram das dicas? Deixe seu comentário e vamos continuar discutindo sobre priorização, até a próxima!!!

The post (Português) 10 dicas para melhorar a priorização do Product Backlog appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post A Vida de um Product Owner appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Inicialmente, deve-se atentar ao período em que o PO estará ausente. Se ele estiver ausente apenas durante o andamento da sprint, caso exista a necessidade de se consultar o PO, a mesma pode ser realizada por e-mail, a menos que o PO não possua acesso a internet em sua viagem. Nesse caso, a equipe tem de ter uma maior atenção no planejamento da sprint para tentar antecipar todas as possíveis dúvidas durante o desenvolvimento da mesma. Essa ausência é a que possui um menor impacto na sprint, mas ainda sim, pode impactar o desenvolvimento, visto que dúvidas podem surgir durante a sprint e serão solucionadas apenas perto do seu final.

Entretanto, se o PO estiver ausente no período entre sprints, i.e., durante a reunião de revisão e planejamento 1, o que fazer de forma a impactar o mínimo possível a sprint?

1. Adiar o fim da sprint?

2. Realizar a revisão remotamente?

No nosso caso, nem discutimos sobre a primeira opção, visto que a mesma irá atrapalhar o cálculo da velocidade média da equipe, logo, decidimos pelo caminho da segunda opção. Nesse caso, as reuniões podem ser realizadas de várias formas diferentes. Para a reunião de revisão, onde a equipe deve apresentar ao PO o trabalho realizado ao longo da sprint, discutimos sobre 4 opções:

1. Uso de uma ferramenta de videoconferência.
2. Gravação de um vídeo que represente a apresentação da equipe de seu trabalho realizado durante a sprint.
3. Envio do roteiro da apresentação da equipe para o PO e um link para a aplicação que será apresentada, de forma que o PO realize a revisão.
4. Apresentação para o PO através de chat.

Como nosso PO estava acessível à equipe via Internet, escolhemos a opção 1 como o plano A e, caso acontecesse algum problema, a opção 3 seria utilizada como plano B. Vale notar que é muito importante a escolha de um plano A e um plano B, pois como dependemos de uma infraestrutura, problemas podem ocorrer e a reunião tem que continuar. Ainda, sobre reunião de revisão, a utilização do ScrumHalf para o gerenciamento de nossos projetos foi importante, pois o PO poderia aprovar ou reprovar histórias de onde estivesse.

Após a reunião de revisão, a próxima reunião a ser realizada com o PO é a reunião de planejamento 1. Novamente escolhemos como plano A a utilização de uma ferramenta de videoconferência e, como plano B, iríamos utilizar o chat para conversarmos. Infelizmente nessa reunião tivemos problemas com a conexão à Internet e foi preciso utilizar o plano B. Novamente, a utilização do ScrumHalf foi fundamental para o sucesso da reunião, pois o PO priorizava as histórias na ferramenta e, via chat, discutia com equipe sobre dúvidas de ambos os lados.

Resumindo, é possível sim o PO sair de férias, entretanto, a equipe deve se planejar para tal a fim de impactar o mínimo possível no andamento das sprints. E você já passou por essa situação? Qual a sua experiência?

The post O PO viajou, o que fazer? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.