.

5 errores frecuentes en la Planificación del Sprint

Aunque por definición sencilla, muchas son los problemas y errores que se cometen durante la Planificación del sprint. 

obstaculos en el camino

La Planificación del Sprint

La Planificación del Sprint es el primero de los eventos del sprint. Durante esta reunión que tiene dos partes, y una duración más máxima de 8 horas para sprints de un mes, el equipo scrum se reúne para elaborar el plan del Sprint.

5 errores frecuentes en la Planificación del Sprint

A continuación una breve descripción de 5 errores frecuentes en la Planificación del sprint, y algunos consejos para evitarlos:

  • Empezar sin el Dueño del Producto
  • Permitir que el Dueño de Producto establezca la cantidad de historias a desarrollar
  • El Dueño el Producto no está preparado para la Planificación del Sprint
  • El Backlog de Producto no está preparado para la Planificación del Sprint
  • Estimar la capacidad del sprint en base a horas hombres

¡Comencemos!

1) Empezar sin el Dueño del Producto

El Dueño de Producto debe estar presente cuando se lleven a cabo las estimaciones y la planificación del sprint. Sus responsabilidades incluyen la de asegurarse que todos, desarrolladores y clientes, tengan la misma comprensión acerca del significado de las historia de usuario.

confusión

En este sentido el Dueño de Producto puede ayudar a controlar las expectativas de lo que el equipo debe desarrollar; quizás insista en hacer las cosas un modo más sencillo, pero manteniendo el valor para el negocio. Recuerda: “la simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.”

Por ello, es fundamental que el Dueño de Producto esté disponible y presente durante toda la reunión. En Ágil/Scrum valoramos más la interacción entre las personas que los procesos y las herramientas, y “el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros, es la conversación cara a cara”.

Consejo: aunque el rol del Dueño del Producto puede desempeñarse a tiempo parcial, es fundamental que el Dueño del Producto preste la atención necesaria al equipo de desarrollo (tenga tiempo suficiente). El Scrum Máster es responsable de velar por el correcto cumplimiento de scrum, y en caso de que surja algún obstáculo, debe removerlo.

En caso de trabajar con varios equipos scrum, para evitar sobrecargar al  Dueño del Producto y que este no puede cumplir con sus responsabilidades podemos utilizar la figura de un Dueño del Producto Jefe. En este caso, varios Dueños del producto Locales, coordinados por el Dueño del Producto jefe, se encargarían de estar permanentemente a disposición de los equipos scrum.

2) Permitir que el Dueño de Producto establezca la cantidad de historias a desarrollar

Es decir, que el Dueño de Producto proponga (imponga) la cantidad de elementos del Backlog de Producto a desarrollar durante el sprint. Al respecto deben  tenerse en cuenta dos cosas; la velocidad, y las estimaciones del Equipo de Desarrollo. Respecto a la primera, el Dueño de Producto debería utilizarla la velocidad como una guía para realizar un cálculo orientativo, mientras que de la segunda (las estimaciones) es exclusivamente responsable el Equipo de Desarrollo.

el-jefe-tiene-que-saber-mandar

Conforme el Dueño de Producto propone elementos de la lista, aquellos que más valor tienen, el equipo de desarrollo estima (reestima o comprueba) el esfuerzo necesario para su desarrollo, y lo resta de su capacidad de trabajo. Recuerda: “los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.”

Consejo: El Scrum Máster debe asegurarse que el Dueño del Producto conoce su rol y responsabilidades. Es por ello que aunque no es obligatorio, si es recomendable que el Scrum Máster asista a esta reunión, al menos hasta cerciorarse que cada quien cumple con su rol y el evento se ejecuta correctamente.

3) El Dueño el Producto no está preparado para la Planificación del Sprint

La situación hace referencia al hecho de que el Dueño del Producto no tenga la información suficiente para aclarar las historias de usuario, y necesita llevar a cabo posteriores consultas. En este caso, es muy peligroso trabajar sobre aquellos elementos “incompletos” dado que los completaríamos con conjeturas. Es decir, al igual que nuestro cerebro, trataríamos de  llenar los vacíos de conocimiento con conjeturas o suposiciones que podrían poner en serio peligro  el proyecto.

not ready

Consejo: el Scrum Máster es responsable de velar por el correcto cumplimiento de scrum, y en este caso debe no solo prestar a tención a que el Dueño del Producto cumpla con las obligaciones de su rol, sino también prestarle ayuda para llevarlas a acabo. Por ejemplo, sugiriéndolo técnicas, herramientas o métodos de trabajo.

No es necesario esperar hasta la reunión de planificación para saber si el Dueño del Producto cumple con sus obligaciones (está o no preparado); recuerda que tenemos la actividad de “refinamiento” del Backlog de Producto nos ayudará a  prevenir esta situación. Sin embargo, el Dueño del Producto no es un “policía” ni tienen autoridad sobre nadie; sus recursos consiste en explicar y convencer acerca de la necesidad de seguir apropiadamente el marco de trabajo scrum.

