Diseñadores UX trabajando un Sprint por delante

Nuestros diseñadores de UX generalmente tienen una historia en Sprint X que los desarrolladores implementarán en Sprint X + 1 (los diseñadores de UX y los desarrolladores / evaluadores están en un solo equipo). Creo que esto tiene sentido porque si no tienes maquetas de pantalla y especificaciones claras, realmente no puedes estimar el trabajo durante la planificación de Sprint.

Sin embargo, en Scrum solo se supone que tiene historias de usuario que proporcionan valor al usuario. En nuestro caso, las historias de diseño de UX no proporcionan ese valor (son más como una actividad de preparación de pedidos pendientes). Por lo general, los entrenadores Scrum no recomiendan tener especificaciones completas antes del inicio del Sprint, una recomendación que me resulta difícil de entender.

Entonces, ¿ve alguna desventaja en nuestro enfoque? Parece funcionar para nosotros, pero va en contra de los principios de Scrum.

Sin embargo, en Scrum solo se supone que tiene historias de usuario que proporcionan valor al usuario.

El valor no se mide solo en líneas de código enviable.

Parece estar insinuando que tener una interfaz de usuario bien diseñada no proporciona ningún valor. Claro que lo hace. Obviamente, hay valor para el usuario final, pero también hay valor para su equipo de desarrollo, que es una parte interesada perfectamente válida. Si no tiene las herramientas y los materiales para hacer su trabajo, no puede entregar valor al usuario final.

No te obsesiones con el dogma scrum. Scrum está ahí para hacerte más eficiente. Si hacer una historia de UX un sprint antes de implementar la interfaz de usuario te ayuda a entregar un mejor software, hazlo.

Las principales desventajas son estas:

1. Estás tramando: si tus diseñadores llegan tarde, tus desarrolladores se quedan sin trabajo; Si sus desarrolladores llegan tarde, su diseñador eventualmente trabajará más de una iteración por adelantado. No es una situación estable, no es sostenible .

2. Sus diseñadores están trabajando por adelantado, usted está pagando costos por historias que pueden o no ser desarrolladas. Incluso si sucede raramente, todavía está tirando dinero.

3. Sus diseñadores UX están tomando decisiones por adelantado sin involucrar a los desarrolladores. Le faltan ideas útiles y aumenta el riesgo de que los diseños sean totalmente erróneos o poco realistas. Esto es bastante común porque el diseño de UX no es un ejercicio "abstracto": debe elaborarse a partir de las características de la aplicación (incluido lo que es factible / aconsejable hacer o no técnicamente)

4. Excluir o desautorizar a sus desarrolladores no es una forma sostenible de ejecutar un proyecto.

5. Los diseñadores no están entregando valor: esto significa que es difícil, si no imposible, priorizar su trabajo correctamente. Por lo general, el trabajo del desarrollador se prioriza utilizando diferentes preocupaciones, valor, factibilidad en el próximo sprint, cantidad de esfuerzo. Se negocian y cambian muchas historias de tiempo para hacerlas "adecuadas" o debido a una discusión útil: si algo de esto cambia la IU (y puede suponer que lo hace si no es un simple detalle de implementación), ¿qué hace? con la historia? Ya no puedes jugarlo.

6. Supone que una historia que puede encajar en una iteración para los diseñadores encaja en una iteración para los desarrolladores: ¿cómo puede dividir las historias para que esta suposición sea correcta?

Me gusta por dos razones:

1. parece funcionar para ti; ¡Es difícil discutir con éxito!
2. el equipo de UX toma la historia y comienza la conversación temprano , y las conversaciones son una especie de punto de las historias

Un requisito básico de Scrum es que el equipo de scrum tenga todas las habilidades necesarias para crear un producto potencialmente liberable. En la situación que describe, esto no está sucediendo.

El equipo UX no está produciendo productos potencialmente liberables y el equipo scrum no es capaz de producir cortes verticales de funcionalidad, ya que no tienen todas las habilidades requeridas. Estas son disfunciones.

