Itens de backlog da sprint que não podem ser quebradas em partes menores

Tem um exemplo do que chama de backlog que não pode ser dividido? Uma forma de divisão em dois backlogs seria na primeira sprint fazer algo mais simples e menor mas que atenda a necessidade e tenha algum valor e na outra faz algumas melhorias nas funcionalidades.

Outro ponto é que você falou em itenS grandes, estou entendendo que tem mais de 1. Se for isso, mesmo você precisará ver o que é prioridade. Se a produtividade do seu time não suporta fazer dois itens grandes no tamanho da sua sprint, você precisará fazer um item em uma sprint e outro na segunda.

Sprint de 2 semanas é um exemplo. O Scrum prevê que a srpint tenha no máximo 4 semanas. Você pode começar com sprints maiores. A cada retrospectiva vai coletando o que está errando o que está acertando e ajustando para ganhar mais produtividade e diminuir assim o tamanho da sua sprint.

O backlog é sempre 1 por produto. Se temos um produto, temos apenas 1 backlog.

A gente pode ter uma história de usuário grande demais, tudo bem, mas nesses casos vamos chamar aquela história de épico! Se for um épico, então dá sim para quebrar em novas histórias de usuário.

Você poderia colocar aqui um exemplo de história que você julgue grande demais?

Ainda, se tiver problemas em quebrar a história, pode fazer uma boa decomposição daquela história em atividades.

Como nosso colega Juliano propôs, você pode discutir com a equipe a duração das Sprints em função da complexidade das histórias de usuário e do projeto como um todo.

Abraços,

FA

Boa tarde, pessoal.

Obrigado pelas explicações. Na realidade são itens de sprints backlogs e não de itens de backlog como mencionei. No caso de um item de sprint backlog que não é possível quebrar em itens menores, por exemplo: um algoritmo para criação de um mapa na tela que irá demandar mais que a sprint de 2 semanas. Sendo que não é possível dividir para outros devs atuarem em conjunto na sprint e não é possível também aumentar o tamanho da sprint. Já passaram por alguma situação parecida?

Teria como passar mais algum detalhe para tentar de ajudar?

É sistema web? Qual linguagem e tecnologia está usando?

Tem como especificar o que esse seu algoritmo faz? Quando diz mapa é o mesmo mapa do google maps? Se for não é possível usar o google maps?

O que é exibido é o mesmo mapa sempre? O usuário tem algum tipo de iteração?

Dentro desse backlog tem apenas atividade de codificação e teste ou tem mais alguma coisa?

No meu caso eu consegui negociar com o cliente. Fazer uma versão mais simples e depois incrementar. Foi necessário questionar para que ele precisava da funcionalidade e definir na Sprint X vai funcionar assim. Na Sprint Y vai funcionar assim. Ai desde a primeira Sprint essa funcionalidade já foi criada para ter menos impacto nas melhorias.

Teoricamente falando, sem entrar no detalhe - que o Juliano vai explorar - aquela atividade está relacionada a uma história de usuário. O que deve ocorrer, ao fim da Sprint, é a história voltar para o Backlog.

Ainda, mesmo durante a Sprint, enquanto o time estiver fazendo o grooming com o PO, reavaliar aquela história de usuário e tentar melhor estimar aquela atividade específica.

Sempre dá para compartilhar o trabalho, programar em par... Não tem jeito. Se por ventura se tornar muito complexo o trabalho, em último caso, pode-se negociar a ampliação da duração das sprints.

Abraços,

FA

O código é em C e não usa google maps. Para resolver esse problema foi decidido criar o código até certo ponto e voltar o item para o backlog para que na próxima sprint possa dar continuidade na atividade. Já era feito dessa forma, mas queria saber se existia outros meios . Agradeço as respostas. Abraços.