Uma discussão que sempre gera muita negociação é o que o time pode se comprometer a fazer em uma determinada Sprint Backlog?
Obviamente que o PO tem a atribuição de definir o que deve ser priorizado, podendo aplicar diversas técnicas para tal (MOSCOW[a], KANO[b], WSJF[c], etc).
De qualquer forma cabe ao time nas cerimônias de refinamento e planning aferir se os acordos das histórias estão sendo cumpridos. Por exemplo:
Story
- As histórias estão DOR (Definition of Ready), com o detalhamento necessários para compreensão do time, ou seja, detalhamento de ao menos um critério de aceite, wireframe/protótipo de baixa fidelidade?
- A história é do tipo INVEST(Independent, Negociable, Valuable, Estimable, Small e Testable). Ou seja, sua atomicidade garante um desenvolvimento desacoplado, pode ser negociada, tem valor suficiente para uma implementação para o cliente, é passível de ser estimada e suficientemente testável?
- Existem riscos de indefinições técnicas, de negócio ou arquitetura que não serão resolvidas pré-Sprint?
- Existem dependências com outros times que não foram negociadas as demandas para sincronização adequada de implementação?
- A história tem uma importância e relevância para o cliente?
Está gostando deste post? Cadastre-se na nossa newsletter e receba os próximos conteúdos sobre transformação dgital e mais!
Maturidade
Times com baixa maturidade e sem um suporte adequado de um agilista do processo (Scrum Master e Agile Coach por exemplo), acabam não se atentando aos pontos citados acima. Isso corrobora ao não atingimento do objetivo definido na Sprint, perda do timebox estabelecido e consequentemente frustração entre os integrantes do time.
Ainda nessa linha, é necessário verificar se a formação do time foi montada de acordo com as características técnicas necessárias do que será implementado no roadmap das sprints planejadas.
Uma vez que os itens acima sejam considerados, o time consegue não aceitar histórias incompletas e que gerem riscos para cumprimento do objetivo estabelecido na Sprint.
Naturalmente que o time deve ter autonomia e maturidade suficiente para eventuais itens considerados “incompletos” não caiam para Sprint Backlog, onde se comprometem a entregar as histórias discutidas e entendidas para serem implementadas.
No início deste processo, naturalmente o time terá muitas dificuldades em fazer cumprir as regras/acordos definidos. Neste cenário, o agilista (como citado acima), ganha uma importância fundamental para orientar, passar direcionamento, realizar mentoring e nas retrospectivas tangibilizar ao time, eventuais motivos que a sprint “capotou” e não foi possível cumprir o que foi comprometido na planning. Por exemplo, histórias incompletas que o time permitiu que fossem construídas.
Outro aspecto importante que o agilista pode contribuir é não permitir que o time se fruste com insucessos iniciais, já que estamos lidando com modelo não prescritivo e empírico.
As retrôs neste cenários são muito importantes para identificar problemas de indefinições, riscos existentes, histórias incompletas e atuar em ações assertivas para que um novo ciclo não se repita as mas características de ocorrências.
Com esse acompanhamento realizado pelo agilista, o time vai ganhando cada vez mais confiança e empoderamento, para que nas próximas sprints o processo fique cada vez mais maduro e assertivo.
[a] MOSCOW
O termo MoSCoW é um acrônimo em inglês derivado da primeira letra de cada uma das quatro categorias com os “Os” no meio para fazer a palavra ser pronunciável. Dessa forma:
- Must Have (Tenho que fazer)
- Should Have (Devo fazer)
- Could Have (Poderia fazer)
- Won’t Have (Não vou fazer)
[b] KANO
O Modelo Kano (pronuncia-se “kah-no”) é uma abordagem para priorizar recursos em um roadmap de produtos com base no grau em que eles provavelmente satisfarão os clientes. As equipes de produto podem avaliar um recurso de alta satisfação em relação aos custos de implementação, para determinar se a inclusão ou não no roadmap é uma decisão estratégica.
[c] WSJF
Sigla com significado Weighted Shortest Job First, que realizando uma tradução objetiva seria trabalho com menor esforço e maior valor devem ser priorizados primeiro. Criando um peso de cada item do backlog para calcular qual teria mais relevância e menor esforço para ser desenvolvimento primeiro.
Artigo escrito por Sérgio Ricardo Vieira, Agile Coach da Mooven Consulting.
A Mooven Consulting é uma consultoria especializada em Agilidade Corporativa, Transformação Digital, Transformação Ágil e Gestão de Mudança Organizacional Ágil.