Entendendo a relação entre histórias (User Story) e tarefas

No meu artigo anterior falei sobre o planejamento das equipes ágeis o que nos levou a User Story (histórias) e consequentemente a tarefas, neste artigo vamos mais a fundo na relação entre User Story e tarefas.

Cada história é uma coleção de tarefas, onde a história descreve a necessidade do usuário e a tarefa descreve como a funcionalidade será implementada, como a tarefa representa o trabalho real teremos um nível de granularidade muito maior.

A definição das tarefas para cada história, ocorre quando alocamos a história na iteração atual e isso é muito bom, pois teremos maior feedback e detalhes para assim melhor elaborar as tarefas a serem executadas para aquela história.

As tarefas são estimas em horas, é recomendado estimar o tamanho das tarefas entre 2-12 horas, para tarefas que requerem mais que 12 horas quebre estas em várias tarefas de menos de 12 horas.

Quando uma história está PRONTA (DONE)?

Em SCRUM utilizamos o termo DONE para indicar que uma história já teve seu desenvolvimento finalizado e está pronta para ser avaliada pelo Produtct Owner. A própria equipe cria sua definição de DONE, que pode ser um único critério ou um conjunto, abaixo um exemplo:

  • Todas as tarefas completadas (desenvolvimento, testes, documentação)
  • Executar e passar em todos os testes de aceitação
  • Nenhum defeito aberto
  • Aceitação do product owner
  • Pode ser enviado ao usuário

Com isso a equipe se compromete a entregar todas as histórias com base na definição estabelecida.

Critérios de Aceitação

Assim como a equipe define o DONE para cada história, o product owner ou cliente são responsáveis por descrever seus critérios para aceitarem a história, estes critérios podem descrever a funcionalidade, comportamento e desempenho que eles esperam para tal recurso.

O papel dos critérios de aceitação é definir o que DONE é exatamente, isso irá ajudar ao desenvolvimento saber quando eles completaram a história. Se existem partes da história que você não quer deixar para o desenvolvimento definir, escreva um critério de aceitação. Por exemplo, se você acha que deve definir as mensagens de erros e como elas serão apresentadas, você pode fornecer um documento de design para explicar o formato e texto das mensagens de erro ou você pode escrever critérios de aceitação para cada história que venha a gerar uma mensagem de erro.

Para finalizar, história, critérios de aceitação e tarefas para implementar a história representa um requisito em ágil.

No próximo artigo vamos falar sobre Daily Standup.

4 respostas
  1. Celso Henrique
    Celso Henrique says:

    Bom dia Andreano,

    Os Critérios de Aceitação é um documento formal? Ele especifica a aceitação de uma única história ou define a aceitação de todas as histórias? Caso a história precise de testes para receber o status DONE, os requisitos a serem testados estão todos contidos no critério de aceitação? Em que momento são levantados estes critérios junto ao cliente? Existe um sprint específico para isso?

    Fico no aguardo!

    Atenciosamente.

    Responder
  2. Rodrigo Martim
    Rodrigo Martim says:

    Bom dia Andreano, tudo bem? espero que sim

    Você teria algum software que gerencie SCRUM para sugerir?
    Atualmente utilizo TRAC + AGILO devido ao mesmo integrar ao SUBVERSION, porém, a versão que tenho deixa a desejar em alguns aspectos.

    Agradecido desde já,
    Um abraço,

    Responder

Deixe uma resposta

Want to join the discussion?
Feel free to contribute!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *


Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.