*Este texto é uma tradução e adaptação de “Epics, Stories, Tasks, Subtasks… what’s the difference“, de Kelly Albrecht, disponível em https://lastcallmedia.com/blog/epics-stories-tasks-subtasks-whats-difference.

Intro

Epics, Stories, Tasks e Subtasks são termos normalmente usados nos sistemas de gerenciamento de problemas (issues), mas frequentemente equipes iniciam seus trabalhos sem estarem alinhadas em relação ao significado desses termos e as diferenças entre eles. É fácil cometer esse erro pois, na maioria das vezes, realmente parece muito mais importante executar as tarefas e fazer as coisas acontecerem, do que discutir e entrar em consenso sobre algo tão específico como “de que forma classificaremos nossos problemas”.

Ainda que as definições desses termos geralmente sejam as mesmas para os mais diversos times, há situações onde adaptações podem ser feitas gerando diferenças na forma de aplicação prática. Isso geralmente ocorre devido a restriçoes do contexto (eg. estrutura do software ágil).

O que é importante saber?

A forma mais fácil de entender a diferença entre essas classificações de problemas é entendendo O QUÊ torna esse tipo de atividade acionável. De modo rápido, usaremos Task para aquele problema que precisa ser resolvido e está descrito de uma forma clara, de modo que qualquer pessoa possa executar a tarefa sem precisar fazer perguntas ou discutir soluções. Os demais tipos de problemas tornam-se úteis no gerenciamento colaborativo quando exploramos também o valor de cada um deles para o projeto.

Quando somos solicitados a fazer algo, a primeira coisa a fazer é avaliar se faremos. Se vamos nos comprometer, nos responsabilizar pelo compromisso, de executar aquilo ou não.

“Compromissos são a moeda da confiança, por isso precisamos levá-los a sério.” (Kelly Albrecht)

Nem todos os problemas são claros. Alguns precisam de uma boa discussão. Nesses casos, vamos discutir, definir, detalhar e avaliar antes de assumir um compromisso razoável.

Quando o Product Owner traz a lista de demandas para o time de desenvolvimento, um desenvolvedor só poderá se comprometer a entregar algo se todas as atividades estiverem quebradas em pequenas e claras tarefas executáveis. Os termos que queremos distinguir representam uma hierarquia de ideias e suas classificações em relação ao nível de clareza para a execução, de modo que a conclusão de todas as tarefas resultem na realização da ideia principal.

Diagrama de atores e hierarquia de problemas (issues).

Stories

Stories contém ideias, que geralmente levam à outras novas ideias. O objetivo de uma história é o conteúdo, e não o modo como será feito. Quando um problema é classificado como Story, estamos reconhecendo que há a necessidade de uma discussão sobre o assunto para chegarmos a um entendimento coletivo daquela ideia. Uma Story representa O QUÊ, e não COMO. É a descrição do que é esperado ao final, quando a ideia se tornar realidade. Por isso estimamos esse tipo de problema com Story Points, uma pontuação exclusiva para medir a capacidade da equipe de atingir um valor entendido como proveniente da própria história.

Boas Práticas

Existem algumas boas práticas a serem exploradas quando falamos de Stories. Uma delas é garantir que toda Story esteja de acordo com o I.N.V.E.S.T.:

I.N.V.E.S.T

• (I)ndependent — A atividade não depende de nenhuma outra atividade, e pode ser executada e testada por si só, sem influências externas ao próprio problema em si.
• (N)egotiable — A atividade é negociável, ou seja, o objetivo que se pretende pode ser alcançado por diferentes caminhos, sendo flexível o COMO as coisas acontecerão, mas não os requisitos do QUÊ se espera no final.
• (V)aluable — A descrição da atividade revela o valor dentro dela. É possível inferir a importância da ideia, pois ela acrescenta um valor claro ao projeto.
• (E)stimable — Significa que a ideia precisa ser simples e clara o suficiente para que alguém possa considerar o esforço necessário para torná-la real.
• (S)mall — As histórias pequenas são, naturalmente, independentes e estimáveis. Então, torná-las pequenas vai ajudar a cumprir os demais requisitos.
• (T)estable — A descrição deve ser clara de modo que, ao concluir a execução da atividade, seja possível testar e identificar se o problema foi resolvido ou não.

Quando uma ideia não se encaixa inicialmente nesses requisitos, uma boa estratégia é dividi-la em ideias menores. Existem diversas abordagens para realizar esta divisão, e talvez eu aborde este tema em outro texto futuro.

Quando uma ideia se encaixa nesses requisitos, ela é marcada como Story e será posteriormente discutida e dividida em tarefas e subtarefas para que os compromissos sejam possíveis. Esse conceito é importante pois reconhece a importância de um pré-trabalho de planejamento e alinhamento em equipe antes que compromissos sejam feitos. Esse costume é saudável para uma equipe que pretende fazer grandes coisas.

Como descrever uma Story?

Um padrão comum de descrição de Stories é o seguinte:

Como um [Papel desempenhado pelo ator], eu preciso [Algum objetivo], de modo que [Um ou mais requisitos para que se verifique que o objetivo foi alcançado].

Descrever uma Story dessa forma ajuda a atender os requisitos do I.N.V.E.S.T.

Lembre-se que nem tudo precisa ser uma história. Se você for solicitado a pintar uma parede de Azul com a tinta e o rolo fornecido, essa tarefa provavelmente não precisará de uma conversa antes de você decidir se vai ou não se comprometer com ela.

Tasks

Tasks, por outro lado, não recebem o mesmo tratamento que as Stories, pois são geralmente auto-explicativas. Mas podem sofrer alguma discussão e até uma divisão em equipe para subtarefas se necessário quando um colega de equipe está muito receoso de se comprometer com esta atividade.

As Tasks ainda não precisam descrever o COMO, embora às vezes isso possa acontecer. Tasks costumam ser uma descrição simples de algo que precisa ser feito para alcançar um pedaço da Story. Não tem um valor claro em si própria, mas seu valor pode ser compreendido quando em conjunto com as demais tasks da Story.

Subtasks

Subtasks são a menor peça a ser visualizada no planejamento do trabalho. São também uma ferramenta para que os desenvolvedores detalhem o COMO desejam executar a Task e decidam se vão se comprometer com aquilo ou se precisam dividir ainda mais o problema.

Nem toda Task precisa ter Subtaks. Mas se existe a necessidade de descrever subtarefas, então toda a Task deve ser descrita em pequenas Subtasks, de modo que o problema seja completamente compreendido e, ao concluir todas as Subtaks, alcançarmos o objetivo da Task principal.

Epics

Epics são as ideias maiores, que não podem ser definidas como Story, e precisam ser divididas em pequenas ideias que atendam aos requisitos I.N.V.E.S.T.

Na hierarquia das ideias, podemos colocar acima das Epics ainda as Initiatives e os Themes. Entretanto, quando pensamos em registrar isso em quadro ágil como Kanban ou Scrum, somente o nível Epic e inferiores são descritos, sendo os níveis mais altos definidos em documentos colaborativos como o Confluence ou o Google Docs. A partir dessa documentação, identificamos as Epics, Stories e tasks que serão registradas na ferramenta ágil de sua escolha.

Hierarquia de Organização das ideias (problemas/issues).