Designers de UX trabalhando um Sprint à frente

Nossos designers de UX geralmente têm uma história no Sprint X que os desenvolvedores implementarão no Sprint X + 1 (os designers de UX e os desenvolvedores / testadores estão em uma equipe). Acho que isso faz sentido, porque se você não possui modelos de tela e especificações claras, não pode realmente estimar o trabalho durante o Sprint Planning.

No entanto, no Scrum, você deve ter apenas histórias de usuários que forneçam valor ao usuário. No nosso caso, as histórias de design do UX não fornecem esse valor (são mais como uma atividade de preparação de pedidos em atraso). Geralmente, os treinadores do Scrum não recomendam ter especificações completas antes do início do Sprint, uma recomendação que acho difícil de entender.

Você vê alguma desvantagem em nossa abordagem? Parece funcionar para nós, mas é um pouco contrário aos princípios do Scrum.

No entanto, no Scrum, você deve ter apenas histórias de usuários que forneçam valor ao usuário.

O valor não é medido apenas em linhas de código entregável.

Você parece estar implicando que ter uma interface do usuário bem projetada não fornece nenhum valor. Claro que sim. Obviamente, há valor para o usuário final, mas também há valor para sua equipe de desenvolvimento, que é uma parte interessada perfeitamente válida. Se você não possui as ferramentas e os materiais para fazer seu trabalho, não pode agregar valor ao usuário final.

Não se desligue do dogma do scrum. O Scrum está lá para torná-lo mais eficiente. Se criar uma história de UX, um sprint antes de implementar a interface do usuário ajuda a fornecer um software melhor, faça-o.

As principais desvantagens são estas:

1. Você está envolvido: se seus designers estão atrasados, seus desenvolvedores ficam sem trabalho; se seus desenvolvedores estão atrasados, seu designer acabará trabalhando com mais de uma iteração com antecedência. Não é uma situação estável - não é sustentável .

2. Seus designers estão trabalhando antecipadamente, e você está pagando custos pelas histórias que podem ou não ser desenvolvidas. Mesmo que isso aconteça raramente, você ainda está jogando dinheiro fora.

3. Seus designers de UX estão tomando decisões antecipadamente sem envolver os desenvolvedores. Você está perdendo informações úteis e aumentando o risco de que os projetos sejam totalmente errados ou irreais. Isso é bastante comum porque o design do UX não é um exercício "abstrato" - ele deve ser criado com as características do aplicativo (incluindo o que é viável / aconselhável fazer ou não tecnicamente)

4. Excluir ou desativar seus desenvolvedores não é uma maneira sustentável de executar um projeto.

5. Os designers não estão agregando valor: isso significa que é difícil, se não impossível, priorizar seu trabalho corretamente. Geralmente, o trabalho do desenvolvedor é priorizado usando diferentes preocupações, valor, viabilidade no próximo sprint, quantidade de esforço. Muitas histórias de tempo são negociadas e alteradas para torná-las "adequadas" ou por causa de discussões úteis: se algo disso altera a interface do usuário (e você pode presumir que sim, se não for um mero detalhe de implementação), o que você faz com a história? Você não pode mais jogar.

6. Você está assumindo que uma história que pode caber em uma iteração para os designers se encaixa em uma iteração para os desenvolvedores: como você pode dividir as histórias para que essa suposição esteja correta?

Eu gosto disso, por duas razões:

1. parece funcionar para você; é difícil argumentar com sucesso!
2. a equipe de UX pega a história e inicia a conversa mais cedo - e as conversas são o ponto principal das histórias

Um requisito básico do Scrum é que a equipe do scrum possua todas as habilidades necessárias para criar um produto potencialmente liberável. Na situação que você descreve, isso não está acontecendo.

A equipe de UX não está produzindo produtos potencialmente liberáveis ​​e a equipe de scrum não é capaz de produzir fatias verticais de funcionalidade, pois não possuem todas as habilidades necessárias. Estas são disfunções.

Sklivvz escreveu um excelente post sobre os problemas que as disfunções acima podem levar. Em resumo, não acho que você esteja praticando Scrum.

Mas não há absolutamente nada de errado nisso. Se você descobriu uma maneira de trabalhar que agrega valor a todos e está feliz com isso, continue fazendo isso. Meu único conselho seria inspecionar e adaptar com frequência.

Observe, no entanto, que se seu objetivo é fornecer software usando o Scrum, você precisará solucionar as disfunções identificadas.

Há dois problemas aqui, um sobre o design centrado no usuário e o outro sobre o alinhamento do sprint.

Primeiro : as histórias do usuário devem estar alinhadas às necessidades do usuário, não apenas à lista de pendências. As histórias de UX precisam ter um valor claro para os usuários. Isso não requer especificação completa e uma declaração curta como,

"Os usuários terão acesso mais fácil à atividade da conta em uma única página, em vez de divididos entre várias páginas"

é acessível e adaptável a várias implementações e ainda é claro sobre o valor para o usuário (acesso mais fácil à atividade da conta).

Segundo : alinhamento da sprint. O UX cria recursos no sprint X que os desenvolvedores implementam na primavera X + 1. Na prática, isso acontece em muitas lojas e, às vezes, pode ser mais parecido com a implementação no sprint X + 2 ou X + 3. Com uma equipe forte e experiente, essa configuração pode funcionar. Torna-se desafiador se você tiver uma nova equipe ou novos membros que não estejam familiarizados com os conjuntos de habilidades, preferências, hábitos, estilos de trabalho e tendências de outros membros da equipe. Se você trabalha em conjunto há menos de 6 meses, é provável que isso seja um problema.

Dê um passo para trás e reavalie. No lado positivo, você tem os designers e desenvolvedores de UX trabalhando lado a lado, o que é um benefício. Comece certificando-se de que suas histórias tenham um valor claro para os usuários.

Um dos possíveis problemas que vejo é que, no Scrum, o escopo do sprint N + 1 é normalmente determinado logo antes do início. Então, como você pode fazer UX para histórias de sprint N + 1 no sprint N antes de saber quais histórias estarão no escopo. Se você decidir fixar o escopo do sprint N + 1 no início do sprint N, perderá alguma flexibilidade.

No entanto, no Scrum, você deve ter apenas histórias de usuários que forneçam valor ao usuário. No nosso caso, as histórias de design do UX não fornecem esse valor (são mais como uma atividade de preparação de pedidos em atraso).

Do meu ponto de vista, eles estão fornecendo muito valor ao usuário. A questão é: o usuário não é o usuário final da empresa, ele é a equipe de desenvolvimento que implementará o recurso no sprint X + 1.

Você está ficando preso na religião do processo e, ao longo do caminho, vejo scrum / ágil sendo mal utilizado e usuários rotulados incorretamente. O Scrum não é uma ferramenta universal, é um meio para atingir um fim.

Eu acho que seu grupo classificou incorretamente quem são seus usuários e está planejando para o público errado.

O grupo UX está usando o scrum da maneira clássica, valor do usuário e adaptação ágil às entradas de alguns usuários finais mágicos. Eles são os únicos com os usuários. Seu grupo está usando mal o scrum porque você está apenas preenchendo a mecânica para fazer um design existente funcionar, não há nada ágil necessário e o scrum está desempenhando o papel de rastreamento de gerenciamento.

É por isso que isso parece errado para você, você não precisa nem se beneficia do scrum de nenhuma maneira, porque você está em um grupo de serviços e seu trabalho flui adiante das pessoas do UX que já fizeram as partes ágeis / scrum.

Nada de muito ruim por lá, apenas um processo diferente do que lhe foi dito.