Contando artefatos do scrum

Vocês conhecem os artefatos do scrum? Eu pensei que os conhecia. Então, antes de escrever este post, dei aquela revisada no conteúdo para não dar bola fora e o resultado foi bem diferente do que eu esperava. Por exemplo, no livro do Rafael Sabbagh sim, a gente curti muito esse livro, ele apresenta sete itens, sendo uma mescla entre o que o scrum prega e artefatos que ele adicionou em seu livro (na página 30 Sabbagh comenta sobre isso). Sem contar que os resultados que o google me ofereceu variaram muito. E antes de dizer do resultado da minha revisão, vamos entender o que são artefatos do scrum, seguindo o Scrum Guide.

Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação.

Os artefatos são peças de entradas e saídas para fazer movimentar a famosa engrenagem do scrum e, com isso, gerar energia para os três pilares que se basea esse processo empírico: transparência, inspeção e adaptação.

Comforme as atualizações do Scrum Guide, temos três artefatos:

Product Backlog

Uma lista priorizada com os requisitos/itens/demandas necessárias/bugs/melhorias para atender o produto a ser gerado no decorrer do projeto. Esse artefato é mutável e deve ser atualizado e ordenado pelo Product Owner (PO). Essa lista também alimenta as atividades do time de desenvolvimento.

Sprint Backlog

Este artefato é a lista de itens selecionados do topo do Product Backlog, devidamente refinado e preparado para o time desenvolver durante um sprint. Esta lista pertence ao time de desenvolvimento. Esse artefato auxilia o time a atingir o objetivo do sprint e acrescentar ao produto esperado.

Incremento do Produto

Copiando do Scrum Guide:

O incremento é a soma de todos os itens do Backlog do Produto completados durante a sprint e o valor dos incrementos de todas as sprints anteriores. Ao final da sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e atender a definição de “Pronto” do Time scrum. Este deve estar na condição utilizável independente do Product Owner decidir por liberá-lo realmente ou não.

Preciso comentar algo mais?

Poxa, tão pouco e tão simples né?!É né …

Ao final, fiquei refletindo o porquê de achar que tinha mais artefatos que o framework apresenta e cheguei na seguinte conclusão. Primeira hipótese, ao se tratar de um framework não precisamos saber o como fazer, mas quais são os itens necessários para as atividades do trabalho proposto. Por exemplo, o scrum não diz que devo usar uma lista em excel ou post-its para descrever o meu backlog, somente diz que devo ter um Product Backlog, para que serve e quem deve cuidar dele. Assim como, ele não comenta que devo formatar as funcionalidades em user story e ter o gráfico de burndown para monitoração das atividades. O scrum diz que devo fazer ser transparente de maneira que possa inspecionar e adaptar.

Segunda hipótese, após trabalhar com algumas ferramentas e técnicas, acabei absorvendo-as ao scrum. Quando, na  verdade, esse arsenal de outras áreas se encaixam bem com ao scrum, uma vez que ele é um framework. Tornando-se um meio para atingir um fim, que é aplicar os princípios e valores. Como o próprio Scrum Guide conclui, o scrum funciona como um “container para outras técnicas, metodologias e práticas.”

Ao querer praticar ao scrum não é necessário fazer todo um reboliço para utilizá-lo. Primeiro, tente adaptar algo do seu modo de operar e com o decorrer, adicionar boas práticas que o mercado oferece. Torne a sua adaptação simples, menos dolorosa. Não é a toa que o scrum está sendo aplicado em diversas áreas de negócio. 🙂

Adorei escrever esse post, foi um bom momento de reflexão.

Convido todos a fazer essa reflexão também.

Abraços.