4) El Backlog de Producto no está preparado para la Planificación del Sprint.

Si las historias de usuario no se han trabajado anteriormente, el avance pude ser muy lento, y apenas podremos avanzarse durante la reunión de Planificación, con la consecuente disminución en la productividad.

Al respecto hay que considerar varias cosas: 1) el propósito de la Planificación del Sprint no es planificar en detalle todas y cada una de las historias de usuario que llevaremos a  cabo durante el sprint. Más bien, dado que scrum es un enfoque Ágil, tratamos de planificar lo mínimo y suficiente para poder empezar a trabajar.

Y 2), todos somos conscientes de que la Reunión de Planificación no es suficiente para llevar trabajar las  historias de usuario “desde cero”.

Consejo: Precisamente para evitar esta anomalía está previsto el refinamiento del Backlog de Producto.

La actividad del refinamiento del Backlog de Producto tiene lugar durante el sprint, y cosiste en dedicar una parte de la capacidad del Equipo (nunca más del 10%) a trabajar las historias de usuario del Backlog de Producto. De esta manera, cuando llega el momento de la planificación, el Dueño de Producto esté lo suficientemente preparado como para iniciar la nueva iteración sin contratiempos, y el Equipo de Desarrollo ya ha trabajado las historias anteriormente, con lo que todo resulta más sencillo.

5) Estimar la capacidad del sprint en base a horas hombres

Sabemos que en los entornos Ágiles no nos gusta realizar las estimaciones en base a las horas hombre. Pero en caso de hacerlo, preferimos recurrir al concepto de horas ideales. ¿Cuál es el problema de emplear como unidad de cálculo las horas hombre?

En primer lugar hay que evitar caer en un error de principiante y descontar las horas necesarias para llevar a cabo los eventos scrum. Por ejemplo, si trabajamos con un equipo de 6 desarrolladores y estamos haciendo sprints de 4 semanas, deberíamos prever que necesitaremos:

  • Reunión de Planificación: 6 por 8 horas = 48 horas
  • Scrum diarios: unas 5 horas
  • Reunión del sprint: 6 por 4 horas = 24 horas
  • Retrospectiva del sprint: 6 por 3 horas = 18 horas

Es decir, de un total de 960 horas hombre disponibles, tendríamos que considerar que 95 horas vamos a necesitarlas para “gestionar” el sprint; la capacidad real sería de 870 horas.

Además deberíamos pensar en jornadas efectivas de menos de 8 horas, por ejemplo 6 o 7, máximo (horas ideales), dado que el resto del tiempo se dedica a otras tareas: escribir mails, contestar al teléfono, ayudar a compañeros…  Con todo ello nuestra capacidad se reduciría a 720 horas efectivas (considerando 6 horas ideales por jornada).

Consejo: para realizar las estimaciones, es mucho más sencillo y efectivo planificar los sprints en base a los puntos de historia.

Recuerda que si completamos todas las historias de usuario del Backlog del Sprint  antes de finalizar el sprint, siempre podemos volver a escoger nuevas historias de usuario del Backlog del Producto.

Otros errores frecuentes

Además, durante la Planificación del Sprint debemos prestar atención a:

  • La reunión no debe durar más de lo debido; podría ser indicativo de falta de productividad o de que estamos sobre-planificando el sprint. El Scrum Master debe estar atento a ello. (Duración).
  • Los miembros del equipo no planifican su propio “sprint individual”; se planifica de manera colaborativa. Todos son responsables del todo, del proyecto y entregar un incremento al final del sprint.
  • Definir el Objetivo del Sprint; en caso de no hacerlo, ¿cómo sabemos hacia dónde vamos?
  • No permitir que alguien, por ejemplo el Dueño de Producto o el Scrum Máster, incluso alguien externo, asigne las tareas al Equipo de Desarrollo. Recuerda, el equipo es auto-gestionado y multifuncional.

Y tú, ¿qué experiencia tienes en la planificación de sprint? ¿Tienes algún error o duda que te gustaría compartir con nosotros?

Post relacionados

Equipos scrum multiproyecto La mayoría de las veces que se presenta scrum, se hace en  un contexto de proyecto único. Sin embargo, es habitual que una organización necesite dedic...
Cambios en La Guía Scrum, julio 2016 La guía oficial Scrum de scrum.org ha sido modificada en las últimas semanas. ¿Cuáles han sido los cambios y por qué? Por primera vez desde  el 201...
El significado de equipo multifuncional en scrum Un equipo scrum debe ser multifuncional. ¿Significa esto que todos los miembros del equipo scrum deben que ser expertos en todos los temas? La respues...

Deja un comentario

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

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR