Quão relaxado (ou não) deve ser um sprint?

Qual deve ser a atitude em relação à realização de histórias atribuídas a um sprint? Obviamente, você deseja priorizar a realização deles no sprint, mas para mim o ponto principal do ágil é ser dinâmico: você não deseja procrastinar deliberadamente ou torná-lo "ok" perder a conclusão de histórias de usuário em um sprint, mas em Ao mesmo tempo em que coisas inesperadas surgem e essas histórias não são concluídas e são enviadas para o próximo sprint, você não quer ter a sensação de que fez algo errado. Isso não deveria ser uma experiência assustadora ou negativa, deveria?

As experiências negativas / assustadoras são aceitáveis ​​por compromissos de sprint perdidos? Os desenvolvedores devem ser responsabilizados por compromissos perdidos de sprint quando surgirem tarefas inesperadas que devem ser tratadas (por exemplo, suporte à produção)?

Você deve absolutamente tentar fazer os itens em um sprint.

Um dos principais benefícios do SCRUM é que ele dá ao projeto um 'batimento cardíaco'.

Você prioriza, seleciona itens de uma lista, entrega-os, demonstra-os, reflete como eles foram e, em seguida, faz novamente em ciclos imprevisíveis.

Todo o planejamento, estimativas e priorização são baseados nesse conceito. Que podemos e iremos cometer pontos X no sprint e, com o tempo, podemos estabelecer uma velocidade a partir da qual podemos usar para um melhor planejamento.

Se você é muito despreocupado com o conteúdo e os compromissos de seus sprints, o SCRUM simplesmente quebra na minha opinião e você perde muitos benefícios.

É claro que o mundo real às vezes tem algo a dizer sobre isso, mas essa deve ser a exceção e não a regra ...

A chave é que é preciso haver responsabilidade em não deixar as histórias completas.

Isso significa que deve haver uma razão sólida para que uma história não esteja completa e que essa razão seja contabilizada no plano do projeto daqui para frente, para que não seja repetida.

Essa razão precisa ser mais do que uma vaga "coisa que surgiu".

Por exemplo, se uma história não foi concluída porque um membro da equipe teve que trabalhar em um problema de produção, essa possibilidade precisa ser tratada em iterações futuras - planejando menos horas com esse membro da equipe ou organizando outra cobertura.

Se o motivo puder ter sido evitado com mais diligência ou trabalho duro antecipadamente, sim, essa responsabilidade pode ser um pouco dolorosa. Felizmente, a dor é da variedade "Isto é o que precisamos fazer melhor da próxima vez" em vez da variedade "Você não está fazendo seu trabalho".

Isso não deveria ser uma experiência assustadora ou negativa, deveria?

Se isso acontece uma ou duas vezes, não, então não deve ser uma experiência negativa. Se isso acontece regularmente, você tem um problema. A equipe está sempre supercomprometida. Melhore a estimativa e pense duas vezes sobre o que você compromete em um sprint, mas não fique ansioso.

Sprints relaxados significam que você teve um comprometimento insuficiente.

Sprints relaxados significam que você teve um comprometimento excessivo.

Eu apenas entrego o que comprometo e tento melhorar na execução. Somente em circunstâncias especiais eu mudaria uma história para o próximo sprint. Eu prefiro ter uma leve pressão todos os dias do que sofrer um pouco de pressão pouco antes de alguns prazos.

Com base na minha experiência - Como qualquer outra coisa no Agile, nos adaptamos a um sistema de feedback contínuo, incluindo a estimativa.

Não há problema em perder um prazo para o primeiro sprint (início do projeto), mas você APRENDE daquilo que deu errado (subestimação, sem conhecer os pontos fortes da equipe etc.). Então você pega o feedback e o alimenta para o próximo sprint e obtém uma estimativa melhor.

Pela minha experiência, já faz 11 meses em meu novo projeto ágil que raramente perdemos o prazo agora, se é que o perdemos. Mas perdemos o prazo para o primeiro sprint, porque não conhecíamos o ritmo e a força dos membros da nossa equipe.

Algumas pessoas argumentam que "alocam" mais tempo para o primeiro sprint superar o primeiro problema do sprint.

É interessante ver as respostas / comentários aqui. Em todos os projetos ágeis (do tipo) nos quais trabalhei, a principal vantagem era espalhar a pressão do prazo por muitos mini prazos, em vez de uma marcha de morte no prazo final de um projeto. Na IMO, os sprints devem ser levados a sério. Quaisquer falhas no prazo ou na funcionalidade entregues devem ser vistas como possíveis problemas no gerenciamento ou no desenvolvimento do projeto.

Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente. - Princípios por trás do Manifesto Ágil

Se é uma experiência assustadora ou negativa, e acontece o tempo todo, você tem um problema. O desenvolvimento de software deve ser divertido. Não é negativo ou assustador.

No entanto, se a equipe se comprometer a terminar algumas histórias em um sprint e não entregar continuamente, você também terá um problema. Este problema quase certamente não será resolvido, adicionando mais pressão à equipe para concluir as histórias. Se o problema é devido a fatores externos, eles precisam ser gerenciados. Se a equipe está comprometendo demais, o ScrumMaster pode orientá-la a se comprometer com menos pontos na história. Pode haver muitos motivos e cada um pode precisar ser tratado de maneira diferente. Uma equipe enérgica e motivada deve ter muita motivação para seguir em frente.

Idealmente, qualquer que seja o problema, ele é levantado durante a retrospectiva e corrigido.

Não deve ser tão complicado para a equipe descobrir o que eles podem realizar durante o período relativamente curto do sprint e depois realizá-lo (uma história ocasional que é levada para o próximo sprint é OK, a velocidade pode flutuar, as coisas mudam etc. .). Se você não conseguir fazer isso razoavelmente bem após alguns sprints, estará fazendo algo errado.

Realmente depende da sua linha do tempo.

Às vezes, você precisará concluir todas as histórias, ou a maioria delas de qualquer maneira. Embora o Agile forneça alguma flexibilidade, você também precisará concluir o projeto, possivelmente em um cronograma apertado. Portanto, ter a maioria das histórias feitas permitirá que você conclua o projeto a tempo.

Com isso dito, no entanto, surgirão coisas que o impedirão de realizar todas as histórias, todos os sprints.

Se o produto estiver em uma linha do tempo e as principais histórias forem perdidas, essa falha poderá atrasar o produto. O atraso do produto em alguns casos pode prejudicar a posição competitiva de uma empresa. Portanto, nesse caso, você pode querer que seja uma experiência negativa a falta de histórias - isso pode fazer com que você faça tudo da próxima vez.

Quando administrado corretamente, o estresse é bom. Você quer não querer eliminar todo o estresse, apenas espalhá-lo de maneira mais uniforme no tempo. Mesmo quando você joga seu jogo favorito, você terá uma certa quantidade de estresse e sentimentos negativos. Você realmente obtém mais energia disso.

Uma equipe deve se sentir realmente mal com as histórias perdidas. Isso lhes dará energia para mudar alguma coisa na próxima vez (trabalhe de maneira diferente ou planeje menos histórias, ambas são boas). Eles também devem sentir orgulho quando fazem suas histórias, é claro.

Você também menciona tarefas inesperadas (suporte à produção). Isso levanta uma bandeira vermelha comigo. Deveria haver um prazo combinado para todas as questões não relacionadas às histórias. Caso contrário, o jogo não é justo, a equipe se sente desamparada e os sentimentos negativos não são usados ​​para melhorar.

Você deve examinar os fatores que fazem com que seus compromissos falhem e tentar consertá-los. Grandes quantidades de eventos aleatórios continuarão atrapalhando seus sprints, tornando sua velocidade imprevisível. Corrija as causas disso ou introduza folga nos seus sprints. Eu prefiro consertar.

De qualquer forma, a equipe não pode ser responsabilizada se seu trabalho for perturbado por fatores externos. Use retrospectivas para analisar isso.