Sprint

Criação de sprint

Antes do sprint planning, é preciso criar o novo sprint, indicando as suas datas e o seu âmbito, de modo que seja possível à equipa trabalhar sobre as tarefas e associá-las ao novo sprint durante esta cerimónia.

Sprint planning

Product Backlog

Lista do trabalho a ser implementado na construção do produto (epic, story, task, bug).

Sprint Planning

Durante o sprint planning, a equipa analisa os issues prioritários do Product Backlog e identifica, detalha e estima todas as tarefas necessárias à sua concretização. De acordo com as estimativas e a capacidade da equipa, são selecionadas as tarefas para execução durante o sprint.

Uma query similar à seguinte pode ser útil para identificação dos temas que não foram concluídos no sprint anterior e deverão transitar para o novo sprint (a transição é automática, mas o respetivo esforço deverá ser tido em conta aquando da definição do novo compromisso da equipa): project = PDT AND sprint = "Sprint 24" AND status not in (Abandoned, Done) ORDER BY fixVersion, cf[10046], status.

Sprint Backlog

Lista das tarefas que a Equipa selecionou para execução durante o sprint, e que correspondem ao seu compromisso, a fim de que exista um incremento de funcionalidade no produto.

Abertura de sprint

Para que seja possível realizar a abertura do sprint, tem de ser conhecido o Sprint Backlog, garantindo as seguintes validações básicas sobre o mesmo:

  • Apenas as tarefas que irão ser trabalhadas durante o sprint devem fazer parte do Sprint Backlog;

  • Todas as tarefas têm de ser criadas no contexto de um epic. A identificação das tarefas sem epic atribuído pode ser realizada por recurso a uma query similar à seguinte: project = PDT AND "Epic Link" is EMPTY AND type != Epic AND type != subtask ORDER BY created DESC;

  • As tarefas que estão relacionadas com negócio, é essencial que estejam ligadas à respetiva story (Linkar outros issues);

  • Todas as tarefas têm de ter uma previsão de entrega, pelo que deverão ser associados a uma release (Associar issues). A identificação das tarefas sem release atribuída pode ser realizada por recurso a uma query similar à seguinte: project = PDT AND fixVersion is EMPTY ORDER BY cf[10046] ASC;

  • Todas as tarefas têm de ter uma estimativa definida, tipicamente em story points, ocasionalmente em tempo. O número de story points a adicionar ao sprint deve ter em conta a velocidade da equipa (Velocity chart);

  • Todas as tarefas dizem respeito a um ou mais componentes, o que facilita às equipas a identificação das suas tarefas para execução. A identificação das tarefas sem componente atribuído pode ser realizada por recurso a uma query similar à seguinte: project = PDT AND component is EMPTY ORDER BY created DESC;

  • Se facilitar o trabalho do product owner, para permitir a visualização da lista de issues em árvore de hierarquia, todas as tarefas deverão ter um business unit value atribuído. A identificação das tarefas sem business unit value atribuído pode ser realizada por recurso a uma query similar à seguinte: project = PDT AND "Business Unit Value[Short text]" is EMPTY ORDER BY created DESC Business Unit Value.

O campo business unit value é um campo de gestão manual. Uma possível regra de preenchimento é ilustrada no exemplo seguinte:

  • E1.Epic 1 – Business Unit Value do Epic 1

    • E1S1.Story 1 – Business Unit Value da Story 1 do Epic 1

      • E1S1.Story 1 – Business Unit Value de qualquer tarefa associada à Story 1 do Epic 1

      • E1S1.Story 1 – Business Unit Value de qualquer bug associado à Story 1 do Epic 1

      • ...

    • E1S2.Story 2 – Business Unit Value da Story 2 do Epic 1

      • E1S2.Story 2 – Business Unit Value de qualquer tarefa associada à Story 2 do Epic 1

      • E1S2.Story 2 – Business Unit Value de qualquer bug associado à Story 2 do Epic 1

      • ...

    • ...

  • E2.Epic 2 – Business Unit Value do Epic 2

    • E2S1.Story 1 – Business Unit Value da Story 1 do Epic 2

      • ...

    • E2S2.Story 2 – Business Unit Value da Story 2 do Epic 2

      • ...

    • ...

  • ...

Sprint review

Durante o sprint review, o product owner apresenta o incremento do produto, com o auxílio da equipa. Para a respetiva preparação dos temas a demonstrar, poderá ser útil uma query similar à seguinte: project = PDT AND sprint = "Sprint 24" AND status in (Review, Done) ORDER BY cf[10046], status.

Fecho de sprint

Após a realização do sprint review, o sprint atual é fechado, sendo que todos os issues que o compunham e que ainda não estavam concluídos (no estado done ou abandoned) transitam automaticamente para o novo sprint.

Last updated