No voy a explicar a estas alturas qué es un Sprint Planning, que ya todo el mundo lo sabe (sino aquí tienes un post sobre el Sprint Planning), pero conviene recordar, resumidamente, que el objetivo de en un Sprint Plannig es decidir, como equipo, cuántos Items trabajaremos durante el Sprint y cómo los llevaremos acabo.
Y que la tarea principal es crear el Sprint Backlog, ese que contiene las historias de usuario (o items) en los que trabajará el equipo durante el Sprint y las tareas necesarias para incorporar esas historias de usuario (o items) al producto.
El Sprint Planning es uno de los eventos que más desperdicio se lleva cuando no se hace del todo bien (diría que se lleva más tiempo de desperdicio que una mala retrospectiva). Hay muchos errores típicos, como no fijar en el Planning el objetivo del Sprint, no trabajar nada, o trabajar demasiado, las tareas del Sprint Backlog, etc.
Pero de todos los errores típicos, me quedo con 3, por ser los más populares y de los que más daño hacen…
No fijar un tiempo máximo (que no se pueda superar)
Y añado, el problema no es solo no fijar un tiempo máximo (lo que viene a ser el time box), el problema es también que ese tiempo no sea el mínimo, mínimo, el tiempo justo.
Ya te hablé de ello en ¿cuánto debe durar un Sprint Planning? Cuando veo un Planning de 8 horas en el que participan 8 personas… «se me abren las carnes» y a vosotros os debería pasar lo mismo (y no te digo ya al Scrum Master).
Olvidar que esto va de hacer más working software, no de estimar
En su día hablamos de que estimar es un desperdicio o que estimar mejor es un medio para algo… no un fin. Sí, desperdicio del menos malo, quizá conviene no quitarlo, pero… tampoco conviene tener más allá de lo necesario. Lo que no tiene sentido es que por buscar la (imposible) perfección y exactitud estimando… hagamos menos historias.
Hay que reducir los tiempos que se dedican a ese tipo de cosas, y de ahí (y de otras cosas) venía aquello de tirar a la basura las cartas del Planning Poker
No tener un Product Backlog decente
La entrada al Sprint Planning es el Product Backlog y, uff, la de Product Backlogs que llegan de mala manera al Planning y que, por ello, se llevan un montón de tiempo del Planning en detallar sus Items, en vez de en trabajar en qué Items se harán en el Sprint y cómo.
Entre los problemas más típicos, está lo de tener historias muy grandes (¿Por qué las Historias de Usuario deben ser lo más pequeñas posible?), que probablemente no sean ni historias, Historias de Usuario sospechosas, etc. Te dejo aquel post de algunas pistas para saber si ese Item es, o no, una Historia de Usuario.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Me pasa como PO que a veces se crean peticiones hijas que ni yo entiendo ni puedo justificar si se pisa con otra padre que había escrito. Terrible.