Sklivvz ha escrito una excelente publicación sobre los problemas a los que podrían conducir las disfunciones anteriores. En resumen, no creo que estés practicando Scrum.

Pero no hay absolutamente nada de malo en eso. Si ha descubierto una forma de trabajar que ofrece valor para todos, y está contento con eso, continúe haciéndolo. Mi único consejo sería inspeccionar y adaptar con frecuencia.

Sin embargo, tenga en cuenta que si su objetivo es entregar software utilizando Scrum, deberá abordar las disfunciones identificadas.

Aquí hay dos problemas, uno sobre el diseño centrado en el usuario y el otro sobre la alineación de sprint.

Primero : las historias de los usuarios deben estar alineadas con las necesidades de los usuarios, no solo con el retraso. Las historias UX deben tener un valor claro para los usuarios. Esto no requiere una especificación completa y una breve declaración como,

"Los usuarios tendrán un acceso más fácil a la actividad de la cuenta en una sola página en lugar de dividirse entre varias páginas"

es accesible y adaptable a diversas implementaciones y, sin embargo, sigue siendo claro sobre el valor para el usuario (acceso más fácil a la actividad de la cuenta).

Segundo : alineación de Sprint. UX diseña características en sprint X que los desarrolladores implementan en spring X + 1. En la práctica, esto sucede en muchas tiendas y, a veces, puede ser más parecido a la implementación en sprint X + 2 o X + 3. Con un equipo apretado y experimentado, esta configuración puede funcionar. Se vuelve desafiante si tiene un nuevo equipo o nuevos miembros que no están familiarizados con los conjuntos de habilidades, preferencias, hábitos, estilos de trabajo y tendencias de otros miembros del equipo. Si han estado trabajando juntos por menos de 6 meses, es probable que esto sea un problema.

Da un paso atrás y vuelve a evaluar. En el lado positivo, los diseñadores y desarrolladores de UX trabajan codo con codo, lo cual es una bendición. Comience asegurándose de que sus historias tengan un valor claro para los usuarios.

Uno de los posibles problemas que veo es que en Scrum el alcance del sprint N + 1 normalmente se determina justo antes de que comience. Entonces, ¿cómo puede hacer UX para las historias de sprint N + 1 en sprint N antes de saber qué historias estarán dentro del alcance? Si decides arreglar el alcance del sprint N + 1 al comienzo del sprint N, pierdes algo de flexibilidad.

Sin embargo, en Scrum solo se supone que tiene historias de usuario que proporcionan valor al usuario. En nuestro caso, las historias de diseño de UX no proporcionan ese valor (son más como una actividad de preparación de pedidos pendientes).

A mi modo de ver, están proporcionando mucho valor a sus usuarios. La cuestión es que su usuario no es el usuario final de la compañía, sino el equipo de desarrollo que implementará la función en sprint X + 1.

Te estás quedando atrapado en la religión del proceso y en el camino veo que scrum / agile se usa mal y los usuarios se etiquetan mal. Scrum no es una herramienta universal, es un medio para un fin.

Creo que su grupo ha etiquetado erróneamente quiénes son sus usuarios y están planeando para el público equivocado.

El grupo UX está utilizando scrum de la manera clásica, valor de usuario y adaptación ágil a las entradas de algunos usuarios finales mágicos. Ellos son los que tienen usuarios. Su grupo está usando mal el scrum porque simplemente está completando la mecánica para hacer que un diseño existente funcione, no se requiere nada ágil y scrum está cumpliendo el rol de seguimiento de la administración.

Es por eso que esto le parece incorrecto, en realidad no necesita ni se beneficia de scrum de ninguna manera porque está en un grupo de servicio y su trabajo fluye hacia adelante desde las personas UX que ya han hecho las partes ágiles / scrum.

No hay nada realmente malo allí, solo hay un proceso diferente en lugar de lo que le dijeron.