Vamos a centrarnos en una reunión que tiene una importancia capital, no solo por lo complicado de estimar, o de no estimar (que es un punto importante y clave en este tipo de reuniones), sino porque es el punto donde el equipo al completo adquiere el compromiso de aportar X valor (en forma de ítems, de User Story’s o como se quiera determinar) en un plazo concreto de tiempo y/o esfuerzo, (esto ya va a gustos, como casi todo) el sprint.

Contenido

El objetivo de este tipo de reuniones es obvio; planificar el sprint en el cual el equipo al completo debería adquirir un compromiso de tener realizadas N funcionalidades en forma de valor al proyecto al llegar al final de dicho sprint.

Aquí hay varios puntos claves, el primero y que suele ser causa de conflictos es la estimación (e insistimos, o la no estimación).

En líneas generales se tiene la idea de que, para poder comprometerse con algo, previamente hay que estimarlo. Esta afirmación puede ser cierta o no, y sobre todo, depende de qué entendemos por «estimar», aunque la parte importante es cómo se debe estimar.

Si buscamos un modelo ceñido a horas y esfuerzos (en plan cocomo y cosas así…….) directamente pensamos que la planificación se convertirá más bien en «deseos» que en realidades. Pero ojo, que un modelo de estimación en puntos, secuencias, etcétera también tiene sus desventajas, y especialmente hacia el cliente, y estas también son importantes (actualización 2019 -> esto era obvio en el 2017, ahora prácticamente todo el mundo lo ve igual).

Sin pretender redactar un post de cómo o cómo no se debe estimar, la idea principal es que en una reunión de planificación se debería terminar con una serie de puntos claros y un compromiso «encima de la mesa» de todo el equipo con lo que se va a entregar al cliente al final del sprint.

En este compromiso, como es lógico, el cliente también adquiere el suyo propio que consiste básicamente no efectuar cambios de última hora en los ítems que de manera común y por consenso han entrado en el sprint.

Desarrollo de la reunión

El desarrollo de este tipo de reuniones podría seguir este modelo:

– El product owner (o el/los roles que ejerzan sus funciones) define una lista de ítems, user story’s o el formato que se esté usando, que desea que estén acabados al finalizar el sprint. Cabe resaltar que en otro post hablaremos de cómo organizar, trabajar, priorizar, y en definitiva gestionar un backlog, técnicas de mapping, y demás prácticas que están relacionadas con tener un buen proceso de incepción, un MVP realista, y el largo etcétera necesario para llegar hasta este tipo de reuniones (las de un sprint en pleno desarrollo) pero eso, será en otro post.

– El equipo pregunta, consulta y da su opinión sobre lo que el product owner desea «meter» en el sprint.

– Se deben buscar puntos en común, acuerdos y formas de llegar a lo que por un lado el product owner está pidiendo y por otro a lo que el equipo es capaz de ofrecer.

Esto es importante; en un equipo de alto rendimiento es probable que se llegue a un nivel de satisfacción, valor entregado, calidad, etcétera muy alto, pero muchas veces no hay que olvidar que el equipo es el que es, esto no lo escribimos de manera peyorativa, todo lo contrario. Las causas de que un equipo no pueda ofrecer un rendimiento muy alto son varias, casi seguro que complejas y tengan más que ver con cultura organizativa, formación, ambiente, expectativas, y un largo etcétera que no es nada fácil de conseguir, y menos al primero o segundo intento.

Por tanto, el ser realistas es un punto a favor de todos, tanto para el proyecto como para los participantes del mismo.

– En esta reunión se debería haber llegado de una u otra manera a las estimaciones, al principio, nuestra recomendación es que sea el propio equipo el que estime  de manera común el esfuerzo, sin entrar en técnicas concretas, lo ideal es que el equipo pueda comprometerse a tener una serie de ítems del backlog terminados con los estándares de calidad del proyecto, y si, esto no es fácil y puede representar el grueso de una reunión de planificación, aunque no debería ser así, la experiencia nos dice que si, efectivamente (e insistimos muy especialmente al inicio) esto ocurre.

– Si existen divergencias y conflictos en el equipo (por estimaciones, entre los miembros o con el product owner) esta es la reunión donde deben aflorar las cosas, de lo contrario el sprint comenzará «viciado» y casi seguro que no será lo que ninguna de las partes y personas esperan.

– De esta reunión salen los compromisos del equipo (incluido el product owner) pero también las expectativas para el sprint, por tanto, es imprescindible que al finalizar la reunión todos los componentes tengan claro que entra y que no entra en el sprint y el por qué.

Artefactos

De esta reunión debería quedar un backlog actualizado, una lista de ítems definida y acotada para el sprint y una lista de personas/tareas asignadas.

Con esto último nos referimos a lo siguiente: es practico (sobre todo al principio de un proyecto, cuando entran personas nuevas, etcétera) conocerse bien unos a otros y ver puntos flacos y debilidades, un equipo debiera ser auto-organizado, independiente y tener muy claro porque se les pide lo que se les pide para ese sprint.

Hay dos puntos claves en esto último:

– El product owner debería ser capaz de explicar porque quiere/necesita los ítems que ha marcado, de esta manera todo el equipo comprenderá (y esto es incremental conforme pasa el tiempo) cual es el valor (o lo que percibe como valor) el cliente.

El equipo debe encontrar un punto de equilibrio, de manera todos sus miembros sientan que hacen el mismo esfuerzo, que están cómodos con las tareas asignadas, etcétera.

Y por último en estas reuniones, además de las estimaciones también es muy probable que afloren lo siguientes puntos:

– Los acuerdos y no acuerdos entre equipo y product owner

– Ítems que no están bien definidos y sin embargo están en el backlog listos para entrar en sprints.

– Áreas, ítems, user story’s, etcétera que se van «quedando atrás» y no entran en los sprints, bien por tamaño, por valor, por X.

– Los puntos de convergencia y de divergencia, tanto a nivel de equipo como a nivel de proyecto.

Concluyendo

En general las técnicas que se pueden realizar para solucionar , o al menos mitigar, estos puntos son muchas y variadas, desde colores y sombreros, a principios de 80 20 y otras pero, para nosotros lo realmente importante es que siempre que se termine una reunión de planificación se sienta un win-win por todas las partes y que todo el equipo sienta que el compromiso es adquirido por decisión propia, que es capaz de hacerlo sin sobre esfuerzo (o pérdidas de calidad…) y que el cliente va a obtener el valor esperado.

Por último, se pueden implementar una serie de métricas muy sencillas que nos ayudaran el siempre presente ciclo de mejora continua.

– Qué número de ítems han entrado (porcentajes, etcétera)

– Qué número de ítems si/no han sido correctamente estimados

– En qué áreas funcionales (aplíquese cualquier otro criterio como urgencia, criticidad, frecuencia de uso, etcétera) si/no hay consenso.

– Ítems (se puede incluir todo tipo de variables como en el punto anterior) en los que había consenso, si se ha estado conforme o no conforme o abstenciones.

– En qué estado de preparación estaban los ítems que han entrado

 

Deja una respuesta

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