Hace poco me topé con Jaume, quién me contó que lo que realmente "sprinta" es el producto... tomando perspectiva, Scrum es una gestión de entrega incremental de producto en la que el equipo entrega con cada sprint un incremento de producto terminado, un resultado completo potencialmente desplegable en producción. No cabe duda, es el producto quién "sprinta".
Considerar que el equipo "sprinta", que construye con cadencia, nos lleva a una disfunción muy propia de equipos poco maduros. Aquellos que afirman que sus historias de usuario son indivisibles y por tanto se han de construir en dos o más sprints, y creyendo que aplican Scrum, obvian que una historia de usuario no puede ser mayor que la que cabe en un solo sprint.
 |
| Scrum es un gestión de entrega incremental de producto - cortesía PixaBay |
Hola Alexander. Estoy de acuerdo. Las historias de usuario o los pbi deben tener un tamaño adecuado para entrar en un sprint, y eso forma parte de nuestras buenas prácticas. Pero y ¿cuando no se puede? Mi ejemplo: recientemente hemos tenido que realizar unos cambios buscando mejorar el rendimiento en la aplicación, eso nos ha llevado a un cambio en el core que mínimo nos lleva 2 sprints (actualmente estamos en el segundo). Normalmente desplegamos o por lo menos entregamos incremento potencialmente desplegable al final de cada sprint, pero también se dan estos casos en los que al final del sprint (en este caso, el primero de los dos) el cambio estaba a medias, y no encontraba una forma lógica y aprovechable de romper el pbi para poder generar algo potencialmente entregable, es decir desde nuestra experiencia el pbi era indivisible. Esto se da en la realidad, o ¿que hacen los equipos maduros para que no se de? ;-)
ResponderEliminarHola Edu,
EliminarSi lo piensas con perspectiva desde fuera, un equipo, digamos de cinco personas, debería de poder hacer mucho trabajo en digamos 2 semanas, quiero decir que un PBI tiene que ser muy grande para que no se pueda hacer en un sprint. Pero ocurre, en nuestras realidades y con las infraestructuras que tenemos hay ocasiones en las que un PBI no cabe en un sprint y hay que hacerlo en dos sprints o más. Mientras el PBI sea una excepción, está bien, las excepciones confirman la regla.
Yo aconsejaría construir este tipo de PBI de tal manera que a final del primer sprint se pudiera enseñar algo a los interesados de manera que nos permita obtener su feedback, aunque no entreguemos nada. Una estrategia en este sentido es la división de un PBI por "happy flow", en el primer sprint construyes la solución como si todo fuera bien y sin excepciones, a final de sprint le enseñas al usuario como quedará para poder obtener su feedback, y en el segundo sprint incluyes feedback de valor y las excepciones.
Equipos maduros implica estar en empresas maduras, empresas que trabajan con arquitectura ágil como microservicios pro ejemplo, y con cultura DevOps con una pipeline de despliegue continuo donde el ciclo de llevar a producción sea cortísimo. En ese ambiente, cuando todos los ciclos son cortos, los PBIs son pequeños.
Para mi lo importante es la mentalidad que hay detrás, si los equipos se esfuerzan en dividir en PBIs pequeños aprenderán y acelerarán, ese es el objetivo, las excepciones ocurrirán y no son más que eso, excepciones.
Gracias por escribir, un abrazo,
Alex