você está aqui: Home  → Arquivo de Mensagens

Scrum: Integrando a experiência do usuário no Product Backlog

Por Cesar Brod

Data de Publicação: 22 de Dezembro de 2015

Este é um artigo de 2012. Ainda hoje, algumas pessoas dizem que o Scrum não leva em conta a experiência do usuário (UX). Na verdade, o Scrum não é uma prescrição sobre como todas as coisas devem ser feitas, mas um framework de atitudes com papéis, ritos (incluindo ritmos) e artefatos muito bem definidos, dentro do qual qualquer coisa pode ser feita. O texto a seguir, que traduzo com a permissão do autor, Jon Innes, apresenta a Matriz de Integração da Experiência do Usuário, explicitando seu uso em conjunto com um típico product backlog.

A tradução é o mais literal possível, o que não significa que concordo, integralmente, com o texto original. Não concordo, por exemplo, que a pontuação das histórias deva separar o desenvolvimento das questões de UX. A equipe Scrum é multidisciplinar e deve considerar tudo o que é necessário para dar uma história por completa ao pontuar seu esforço de desenvolvimento. Por outro lado, para equipes novas e não acostumadas a considerar questões de UX, a receita proposta pelo autor é bastante útil, assim como as muitas dicas que ele dá em todo o artigo.

Esta tradução foi motivada por conversas com o amigo Kenner Kliemann, do CELTAB, onde tive a honra de facilitar oficinas de Scrum.

O texto original pode ser acessado aqui.

A Matriz de Integração da Experiência do Usuário

As equipes que migram para métodos ágeis lutam, com frequência, para integrar tais métodos com as melhores práticas de design centrado no usuário (UCD - User Centered Design) e experiência de usuário (UX - User Experience) em geral. Felizmente, o uso de uma matriz de integração de experiência de usuário auxilia na integração de UX e agilidade ao incluir informações e requisitos de UX diretamente no product backlog.

Ainda que os métodos ágeis e de UX compartilhem algumas boas práticas -- como a iteração e a definição de requisitos baseados em histórias sobre usuários --, esses métodos evoluíram a partir de propósitos diversos, servindo de base a valores distintos. Os métodos ágeis foram desenvolvidos sem considerar as melhores práticas de UX. Os pioneiros dos métodos ágeis estavam trabalhando em projetos internos de TI (software customizado) ou softwares empresariais 1,.

Há diferenças entre a venda de produtos ao consumidor final e o desenvolvimento de software empresarial -- UX é mais importante em produtos para o consumidor. Para o Jeff Bezos, é muito mais importante a forma pela qual o usuário clica o botão que coloca dinheiro em seu bolso do que para o Larry Ellison, que pouco se importa com qualquer botão no Oracle. O Larry ganha dinheiro mesmo que as pessoas não possam usar o seu software. A Oracle vende contratos de suporte e serviços profissionais para consertar as coisas que seus clientes não gostam. A Amazon e outros negócios online não podem operar da mesma forma. Eles tem que cuidar bem da UX, ou rapidamente irão à falência. Os fatores de experiênca de usuário raramente recebem o mesmo nível de consideração quando o usuário final não é a mesma pessoa que o cliente pagante [3].

Equipes ágeis e problemas de UX

Encontrei dois problemas comuns entre especialistas em métodos ágeis ao ajudá-los a melhorar a experiência de usuários de seus produtos e serviços:

  1. o trabalho de UX é, com frequência, negligenciado durante os esforços de planejamento de versões e sprints;
  2. as equipes, tipicamente, falham em medir o impacto de UX em seus esforços iterativos.

Esses dois problemas tornam-se mais sérios quando acontecem ao mesmo tempo.

Quando o trabalho de UX não é feito e seu impacto não é medido, a equipe que realiza o trabalho não tem ideia do que está acontecendo. O ciclo de feedback é quebrado. Tanto os métodos ágeis quanto de UX enfatizam a iteração, mas uma iteração produtiva requer bons ciclos de feedback.

Você pode conduzir iterações de desenvolvimento (o foco dos métodos ágeis) ou iterações de design (o foco de UX) mas, ao segmentar assim, você não verá o real benefício de um processo iterativo. Você não terá a ideia exata se o que está oferecendo aproxima-se da atenção às necessidades do usuário final. A Matriz de Integração da Experiência do Usuário (UXI Matrix) aborda essa questão ao unir UX ao backlog do projeto.

Integrando UX no product backlog

O Scrum (uma das variantes mais populares de métodos ágeis) defende a criação de um Product Backlog, uma coleção de histórias que descreve o que o usuário precisa. A equipe, iterativamente, refina os requisitos, de grosseiros (ou mesmo mal definidos) para mais específicos. Isto é feito ao se usar histórias que nascem da perspectiva do usuário, que tem condições de satisfação associadas a elas. Esse conceito é adaptado de um cenário de UCD, baseado em métodos de modelagem. Na minha visão, esse método é muito melhor do que as abordagens de documentação de requisitos que, frequentemente, estão desconectadas dos objetivos dos usuários.

Vários especialistas em métodos ágeis 4, discutem a quebra de requisitos a partir de histórias de alto nível para necessidades que atendem a usuários específicos. Se sua equipe segue o método de mapeamento de histórias proposto por Jeff Patton [6], que enfaticamente recomendo, para criar representações hierárquicas estruturadas, você tipicamente desejará analisar as histórias de acordo com diferentes fatores na medida em que refina seu backlog.

Trabalhei com equipes que desejavam analisar suas histórias das seguintes formas:

  1. ordem de dependência ou fluxo de trabalho (a possibilidade da troca de senha depende do registro do usuário);
  2. criticalidade (quais dessas histórias devem ser atendidas para que os usuários nos paguem no próximo mês);
  3. quanto trabalho será feito até que o projeto esteja completo (mostre-me todos os épicos);
  4. quais histórias relacionam-se com UX (encontre os requisitos relativos à interface com o usuário);
  5. por papel ou persona (mostre-me todas as histórias que impactam a persona X);
  6. quais histórias tem maior impacto em UX, assim podemos nos focar nelas?

Se o projeto é pequeno (considerando tanto o número de membros da equipe quanto o número de histórias) você será capaz de tocá-lo rearranjando os cartões de histórias na parede. Entretanto, levando em conta minha experiência, as coisas tornam-se, inevitavelmente, mais complexas. Você, tipicamente, desejará considerar múltiplos fatores enquanto revisa o backlog. Uma matriz de integração de UX irá ajudá-lo a visualizar e acompanhar esses múltiplos fatores.

Criando a matriz de integração de UX

A matriz UXI (Integração de Experiência de Usuário) é uma ferramenta simples e flexível, que estende o conceito do product backlog de forma a incluir nele os fatores de UX que normalmente não são rastreados por equipes ágeis. Para criar a matriz UXI você adiciona vários dados relativos a UX em suas histórias de usuário:

Nome Valores possíveis Descrição
Persona Nome da persona Identifica a persona à qual se aplica uma história de usuário
Complexidade UX 1 a 5 (ou os pontos de história da sequência de Fibonacci) Estima o esforço de design, à parte do esforço de implementação
História validada? Sim/Não Esta história é fato ou ficção? Ela está baseada em pesquisa com o usuário ou entrevista com o cliente?
Design completo? Sim/Não O design está devidamente pronto para ser desenvolvido, codificado (a estimativa de codificação foi feita?)
Taxa de realização da tarefa 0 a 100% O percentual de usuários que foram capazes de testar a história sem nenhum tipo de ajuda
Equipe Nome do recurso Quem é o responsável pelo design, independente do grau de fidelidade acordado

Com estas colunas adicionadas, seu product backlog começa a se parecer com a planilha exibida na figura a seguir.

Matriz de integração de UX, um exemplo simplificado

Vantagens de uso da Matriz UXI

