ES 
EN 
JA 
IT 
La simplificación del estatus
Estoy haciendo una gran suposición aquí, pero supongo que sus equipos usan Jira para cumplir con los requisitos del producto. En realidad, tampoco es una gran suposición, más de 65.000 empresas lo utilizan en todo el mundo, así que sólo estoy jugando con las probabilidades. Jira es increíble... pero a pesar de todas sus increíbles características, el flujo de trabajo personalizable es el que voy a discutir... porque me molesta.
Cada PBI en su Product Backlog tiene un ciclo de vida. Se crea, probablemente se trabaja en él y luego se completa. Sencillo, ¿verdad? Todos los equipos con los que he trabajado utilizan flujos de trabajo de Jira para modelar su ciclo de vida de PBI y es muy eficaz. Aquí hay un ejemplo:
El equipo de desarrollo mueve cada PBI a través de los estados hasta que finaliza el trabajo. Pero, ¿alguna vez has notado que siempre hay un miembro del equipo cuyo trabajo está en 'Abierto' y luego anuncia en el Daily Scrum 'oh sí, lo siento, ya casi está terminado, simplemente no cambié el estado'? ¿Es culpa suya por no mantener el estado actualizado? ¿O el proceso es simplemente demasiado complicado?
¿Realmente vale la pena la complejidad del flujo de trabajo?
Para responder a esto, debemos considerar el propósito del Sprint Backlog. Es un artefacto que muestra el plan previsto del equipo de desarrollo para lograr el objetivo del Sprint. Se inspecciona (y se adapta si es necesario) diariamente. Lo importante es que sea transparente. En mi experiencia, cuando los equipos de desarrollo inspeccionan su Sprint Backlog, hablan de cosas como, 'Sí, estoy a punto de integrar ese trabajo' o 'No, necesita más pruebas manuales antes de lanzarlo'... si están dando esto nivel de detalle, considere ¿para quién son los estados complejos del flujo de trabajo de Jira? ¡Pregunta a tus equipos! Después de todo, es su proceso.
Le pregunté esto a mi equipo Scrum y la respuesta fue…. *encogimiento de hombros*. Después de algunos Cinco Porqués, rompimos esto *encogimiento de hombros* hasta tres cosas:
- El equipo de desarrollo no necesita estados complejos. Conocen en profundidad el estado de sus PBI.
- El propietario del producto tampoco utilizó los estados. Todo lo que querían saber era si era probable que se alcanzara el objetivo del Sprint.
- Los beneficios de los estados complejos eran externos (los roles "complementarios" de los gerentes de proyectos y versiones).
Los aficionados a Scrum sabrán que la guía no hace referencia explícita a ningún "estado" por el que deba pasar un PBI (bueno, porque es un marco, no una metodología 😊). Pero, ¿algunas están implícitas? En mi opinión, ¡SÍ!
En primer lugar, "Terminado": un PBI que cumple con la definición de "Terminado" está "Terminado". En segundo lugar, un PBI que acaba de crearse es 'To Do' o algún término parecido. Y en tercer lugar, sólo por extensión, un PBI que no es ni 'Por Hacer' ni 'Hecho' es….¿Haciendo? ¿En curso? Como quieras llamarlos, ¿nuestro flujo de trabajo de Jira podría ser simplemente "Tareas pendientes", "En progreso" y "Listo"? Ciertamente no me corresponde a mí, como Scrum Master, decidir esto. El proceso es propiedad del Scrum Team. Pero creo que esta simplificación es útil porque proporciona un lenguaje común más simple al que puede recurrir el equipo.
Si estás pensando, mi equipo utiliza un flujo de trabajo más complejo y eso funciona para nosotros... ¡es genial! Si su proceso funciona, ¡crack! Pero pregúntese a quién ayuda la complejidad: ¿las personas que necesitan conocer el progreso de las PBI ya lo saben? ¿Estás intentando sustituir la comunicación por estados complejos? ¿Hay valor en la complejidad? De lo contrario, deje que sus equipos lo consideren y vean cómo quieren autoorganizarse en torno a una solución.
Piensa en lo sencillo que puede ser todo:
¿Hay algunas desventajas con este flujo de trabajo simple? Estas son las preguntas que me envió mi equipo y mis respuestas parafraseadas:
¿Qué pasa si un PBI se bloquea por factores externos?
Buena pregunta. Podríamos agregar un estado para bloqueado. Pero si el PBI es bloqueado por otro equipo, ¿se sigue avanzando en ello? ¿Sigues involucrado en su progreso? Entonces, ¿podría simplemente permanecer "En progreso"?
¿Qué sucede si necesitamos entregar un PBI para realizar pruebas?
Scrum es un marco empleado por equipos multifuncionales. El Equipo de Desarrollo es responsable de todo el trabajo para convertir un PBI en Listo. ¿Pasamos trabajo regularmente a otros equipos? ¿Por qué?
¿Cómo puedo mostrar que se está avanzando en un PBI más grande si simplemente está "en progreso" durante años?
Comunicación con el Product Owner. Si la OP sabe que se están logrando avances, su responsabilidad es mantener actualizadas a sus partes interesadas. Si se siente presionado porque no está demostrando progreso, ¿cómo cree el equipo que modelamos la confianza? ¿O podríamos aprender de esto y descomponer nuestros PBI en partes más pequeñas?
Dejaré este post ahí. Sé que esta simplificación no será del agrado de todos, pero si quitas algo de esto, recuerda que un flujo de trabajo complejo de Jira no debería reemplazar la buena comunicación verbal y la transparencia.