En el artículo anterior...
Este artículo es la segunda parte de otro donde hablaba de como integrar el trabajo de los especialistas de UX y los desarrolladores de software.
Puedes leer la primera parte aquí: Como integrar UX y Scrum - ¿Dual Track Scrum?
Backlog y PBI de diseño (tipos de actividad)
El backlog es el repositorio de trabajo del equipo Scrum. Dependiendo si los diseñadores y desarrolladores están en un equipo o en dos, tendremos:
- Dos backlogs: los equipos de diseño de experiencia de usuario (UX) y de desarrollo trabajan de manera no sincronizada, ya sea con fases de diseño y de programación (waterfall) o de sprints entrelazados de diseño y desarrollo (dual-track). Un backlog contiene items de diseño, y una vez aprobados pasan al backlog de desarrollo. Conceptualmente es más intuitivo saber el tipo y objetivo de los ítems de cada backlog, pero genera desconexión entre los equipos, así como más riesgo de retrabajos y de no entregar una experiencia de usuario validada con éste.
- Un único backlog: ambos equipos trabajan sincronizados en el mismo Sprint. Intuitivamente genera un trabajo más integrado los especialistas de diseño y desarrollo, pero genera dudas de como tratar los ítems del backlog, p.e. su tipología (PBI de diseño vs de desarrollo) o en como tratar paquetes de trabajo que no pueden completarse en un Sprint.
Considerando que en el artículo anterior se indicaba que Scrum pide que los equipos puedan producir incrementos de producto "Hechos" en cada sprint, es difícil cumplir este objetivo sin tener un único equipo de desarrollo y un único Backlog de producto. De las dudas identificadas:
- PBI específicos de diseño: no generan valor por si mismos, por lo que no parecen buenos PBI. Así pues, los PBI son paquetes de trabajo de producto "completos" y no partes del proceso.
- Como tratar PBI con duración superior a un Sprint de pocas semanas: pueden tratarse en el refinamiento o dejarlos realizándose durante más de un Sprint, si este no es el escenario habitual.
Comparamos la gestión de un Backlog con Upstream/Discovery de Kanban
Hay miembros de la comunidad de Kanban que abogan por el modelo "Upstream/Discovery". Upstream significa habitualmente la parte del proceso que está fuera del alcance del equipo, en este caso previo al desarrollo. Discovery significa que el objetivo de esta parte del proceso es discriminar cuales de las ideas son viables y valiosas, de la manera más barata y eficaz posible.
Ejemplo de un Upstream/Discovery Kanban de Patrick Steyaert.
Es cierto que las velocidades y ritmos de las actividades de descubrimiento de ideas y de su realización son diferentes. La virtud de este modelo es que hace transparente el estado de todo el trabajo y permite mantener el flujo. El inconveniente, desde el punto de vista de Scrum, es que separa conceptualmente ambos tipos de trabajo y por tanto da pie a la existencia de personas y equipos separados, con los riesgos asociados de desconexión entre ambas partes, retrabajos técnicos y funcionales, así como validación tardía del producto real y no validación de prototipos o maquetas.
Desde el punto de vista de Scrum, se pueden implementar los mismos conceptos a través de un Backlog de Producto:
- Actividades de descubrimiento: las ideas se identifican y se priorizan inicialmente. Las actividades de exploración (p.e. realizar prototipos, entrevistas, etc.) pueden ser parte de un Sprint (p.e. refinamiento). Se priorizan o descartan en función del valor percibido.
- Actividades de definición: cuando una idea ha sido explorada y se quiere desarrollar, habitualmente se refina (de nuevo como parte del Sprint) y se planifica teniendo en cuenta diferentes aspectos, como su tamaño o dependencias.
- Actividades de desarrollo: Finalmente los ítems del producto se desarrollan durante el Sprint. En el siguiente apartado tocaremos el peliagudo tema de: ¿cuando algo está "hecho" desde el punto de vista de UX?
Ejemplo de un backlog bidimensional que incorpora actividades de UX. Elaboración propia.
Aunque tanto el Upstream/Discovery Kanban y los Backlogs con actividades de diseño pueden tener estados parecidos, su diferencia fundamental es que el Backlog fomenta el trabajo compartido de UX y desarrollo dentro del sprint y por un mismo equipo. Hay más detalles de como adaptar Scrum a un enfoque UX en el artículo (1) de Jeff Gothelf.
Hecho y UX
Una de las reglas de Scrum, según su Guía (6), es que el incremento está "hecho" si es almenos potencialmente desplegable al cliente. Aunque esto puede querer decir muchas cosas, comunmente se entiende que los ítems que consideramos frutos del Sprint está desarrollados, probados y "aceptados" de alguna manera. El objetivo es tener transparencia sobre el estado del desarrollo para optimizar el resto de los Sprints futuros según este aprendizaje.
¿Es esto suficiente para los enfoques de UX que algo sea potencialmente desplegable? La respuesta es que no, pues no garantiza que ha satisfecho la necesidad del usuario o que la experiencia de uso es satisfactoria. Según el libro Lean UX, algo está hecho cuando se valida una hipótesis que hace cambiar la conducta del usuario. Esto puede ser difícil o imposible de validarse en el momento del Sprint. Necesitamos observar los efectos de los ítems desarrollados mediante el uso un conjunto de usuarios representativo. Así pues, "Done" tiene que ser "desplegado". Pero no tiene que ser necesariamente un despliegue masivo, p.e. la técnica de Canary Releasing permite experimentar con los efectos de un despligue
Técnica de Canary Releasing, de Ketan Padegaonkar (Go CD).
¡Todavía hay mucho más en el curso Professional Scrum with UX!
En estos dos artículos hemos tratado de algunas de las dudas más habituales que aparecen al hablar de Scrum y UX. En los cursos Professional Scrum with UX de Scrum.org podrás tener mucho más detalle y trabajarlo de manera práctica con otros especialistas de UX, Agile y Product Management digital.