Nuestro equipo scrum consta de los roles habituales de scrum. No tenemos un diseñador de UI / UX y los desarrolladores trabajan la UI / UX con el propietario del producto. Aquí yace un problema. Cada vez que estamos a punto de crear el trabajo atrasado y no definimos el diseño exacto de UI / UX antes del comienzo del sprint, terminamos pasando demasiado tiempo durante el sprint tratando de finalizar el diseño de UI / UX.

Esto es exactamente cierto para el análisis y la arquitectura de las características. ¿Crees que todos los detalles posibles sobre una característica deberían darse a los desarrolladores antes del inicio del sprint o debería ser una tarea dentro de las características? Hemos experimentado con esto y da como resultado algunas características indefinidas que no tienen ningún criterio.

Primero: eche un vistazo a esta agradable charla , Florian Haas dio en el FROSCON (GER). Se trata de la imposibilidad práctica de hacer scrum en absoluto.

La buena noticia : dado que el scrum es imposible de implementar, eres libre de hacer lo que quieras.

La mala noticia : no llames a ese scrum.

Eso te libera de la pregunta: "¿Estoy haciendo scrum bien?" (Respuesta: No, no lo haces ) y podrías pasar a las preguntas prácticas de la vida, en realidad.

No tenemos un diseñador de UI / UX y los desarrolladores trabajan la UI / UX con el propietario del producto

Esta no es una situación poco común. Pero AFAIR scrum está en contra de la especialización: todos deberían tener el mismo conjunto de habilidades y podrían trabajar indistintamente.

Cada vez que estamos a punto de crear el trabajo atrasado y no definimos el diseño exacto de UI / UX antes del comienzo de la primavera, terminamos pasando demasiado tiempo durante el sprint tratando de finalizar el diseño de UI / UX.

Sí, ahora esa situación es demasiado buena. Trabajé en un equipo, donde tuvimos que lidiar con elementos de trabajo muy amplios como "Como usuario, quiero ver información x " y eso fue todo. Luego el artículo aterrizó en el tablero de sprint. Un desarrollador lo tomó. Resuelto. Después de implementarlo, se realizó una primera revisión por pares, donde comenzó la discusión sobre cómo debería ser la IU.

Luego llegó la fase de control de calidad y la discusión comenzó de nuevo.

Después del sprint, hicimos lo que el scrum exige la revisión donde el diseño fue desgarrado por el PO . Desafortunadamente, nuestro cliente no llegó a las revisiones, por lo que no vio el software en ese momento.

Pero luego el ciclo comenzó de nuevo hasta que PO estuvo satisfecho.

Y luego vino el cliente ...

Como puede ver en esta historia de guerra , este (tipo especial) de proceso es infernalmente ineficaz.

Lo que funcionó para nosotros al final fue arrojar scrum por la borda.

Pero esa no es la solución a tu pregunta;)

¿Crees que todos los detalles posibles sobre una característica deberían darse a los desarrolladores antes del inicio del sprint o debería ser una tarea dentro de las características?

Una solución a este dilema implicaría lazos de retroalimentación ajustados entre a) el cliente mismo y la OP , de modo que los criterios estén formulados de manera relativamente estricta. b) Un circuito de retroalimentación ajustado entre scrum-team y PO para minimizar la posibilidad de conducir fuera de la carretera.

Rompería algunas (más) reglas de scrum para definir un elemento de backlog: un »dummy de trabajo«. Lo cual podría ser revisado rápidamente por el PO y el cliente para minimizar el tiempo de desarrollo gastado en un artículo simple.

tl; dr

¿Cuál debería ser la aportación de un equipo scrum?

Suficiente información para cumplir con las especificaciones en el menor tiempo posible.

Fuera de contexto:

Ya no hacemos scrum. No hacemos estimaciones. Guardamos la tabla de sprint. No hacemos sprints. Desarrollamos características / corregimos errores y lanzamos lo antes posible. Cuando se implementan nuevas funciones, pasan lo antes posible a un servidor público donde podríamos discutir el diseño posterior con los clientes lo más estricto posible.

La respuesta canónica es "haz lo que funcione para ti".

Scrum es una de las metodologías ágiles. Está diseñado explícitamente para cambiar y adaptarse a su equipo y su proyecto. Tu enfoque debe ser:

Individuos e interacciones sobre procesos y herramientas
Software de trabajo sobre documentación integral
Colaboración del cliente sobre negociación de contratos
Responder al cambio sobre seguir un plan ( manifiesto ágil )

