Scrum OnePage controlando backlog com o Gsuite da Google

O Scrum OnePage não é um novo framework é apenas uma planilha utilizando o G Suite da Google para facilitar a vida de Gerentes de projeto e Product Owners ao redor do mundo usando Planilhas Google como uma ferramenta para coletar métricas de histórias de usuários.

Afinal no final da construção de um backlog você precisa planejar e se está trabalhando com Times Remotos o melhor é ter algo com uma visão completa.

Motivação para o uso de uma planilha

Você pode perguntar “Coimbra, tem mil ferramentas no mundo e você quer utilizar uma planilha?” Sim! A resposta é simples e direta, afinal existem muitas ferramentas para a utilização do Scrum, mas sua empresa está preparada para transformação digital? Melhor ainda, transformação mental? A cultura ágil não é só saber usar bem algumas ferramentas de mercado, e sim trabalhar bem com os conceitos.

Neste caso recomendo que utilize o Scrum OnePage. 

Como diria um antigo professor “Gestão de projetos a gente faz até em papel de pão com lápis, basta saber como gerenciar” por isso peço que você entenda o motivador:

O Scrum OnePage aumenta a probabilidade de sucesso do projeto, garantindo que sua equipe esteja criando os recursos certos para o maior valor e ajudando a criar um equilíbrio saudável entre os lançamentos.

O Scrum OnePage com o Google  Planilhas pode ser usado como uma ferramenta para agregar e revelar insights sobre suas histórias de usuário.

Alguns truques simples ajudarão você a confirmar se o roteiro e os planos de lançamento estão alinhados com a visão do projeto, metas específicas e entrega de valor comercial consistente.

Existem muitos métodos para reunir e trabalhar com histórias de usuários, desde softwares construídos especificamente até o tradicional post-it.

Em última análise, a ferramenta que você usa para realizar o trabalho é irrelevante, desde que suas sessões de ideação tenham capturado os recursos, as metas e a essência do projeto ou produto.

Você não pode refutar o poder de uma sala cheia de pessoas batendo post-its em um quadro branco, mas também há algo a ser dito sobre eficiência em que um computador com Scrum OnePage pode ordenar, agregar e analisar a saída de suas conversas de forma clara ilustrar tendências e anexos.

As abas

O modelo inclui várias folhas. A primeira planilha é a lista de recursos e histórias de usuários que parecerão familiares às pessoas com experiência em exercícios e artefatos de história do usuário.

A segunda folha utiliza uma tabela dinâmica (pivot) para dar uma rápida olhada em quanto valor está sendo colocado em quais recursos.

A terceira planilha é nada mais que um dashboard que vai exibir uma análise de alto nível na forma de gráficos.

As planilhas que seguem servem uma para cada sprint para preencher seu dashboard com a situação e uma foto de cada uma delas.

A última planilha é um calendário de recursos e Niko-Niko.

As colunas da folha de história do usuário

De forma alguma eu pretendo prescrever exatamente quais pontos de dados você deve capturar em seu documento o Scrum OnePage é apenas algo que fui adaptando.

O que é importante para você e sua empresa pode variar do que descrevi aqui, e o núcleo das metodologias ágeis incentivaria você a conversar com sua equipe sobre quais dados são relevantes para seu processo no contexto de seus projetos.

Dito isto, é essencial que você esteja ciente de quais colunas são capturadas no Scrum OnePage e de que você use uma confirmação cuidadosa em tantas partes interessadas tanto quanto seja prático para garantir que os valores inseridos sejam os mais precisos possíveis.

Aqui estão as colunas que estou reunindo neste modelo:

ÉPICO

Essa coluna deve representar uma grande quantidade de trabalho que precisará ser dividida em várias dezenas de histórias de usuários.

Você pode facilmente trocar o recurso de trabalho por qualquer outro termo que a sua organização use para um grande agrupamento de histórias, como “épico” ou “tema”.

A terminologia não é relevante desde que você tenha um meio de agrupar suas histórias de maneira lógica para que possamos fazer algumas análises sobre agrupamentos de histórias nas outras planilhas.

USER HISTORY

As histórias são os meios fundamentais de comunicação, planejamento e negociação entre a equipe do scrum, os proprietários do negócio e o proprietário do produto.

Cada história deve seguir o princípio “INVEST” as histórias devem ser:

  • Independente de outras histórias para facilitar a negociação, a priorização e a implementação;
  • Negociável com o cliente, para que o time possa manter um ritmo sustentável para a entrega  contínua de valor;
  • Valorosa, assim cada entrega agregará grande valor ao negócio do cliente;
  • Estimável, desse modo o time poderá estabelecer quais histórias serão implementadas de  acordo com sua velocidade;
  • Small (Tamanho apropriado) o suficiente para ser implementada dentro de uma iteração, sem correr grandes riscos de não a completar;
  • Testável, apenas assim poderá ter qualidade na entrega e certeza de que o cliente aceitará a  história como pronta.

Um formato padrão é o seguinte: “Como {{persona}}, gostaria de {{fazer uma ação}}, Então {{motivo}}}.

A maneira como você constrói suas histórias é menos crítica do que garantir que você esteja respondendo a três coisas: quem, o quê e por quê.

PRIORITY

Uma medida relativa de quando a empresa gostaria de ver uma história divulgada em comparação com as outras histórias. Isso deve ser sempre fornecido pelos proprietários de negócios ou partes interessadas.

No modelo, permitimos valores 1-4, em que 1 é prioritário alto e 4 é baixo. Deixando de lado o debate “ordenado” versus “priorizado”, permanece o fato de que, fora da sua equipe scrum, os empresários tendem a ter características particulares que, devido a complexas pressões competitivas externas ou políticas, precisam ser priorizadas antes de outros recursos que oferecerão mais valor do usuário.

É certamente importante notar que, em muitos projetos, a linha entre prioridade e valor pode ser tão boa que essa coluna se torne redundante e desnecessária.

VALUE

Esta é uma medida relativa de quanto uma história enriquecerá a experiência de um usuário ao interagir com o produto.

Para manter as coisas simples, também estamos permitindo apenas 4 opções de 1-4, onde 1 é alto valor e 4 é baixo valor.

Como você determina o valor pode variar. Quando possível, tente utilizar métricas mensuráveis ​​ou, pelo menos, ter em conta a perspectiva de várias partes interessadas.

RISK

O risco pode ser avaliado por quanto impacto negativo uma história poderia ter sobre a experiência de um usuário, caso a história não fosse adequadamente implementada ou quanto impacto essa história poderia ter em outros processos e sistemas existentes diretamente ligados à funcionalidade descrita no relatório

Histórias de alto risco podem exigir um planejamento cuidadoso e habilidades especializadas adicionais, a fim de mitigar os riscos e implementar adequadamente.

De acordo com as duas colunas anteriores, também estamos usando a mesma escala 1-4, embora aqui 1 possa ser percebido como geralmente negativo, enquanto que nas colunas anteriores 1 poderia ser considerado positivo.

ESTIMATE

Essa é quantidade relativa de trabalho necessária para concluir uma história em comparação com outras histórias. Isto pertence estritamente à equipe de entrega e somente à equipe de entrega.

Nesta fase de um projeto, você deseja manter as estimativas aproximadas. Lembre-se de que sua equipe de entrega continuará a refinar a estimativa de cada história à medida que ela for mais próxima de ser incluída em um backlog de um sprint ativo.

Nesta fase de produção, recomendo usar o método de dimensionamento “tamanho da camiseta” (XSm, Sm, Md, Lg, XLg, XXLg).

À medida que as histórias se aproximam de um backlog de sprint, a equipe pode querer reestimar usando os valores de sequência de Fibonacci no software de acompanhamento de projetos da equipe (Jira, VSO, etc.) para aumentar a fidelidade do tamanho relativo de uma história.

SPRINT

A sprint em que a funcionalidade vai ser desenvolvida, aplicada e terminada.

RELEASE

Esta coluna destina-se a auxiliar no refinamento do roteiro do produto. Esta coluna não deve ser preenchida para uma história até que as colunas mencionadas acima tenham sido avaliadas.

É aqui que a mágica acontece

Um Product Owner deve ser capaz de digitalizar a prioridade, o valor, o risco e a estimativa e combinar essas variáveis ​​com o entendimento geral do projeto e as demandas do mercado para fazer a primeira passagem em qual versão do produto essa história / recurso seria ideal ser liberado para o público.

O Product Owner continuará atualizando esta coluna à medida que o feedback é recebido das outras duas planilhas sobre as quais falaremos momentaneamente.

Notas: A coluna de notas pode ser usada para qualquer contexto relevante adicional que possa informar decisões tomadas sobre os valores fornecidos nas colunas. Pessoalmente, gosto de aproveitar qualquer oportunidade para vincular histórias e recursos específicos aos objetivos associados à declaração de visão do produto.

Outras Colunas Opcionais: Se você está pensando Agile, então seja ágil sobre as colunas que você acha que irão agregar valor ao seu processo.

No Planilhas Google, você pode adicionar quantas colunas desejar à sua cópia do modelo e ocultar facilmente colunas inteiras se elas não forem relevantes para um projeto específico.

Você pode acompanhar quem solicitou a história, quaisquer dependências ou até mesmo algumas metas de testes de aceitação de alto nível.

Pode fazer sentido acompanhar uma coluna de prioridades para cada parte interessada em alguns casos, a fim de lançar luz sobre o feedback conflitante do proprietário da empresa. Talvez você possa optar por renunciar “risco” em favor do rastreamento “Viabilidade”.

Você está limitado apenas pela sua própria capacidade de adaptar o modelo às suas necessidades dentro do contexto de seu projeto ou produto.

Relatório em uma única página com todas as sprints

Muitas pessoas adoram itens visuais, a gerência, em particular, tende a gostar de ver as informações rapidamente num formato que possa ser facilmente digerido.

As ferramentas gráficas do Google, embora não sejam as ferramentas gráficas mais robustas existentes, fornecem algumas interfaces fáceis de usar para agregar e converter dados tabulares em uma variedade de diferentes formatos visuais.

No Scrum OnePage eu uso os gráficos abaixo como um “este projeto parece estar em equilíbrio”. O objetivo aqui não é registrar, de forma definitiva, a análise científica, o objetivo é criar uma interface visualmente bem tratada que possa ajudar a identificar possíveis sinais de alerta antecipadamente.

Por exemplo, se um projeto mostrar uma alta porcentagem de histórias que são histórias estratégicas de alto risco, convém reavaliar as metas e os recursos do projeto para distribuir melhor as histórias de alto risco em um período de tempo maior para aumentar a probabilidade de lançamentos bem sucedidos.

É claro que essa pode ser a natureza do projeto e a prioridade determina que todas essas histórias de alto risco sejam concluídas. Isso pode influenciar ajustes na equipe de entrega, ênfase adicional em testes ou ajustes no cronograma antecipado podem precisar ser negociados.

Isso significa simplesmente que você leva esse conhecimento para a frente ao planejar e fazer as reduções informadas, conforme necessário.

O Scrum OnePage foi uma coletânea de itens e planilhas que foram compiladas num único item e que você pode fazer download aqui.

Comentários

Deixe uma resposta

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