User Story: Entendendo o conceito de DOD no Scrum

No artigo anterior, nós falamos sobre o conceito de DOR no Scrum e o quanto entender sua definição é importante para nós, já que ela pode nos ajudar no refinamento de cada item Backlog.

O conceito de DOD no Scrum

No artigo de hoje nós vamos entender o conceito de DOD no Scrum, para fecharmos essa parte de escrita completa de User Story. E para entendermos o conceito de DOD, hoje vamos descobrir como o DOD pode nos ajudar a definir a conclusão de uma funcionalidade e a declará-la pronto.

Entendendo o conceito de DOD no Scrum

Para começar vamos entender o que DOD quer dizer.

DOD = Definition of Done.
Tradução literal: Definição de pronto.
Conceito do DOD: ajudar o time a listar os itens necessários para que a tarefa seja dada como concluída.

Dito isso, preciso dizer também, que por causa da singularidade de cada projeto, não existe uma definição item fixo no DOD. De forma que o Time deve seguir todas as etapas do projeto (as que foram traçadas durante a User Story).

O único ponto incomum no desenvolvimento de todos os produtos e/ou projetos, é que cada Time deve desenvolver o produto considerando, sempre, as definições da User Story:

Os desafios do produto;
As plataformas tecnológicas utilizadas;
As necessidades dos usuários.

Um fato sobre esse assunto, e que também precisamos considerar, é que a definição desses pontos que falamos acima, acontece antes mesmo de ser iniciado o desenvolvimento do produto.

Lembrando que se for necessário rever a definição de pronto, isso deve ser feito no evento de planejamento da Sprint.

Resumindo o conceito de DOD no Scrum

Na prática, no dia a dia do desenvolvimento de um produto, a DOD, é como a DOR. Isso porque, assim como no DOR, ela tem como estratégia montar uma lista para verificar as etapas do desenvolvimento. E assim como na DOR, na DOD a tarefa só pode ser considerada concluída, quando ela atender aos requisitos especificados nesta lista.

Requisitos que fazem parte da DOD:

Integrações com Application Programming Interface (API)
Homologado pelo time;
Testes unitários e automatizados;
Evidência dos testes;
Documentação técnica.

Chegamos ao final do nosso artigo, e espero que tenha ficado bem didático o conteúdo.

O meu objetivo nesses últimos artigos foi mostrar para você, que o entendimento dos critérios de aceite, Regras de negócio, DOR e DOD é fundamental para o desenvolvimento de uma User Story.

Como profissional que já atua a muitos anos na área, ouso dizer que entender o conceito de DOR e DOD no Scrum é chave no desenvolvimento ágil de produtos; e que para ter um resultado bem-sucedido, todo o Time Ágil deve estar alinhado com esses conceitos.

Encerro esse artigo te convidado para fazer a leitura dos artigos relacionados ao assunto de construção de User Story, já publicados aqui no site.

Nos vemos no próximo artigo. Até!

Se você se interessa pelo tema e quer saber como aplicar o SCRUM, transformar sua carreira, aumentar o valor de mercado da sua empresa e ser um profissional que entrega resultados de alto valor e performance, clique aqui Scrum Training e saiba mais sobre esse framework que é tendência mundial.

#canvas #MVP #persona #sprint #uxdesign #userinterface #designthinking #plc #pitch #agile #agilidade #SCRUM #kanban #lean #produtosdigitais #backlog #okr #productdiscovery #productowner #scrummaster #userstory #agilista #leaninception #planningpoker #brunafonsecapro