O Backlog do Produto e a arte da User Story

Pesquisando sobre o framework Scrum você, certamente, já deve ter lido algo do tipo: “O Backlog do Produto contém as funcionalidades do novo produto solicitadas pelos usuários” ou ainda “Os requisitos para o produto que o time está dsenvolvendo estão listados no Backlog do Produto”. Esses, caso você não saiba, são conceitos equivocados ou que podem gerar diferentes interpretações.

Segundo Mike Cohn,  user story é uma pequena e simples descrição de uma funcionalidade dita da perspectiva da pessoa que deseja a nova capacidade, usualmente um usuário ou cliente do sistema. Em outras palavras, o Backlog do Produto deve conter as necessidades dos usuários ou clientes e não as funcionalidades do sistema. Trata-se de uma mudança de paradigma quando comparado ao modelo criado pelo PMI (Project Management Intitute) para gestão de projetos. E é esse um dos papéis do Product Owner: traduzir as necessidades do cliente, através do Backlog do Produto, em uma linguagem  não-técnica compreensível por todas as pessoas envolvidas no projeto.

Para compreender melhor essa mudança de paradigma vamos exemplificar. Observe atentamente a história abaixo:

 

Vantagens do uso do template para User Story

“Como um <ator>, eu gostaria de <ação>, para <objetivo>.”

Você, caro leitor, pode estar agora se perguntando. Mas qual o motivo de usar esse template sempre que eu for escrever uma user story? Pesquisando sobre o assunto, descobri que existem duas razões principais pelas quais esse template se torna tão importante (fonte: mountaingoatsoftware.com).

Razão 1: A magia dos pronomes

Algo mágico acontece quando as exigências são colocadas na primeira pessoa. Obviamente, dizendo: “Como tal e tal, eu quero …” você pode ver como a mente da pessoa vai imediatamente imaginar seus desejos. Paul McCartney foi entrevistado e perguntado sobre por que as canções dos Beatles foram tão incrivelmente populares. Uma de suas respostas foi que suas músicas estavam entre os primeiros a usar um monte de pronomes. Pense nisso: She Loves You, I Want to Hold Your Hand, I Saw Her Standing There, etc. Seu ponto era que essas pessoas passaram a se identificar mais de perto com as canções. Assim acontece nas user stories.

Razão 2: Estrutura a serviço do Product Owner

A estrutura do template ajuda o Product Owner a priorizar as histórias dos usuários. Se o product backlog é um amontoado de coisas como Permita controlar exceção, Permita que os usuários façam reservas, Os usuários querem ver fotos, e assim por diante, o Product Owner tem que trabalhar muito mais para entender o que o recurso é, quem se beneficia a partir dele, e qual o valor dele.

DICA

Muitas pessoas alegam que esse modelo acaba suprimindo o conteúdo da informação devido ao uso de tantos clichês. Se você também concorda com esse pensamento, sugiro que faça o seguinte. Organize seu Backlog do Produto em um tabela com o seguinte cabeçalho. “Como”, “eu gostaria”, “para”. Isso facilita o modo de leitura e compreensão das necessidades. Veja o exemplo abaixo:

Anúncios

Sobre danielettinger

Bacharel em Ciência da Computação pela Universidade Federal de Sergipe (UFS) e Pós-Graduado em Gestão de Projetos de Software pela Faculdade de Administração e Negócios de Sergipe (FANESE). É certificado CAPM® pelo PMI, ITIL® v3 Foundation pelo EXIN e COBIT® 5 Foundation pela APMG. Possui experiência de 5 anos nas áreas de Análise e Desenvolvimento de Sistemas do setor público e privado. Atualmente trabalha no Banco do Estado de Sergipe (BANESE), onde já desenvolveu atividades de análise de processos e gerenciamento de projetos no Escritório de Gerenciamento de Demandas e Projetos e Grupo de Processos, pertencentes à Área de Governança de TI. Dentre elas, destacam-se a gestão do projeto de implantação do PMO de TI e suporte no gerenciamento de projetos de TI. Nos dias de hoje, atua como gerente de projetos do PMO Corporativo do BANESE. Ministra aulas de Sistema de Gerenciamento de Projetos em cursos de MBA da FANESE. Participou como voluntário em eventos do PMI ministrando curso de Gestão do Tempo em Projetos. É proprietário e articulista do site “Gestão de Projetos Ágeis” www.danielettinger.com, onde divulga trabalhos pessoais na área de Gerenciamento de Projetos e Metodologias Ágeis como artigos, vídeo-aulas, pesquisas, eventos, templates, tutoriais e dicas fomentando o interesse e o desenvolvimento dessas áreas.

Publicado em 30/12/2010, em Metodologias Ágeis, Scrum e marcado como , , , . Adicione o link aos favoritos. 6 Comentários.

  1. Muito esclarecedor seu artigo, parabéns.

  2. Fabiano Milani

    Parabéns pelo post, realmente ilustra bem o conceito de backlog, sem contar também que representa muito bem a única coisa que o Scrum pede com relação aos requisitos que é uma boa granularidade do item para que possa facilitar ao Time seu entendimento e estimativa, nisso a User Story ajuda muito.

    Outra coisa interessante que precisamos pensar é que não é aconselhável deixar um US sem o seu “por que”, sem o “para”, pois isso ajuda ao Product Owner a encontrar o valor de negócio agregado e facilita na priorização do backlog, vejo nos projetos que trabalho resultados muito positivos nesse sentido.

    O legal é que uso o por que para subir a prioridade da US no bakclog e o “como” para baixar, porque se ele sabe o real valor de negócio que aquela US traz para o produto mas não sabe ainda “como” ele quer aquilo, muito provavelmente no Planning Meeting com o Time ele não ira conseguir definir nem explicar para o Time como ele quer aquilo funcionando no produto.

    Bom, isso não é a verdade absoluta é apenas o meu sentimento com relação aos trabalhos que realizei.

    Parabéns mais uma vez pelo post.

  3. Ótimo post! Parabéns.. =)

  1. Pingback: Planejando o Release – 1a. Parte |

  2. Pingback: A engrenagem do Scrum « Blog GPA – Daniel Ettinger

  3. Pingback: Como construir um Product Backlog efetivo | Gestão de Projetos Ágeis

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s