No se trata de lo que su equipo debería tener para comenzar en una historia, se trata de qué información le permite a su equipo particular resolver la necesidad comercial particular.

En mi experiencia personal, depende del objetivo comercial. Algunas historias ya vienen con investigación UI / UX y diseños completos, y eso está bien. Algunas historias tienen requisitos vagos, porque el negocio solo necesita resolver un problema. Eso también está bien.

También hay otros factores, por supuesto. Por ejemplo, si sus diseñadores son parte del equipo de desarrollo, marketing o desarrollo de productos, etc. Numerosos factores. Simplemente haga lo que sea necesario para satisfacer el negocio, sea flexible y asegúrese de discutir estas cosas durante sus retrospectivas, ajustando el proceso según sea necesario.

He tenido un retroceso similar de los desarrolladores. El problema desde su punto de vista era que desconfiaban de cuánto tiempo podría tomar la parte UX para implementar. Si aceptan intentar entregar N historias en un sprint, pero algunas de las historias tardan mucho más de lo esperado debido a ir y venir en UX, entonces sentían que se reflejaba mal en ellas.

Lo que ha funcionado para nosotros es:

1. Alguien trabaja con el propietario del producto para crear maquetas de las pantallas que se desarrollarán. Estos se revisan durante el proceso habitual de refinamiento de la historia antes de que la historia entre en un sprint que les da a todos la oportunidad de tener una discusión honesta.
2. No intente finalizar el diseño antes de codificarlo, solo hágalo salir y luego hable sobre lo que necesita cambiar. Los costos de realizar el cambio son más claros, lo que ayuda al propietario / cliente del producto a decidir si vale la pena.
3. Confianza entre el propietario del producto / clientes y los desarrolladores. Al final, todos intentan entregarle cosas al cliente. El PO no puede gemir porque el equipo no entrega todo desde un sprint. Los desarrolladores no pueden ser deliberadamente obstructivos porque están preocupados por no cumplir.
4. Práctica. Acabamos de mejorar las estimaciones de los tamaños de las historias y poder detectar posibles problemas.

Tl; DR: no defina completamente el UX antes de la codificación. Espere hasta que los usuarios lo vean y jueguen con él.

¿Crees que todos los detalles posibles sobre una característica deberían darse a los desarrolladores antes del inicio del sprint o debería ser una tarea dentro de las características?

En pocas palabras, si el propietario del producto no puede entregar el diseño ui / ux antes del sprint, el desarrollo de ui / ux debería ser una historia , no una tarea.

Sus entregas de sprint no siempre tienen que ser un código de trabajo, y el equipo en sí puede ser el "quién" en la historia. Puede tener una historia como "Como miembro del equipo de desarrollo, necesitamos maquetas de UI para poder implementar la UI". Luego estima cuánto tiempo le tomará a su equipo entregar las maquetas, y esa se convierte en una de las primeras historias en las que trabaja.

No tiene que deletrear la interfaz de usuario, solo acepte la solicitud funcional (historia) y califíquela sabiendo que tiene que pensar en una interfaz de usuario. Hacer que el cliente especifique la IU está pidiendo problemas.

Ahora que sabe que la interfaz de usuario le costará algo de tiempo, debería poder planificar mejor. La próxima vez que realice una tarea que incluya trabajo de interfaz de usuario, le asignará algunos puntos de historia adicionales.

Si eres scrum, cualquiera puede ser un diseñador de UI / UX.

La UI / UX no debería ser una ocurrencia tardía. Debería ser un entregable. Debe ser aprobado por el propietario de su producto. Debería aparecer, incluso solo como un gif, al entregar.

Eso no significa que no pueda cambiar. Es algo que cambiará a menudo. También es algo sobre lo que desea retroalimentación temprana. No permita que el código controle el diseño de la interfaz de usuario. Deje que el cliente lo conduzca. Empuje hacia atrás solo cuando el cliente esté pidiendo magia. De lo contrario, solo hágales saber la cantidad de trabajo que están pidiendo y cuánto costará.

La única UI / UX finalizada está en software muerto.

De tu comentario:

"Debe ser aprobado por el propietario de su producto". Aquí es exactamente donde surge el problema. Hay una gran cantidad de tiempo dedicado a este proceso de aprobación y terminamos pasando días en lugar de unas pocas horas que inicialmente se estimaron. - Rashid

Elimina todo lo que innecesariamente te frena.

Tienes una idea Dile al dueño del producto. Deberían estar sentados a tu lado.

¿Ellos lo odian? Siga adelante. ¿Quiéralo? Hazlo. No lo entiendo? Mostrarles.

Cortas reuniones frecuentes no programadas. Hablar. Doodle en una pizarra o papel. Simulacros en un programa de pintura usando capturas de pantalla. Comunique, apruebe, implemente y revise ideas rápidamente.

Si el dueño del producto no está cerca, tome un humano conveniente y pregúntele. Lo que sea necesario para comenzar a iterar. Vuelva a conectar al propietario del producto lo antes posible.

No pases ni un segundo haciéndolo bonito. Solo ve al punto. Mantenga sus ideas pequeñas e incrementales y podrá hacerlo antes de que alguien le pida un presupuesto.

En mi experiencia:

• Demasiado poco análisis inicial causa un desarrollo ineficiente y de detención e inicio
• Demasiado análisis inicial causa parálisis de análisis (el Sprint nunca comienza)

Lo que hacemos:

• Definir algunos criterios de " Listo para el desarrollo "
• Para las historias de UX, esto podría ser "tenemos una estructura metálica que el equipo entiende bien"

Durante la planificación de Sprint:

• Cualquier historia que no esté lista para el desarrollo se descarta (sería demasiado perjudicial para el equipo y volvería para un mayor análisis)
• Cualquier historia limítrofe se declara "de alto riesgo" y se lleva a cabo justo al comienzo del Sprint
• Las historias bien entendidas son estimadas y permitidas en el Sprint

Este sistema nos permite dedicar la mayor parte de cada Sprint a la ejecución, es decir, trabajamos de manera mucho más eficiente.

Cualquier tarea en su scrum debe tener una estimación del trabajo total involucrado y un resultado verificable.

Si pongo una tarea en su scrum "implementar la función X con una interfaz de usuario con la que el gerente de producto está satisfecho", eso tiene un resultado verificable, pero es claramente imposible estimar la cantidad de trabajo involucrado. Por lo tanto, esta tarea no se puede poner razonablemente en un scrum.

Ahora pongo una tarea en su scrum "diseñar una interfaz de usuario para la función X". Eso puede ser estimado, y el resultado es verificable. Esa es una tarea aceptable dentro de un scrum. Cuando la tarea está terminada, lo has hecho.

Ahora, una vez que se realiza la tarea, su gerente de producto puede decir que no le gusta el resultado. Está bien. Había una tarea en el scrum, la has hecho y ese es tu trabajo. Puede poner otra tarea en el próximo scrum. Tal vez con un poco más de dirección, qué tipo de interfaz de usuario le gustaría realmente. Ese es su trabajo. Establecer tareas que den resultados útiles . A veces es difícil, y se hace un trabajo que resulta inútil. Por eso lo llaman "ágil"; se realizan tareas que resultan inútiles y luego cambias a una mejor dirección.

Además, el diseño UX, especialmente un buen diseño UX, es un trabajo de tiempo completo para alguien que ha practicado el diseño UX. Muchos buenos desarrolladores de software pueden hacer un trabajo aceptable creando un UX, pero no lo harán tan bien y rentable como un buen diseñador de UX (si pudieran, crearían diseños de UX y no desarrollarían software). Por lo tanto, no tener un diseñador UX es ineficaz, nuevamente un problema para el propietario del producto.

No estoy seguro de que sigas principios ágiles, pero así es como se debe manejar esto.

no definimos el diseño exacto de UI / UX antes del comienzo del sprint

El objetivo no es ser perfecto en este momento. Obtenga tanta información sobre los requisitos para que los desarrolladores puedan construir algo que coincida con lo que se ha pedido lo más cerca posible. No haga muchos ajustes ni intente diseñar cosas que no se han pedido. Perderás tu tiempo.

terminamos pasando demasiado tiempo durante el sprint tratando de finalizar el diseño de UI / UX.

Trabaja en una forma de determinar cuándo se hacen las cosas. Tengo la sensación de que alguien continúa haciendo muchas evaluaciones de UI / UX. Demasiadas personas tienen opiniones sobre UX / UI sin nada del cliente que respalde sus suposiciones.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Este tipo de cosas puede continuar para siempre. No es un defecto de Scrum. Alguien se está entrometiendo con los requisitos durante el sprint. Vuelva a decidir qué quiere el cliente, determine cuánto tiempo tomará y trabaje con ellos para priorizar. Si piensan que tomará demasiado tiempo, pregúnteles de qué deshacerse.

Hay una empresa que diseña logotipos por una tarifa plana. Limitan el número de solicitudes de modificación porque saben que algunos clientes los matarán por la muerte de mil cortes con todos sus cambios. Ponle fin o carga más. Se llama negocio.