A matriz UXI auxilia as equipes na integração das melhores práticas de UX e design centrado no usuário ao inserir a UX em todos os níveis do processo ágil.

Refinamento do backlog

Durante o planejamento de versões e dos sprints, você pode organizar, agrupar e filtrar as histórias de usuário na planilha:

  • Agrupar por temas ou épicos ou tudo o mais que você quiser adicionar em novas colunas
  • Uma persona principal, um conjunto de personas ou um número de pessoas associadas
  • Histórias que você já verificou em pesquisa com o usuário ou aquelas que ainda carecem de verificação
  • Histórias que foram completadas, mas que precisam de refinamento baseado em métricas
  • As histórias podem ser exportadas em um formato que pode ser usado como base para a arquitetura do sistema
  • Podem ser inseridos hiperlinks para todos os entregáveis de UX, como personas, mockups e resultados de pesquisa

Observe as linhas de sumário perto da base do exemplo na figura acima. Esses valores podem ajudá-lo a priorizar histórias novas e existentes, com base em vários fatores de UX.

Redução da sobrecarga de design

Minha experiência pode não ser muito usual, mas mesmo quando trabalhei com equipes pequenas, de sete pessoas, ainda tínhamos problemas para identificar histórias ou personas redundantes. Minha heurística é a de que, se uma história compartilha várias personas com outra história em um sistema multi-usuário, então essa história pode ser uma duplicata. O agrupamento por temas também ajuda aqui.

Outra heurística útil é a de que, se uma persona compartilha uma grande lista de histórias de usuário com outra persona, pode ser possível unificar essas personas. Na maior porte do tempo, as personas que fazem exatamente as mesmas coisas com o produto podem usar o mesmo design, a não ser, é claro, que elas tenham habilidades ou alguma outra característica que as diferencia, o que é evidenciado na revisão das personas ou através de pesquisa com os usuários (na qual, no meu ponto de vista, todas as boas personas devem estar baseadas).

Facilitação da colaboração

A matriz de integração UX ajuda as equipes na integração de melhores práticas de UX e design centrado no usuário ao inserir a UX em todos os níveis do processo ágil.

Outro grande benefício do formato da matriz UX é que você pode compartilhá-la com membros remotos da equipe.

A listagem das pessoas torna visível o que cada uma está fazendo (ver as colunas sobre o cabeçalho Staffing). Os membros da equipe podem descobrir quem está trabalhando em histórias relacionadas e verificar o que está completo, especialmente se você criar um hiperlink para o design ou materiais de pesquisa diretamente na matriz.

Por exemplo, se houver um Y na coluna Design Complete, você pode clicar no hiperlink do Y para revisar o design do mockup. Trabalhei com equipes que gostavam de rastrear os estados da revisão na matriz: trabalho em andamento (WIP - Work in Progress), rascunho (D - Draft), revisado (R - reviwed), etc, no lugar de simplesmente Y ou N.

Acompanhamento do envolvimento do usuário e outras métricas de UX

A matriz de integração UX também ajuda a acompanhar e compartilhar métricas de UX. Uma métrica chave a ser acompanhada é o contato real da equipe com os usuários finais. Por exemplo, se você conversou com usuários de verdade para validar uma persona, quantos você contatou? Outra boa métrica é o número de usuários envolvidos no teste e design (via testes de usabilidade, A/B ou outros).

Você também pode capturar métricas objetivas e quantitativas de UX, como taxas de finalização de tarefas, de conversão de clicsk e de satisfação por persona. Isto facilita o convencimento da equipe na revisão de designs anteriores, onde as métricas evidenciaram que os usuários não conseguiram usar um design proposto ou mostraram-se insatisfeitos com o atual produto ou serviço. Pode ser útil, também, acompanhar o nível de satisfação por história de usuário (ou estados específicos de história para testes multivariados) em uma coluna próxima à história.

Revisão de métricas de UX durante as retrospectivas de sprint

Revisões e retrospectivas no estilo Scrum são críticas na melhoria do design e do desempenho da equipe. Ainda assim, poucas equipes consideram métricas de UX como parte da retrospectiva. Durante essas reuniões, é útil ter as métricas de UX próximas às histórias durante a revisão com a equipe.

Eu faço as seguintes perguntas relativas à UX, para a equipe, durante a retrospectiva:

  1. Atingimos nossos objetivos de UX para o sprint?
    1. Nossa pesquisa com os usuários mostra que construímos algo útil e amigável?
    2. Os usuários estão satisfeitos com as novas funcionalidades (novas histórias)?
    3. Os usuários terão vontade de promover nosso produto ou serviço para outros?
    4. Temos métricas de uso do produto (via análise do site) que atendam nossas expectativas?
  2. Há funcionalidades (histórias) existentes que exijam refinamento, antes de adicionarmos outras funcionalidades?
  3. Que tipo de pesquisa com usuários devemos conduzir a fim de priorizar novas histórias?
  4. Temos membros suficientes com experiência em UX para atingir nossos objetivos?
  5. Ao seguir adiante, devemos:
    1. garantir que nos antecipamos ao próximo sprint para validar premissas de UX?
    2. fazer um protótipo rápido para refinar uma parte crítica de UX?
    3. refinar o foco do trabalho em UX em histórias ou personas selecionadas?
    4. melhorar nossos mecanismos de feedback a fim de capturar fatores que faltam hoje?

A Matriz de Integração UX insere atividades chave de experiência de usuário e contexto adjacente a histórias de usuário no product backlog.

Aprimorando as decisões de design de sua equipe

Uma vez que você começa a acompanhar a Matriz de Integração UX, torna-se mais fácil a condução de discussões informadas durante as revisões e retrospectivas. Eu uso a matriz UXI para definir objetivos de UX com a equipe, para ajudar na priorização de histórias no backlog, acompanhar o progresso do trabalho de UX e para ajudar a responder ao problema clássico em métodos ágeis: o que significa pronto? -- não apenas para todo o produto ou serviço, mas para histórias individuais.

Estou curioso para ouvir de outros que gostariam de compartilhar suas experiências com variações do método aqui proposto, ou outros similares. Por outro lado, se você for um agilista e pensa que tudo o que propus aqui é pouco ágil, eu pergunto: você pode provar, de fato, que seu método cria uma melhor UX sem tudo isso?

Um template para a Matriz de Integração UX está disponível aqui.

  1. Larman, Craig. Agile and Iterative Development: A Manager's Guide. Pearson Education, 2004.
  2. Sutherland, Jeff. "Agile Development: Lessons learned from the first scrum". Cutter Agile Project Management Advisory Service, Executive Update, Vol. 5, No. 20, 2004: http://www.scrumalliance.org/resources/35.
  3. Cagan, Martin. Inspired: How To Create Products Customers Love. SVPG Press, 2010.
  4. Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley Professional, 2004.
  5. Cockburn, Alistair. Agile Software Development. Addison-Wesley Professional, 2001.
  6. Patton, Jeff; "It's All In How You Slice It", Better Software, January 2005: http://www.agileproductdesign.com/writing/how_you_slice_it.pdf.

Sobre o autor

Cesar Brod é empresário e consultor nos temas de inovação tecnológica, tecnologias livres, dados abertos e empreendedorismo. Sua empresa, a BrodTec, faz também trabalhos tradução e produção de conteúdo em inglês e português. Além de sua coluna, Cesar também contribui com dicas para o Dicas-L e mantém um blog com aleatoriedades e ousadias literárias. Você pode entrar em contato com ele através do formulário na página da BrodTec, onde você pode saber mais sobre os projetos da empresa.

Mais sobre o Cesar Brod: [ Linkedin ] | [ Twitter ] | [ Tumblr ].


Para se manter atualizado sobre as novidades desta coluna, consulte sempre o newsfeed RSS

Para saber mais sobre RSS, leia o artigo O Padrão RSS - A luz no fim do túnel.

Recomende este artigo nas redes sociais

 

 

Veja a relação completa dos artigos de Cesar Brod