Histórias refinadas??

Olá,

O conceito de refinado varia bastante, mas neste caso você pode tomar algumas premissas, como se ela não é dependente de outra história, se nesta história tem uma complexidade alta, você pode pegar como base outras histórias se elas se parecem com ela e que foi definida como pronto.

O PO quem define as histórias, em relação se está refinada ou não, o melhor seria o scrum master se reunir antes da plannning com o P.O. para dar uma repassada nas histórias que se pretende ir para planning. O Scrum Master tem uma visão geral sobre as histórias e pode influenciar o P.O. na priorização do backlog, assim como dividir uma história.

Na Planning a também pode ocorrer a divisão de uma história em duas ou mais. O próprio time também pode sugerir a divisão da história visto o esforço para conclusão dela, lógico que isto depende do sentido final depois da divisão, se é possível ou não serem histórias independentes.

Quando aplicamos agilidade, sempre pensamos em times unidos, ou seja, apesar de ter uma "divisão" de papéis como P.O., Scrum master, time de desenvolvimento, todos trabalham juntos.

Bom dia Danilo!

A seleção das histórias que entrarão na próxima sprint é feita na revisão da sprint, correto? Entretanto, quando se realiza a planning, discuti-se as histórias e as mesmas podem, ainda, serem quebradas em histórias menores e no caso serem, até, retiradas daquela sprint, estou correto no meu pensamento?

Obrigado, Gillian Lopes

Bom dia Gillian,

Na etapa de revisão, não escolhemos as histórias que entrarão na sprint, a review é algo mais curto, ela é somente para revisar e apresentar o que foi desenvolvido durante a sprint para o P.O. e outros possíveis stackholders. Nesta reunião de review que é feito a aprovação dos itens feitos durante a review , caso um item não esteja de acordo ela retornará para o backlog para ser incluido na proximo sprint com as correções a serem feitas.

Literalmente é uma reunião para revisar e apresentar o que foi feito. Na reunião de planejamento é que se decide mesmo o que vai ser realizado, tanto que é uma reunião mais longa, dependendo do tamanho da sprint.

Por exemplo para uma sprint de duas semanas a planning pode durar até 4 horas. Não tem problema se durar menos o importante é manter a equipe focada para que não ultrapasse as 4 horas, se a sprint durar um mês, consequentemente teremos 8 horas de timebox limite para a planning,

A review tem que ter a metade desse tempo, então no caso de uma sprint de duas semanas a review deve durar 2 horas no máximo.

Boa tarde Danilo!

No guia tem as seguintes pontuações na Revisão de história:

• O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta os prováveis alvos e datas de entrega baseado no progresso até a data (se necessário);
• O grupo todo colabora sobre o que fazer a seguir, e é assim que a Revisão da Sprint fornece valiosas entradas para o Planejamento da Sprint subsequente;

Havia entendido que isso seria exatamente o momento da escolha do que seria implementado na próxima sprint. Não seria isso?

Mas no planejamento da sprint também tem o seguinte trecho:

"A entrada desta reunião é o Backlog do Produto, o mais recente incremento do produto, a capacidade projetada do Time de Desenvolvimento durante a Sprint e o desempenho passado do Time de Desenvolvimento. O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do Time de Desenvolvimento. Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint."

Bem, achei um pouco confuso. Poderia, por favor, esclarecer?

Obrigado, Gillian Lopes

Olá Gillian,

Esses itens constam no manual, porque o próprio backlog pode mudar, pois um item desenvolvido naquela sprint pode ser que não tenho conseguido ficar pronto ou não estava de acordo com o que o P.O. esperava. Este item pode voltar pro backlog do produto como prioritário para ser feito na próxima sprint, quando um item volta consequentemente o backlog é alterado.

Outra coisa que se pode influenciar para discutir o backlog, é que na revisão foi entregue um item que seria um pré-requisito para outros itens no backlog, Com isso a própria equipe e o P.O podem ter uma visão do que pode ser adicionado na próxima sprint. A revisão é algo mais informal então não é decidido nela o que vai ser feito, mas pode-se chegar a debater o backlog.

Outro exemplo onde o backlog pode ser debatido, que seria a integração com algum serviço, havia-se o impedimento para criação das credenciais para o consumo desses serviços, não há problema em dizer na review que já foi gerado essas credenciais para o P.O. pense em repriorizar o backlog.

Em relação ao segundo trecho:

O P.O. ordena o backlog com as coisas prioritárias, mas o time que fala quantas HUs podem ser feitas durante a sprint, existem H.U. tem maior complexidade que outras, então dessa forma não é ele quem fala quantas e quais devem ser feitas, a equipe decide de acordo com a priorização, não necessariamente sempre tem que seguir a ordem do backlog, se tivermos 3 historias bastante complexas no final e logo em seguida uma mais simples, podemos negociar de executar 2 e a outra mais simples, sendo que as 3 não seria possível executar.

Enfim, o Scrum em si sempre é combinado com outras técnicas agéis, tente focar no principal como as timebox, e o principal objetivo de cada evento da sprint.

Espero ter esclarecido melhor.

Oi Gillian, tudo bem?

Sua dúvida foi esclarecida?

Lembre-se de marcá-la como solução, caso contrário, mande por aqui para tentarmos te ajudar.

Bons estudos.