Los 3 errores más típicos en un Sprint Planning

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.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *