.

Cómo mejorar la planificación en scrum

¿Qué es y cómo se lleva a cabo el refinamiento del Backlog de Producto? Scrum establece que NO debería consumir más del 10% de la capacidad del Equipo de Desarrollo. ¿Te parece mucho?… En este post tratamos brevemente estas y otras cuestiones respecto a la actividad de refinamiento del Backlog de Producto, una actividad esencial para mejorar la planificación.

Scrum Sprint

Como seguramente ya sabes el Backlog de Producto no es algo estático. Más bien todo lo contrario; se estira y encoje a lo largo de la vida del producto en desarrollo. Tampoco todos los elementos  que lo forman son iguales; generalmente los de la parte alta son más claros y detallados que los que se encuentran por abajo.

El refinamiento del Backlog de Producto en la guía scrum

Que establece la guía scrum sobre el refinamiento del Backlog de Producto:

El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a criterio suyo.

He marcado en negrita los aspectos que para mí son especialmente importantes:

  • Referente a su definición: es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto
  • Referente a cómo hacerlo: 1) proceso continuo, 2) equipo Scrum decide cómo y cuándo se hace el refinamiento, y 3) consume no más del 10% de la capacidad del Equipo de Desarrollo

Ahora te pregunto, ¿te parece mucho tiempo un 10%? … Aunque un 10% puede parecer poco, lo cierto es que la mayoría de veces ni si quiera se dedica un 1% de la capacidad del Equipo. Y esto es así, porque habitualmente infravaloramos la importancia de esta actividad.

La importancia del refinamiento del Backlog de Producto

El refinamiento del Backlog de Producto es mucho más de lo que a primera vista pueda parecer.  Tiene implicaciones sobre: la planificación y la estimación, la gestión de riesgos, el diseño de la solución,  la planificación de la calida, etc. Todo ello se comprende más fácilmente cuándo se presta atención a la relación que existe entre la actividad de refinamiento y el Backlog Producto, que es el eje central de los enfoques Ágiles.

En muchos aspectos el Backlog de Producto  es el artefacto de planificación de los equipos Ágiles (quien dijo que en scrum no se planifica).  Y el refinamiento es la práctica que nos permitirá llevar a cabo una buena planificación.

El refinamiento del Backlog de producto y la planificación

Por ejemplo, hay una correlación directa entre la calidad de la reunión de Planificación del Sprint, y la inversión en tiempo y calidad en la actividad de refinamiento. Cuanto más tiempo dediquemos al refinamiento del Backlog de Producto, mejor y más productiva será la reunión de planificación.

Al respecto, como facilitador y formador de scrum, una de las comentarios más habituales que escucho tienen que ver con la reunión de planificación del sprint. Es habitual escuchar a la gente decir: “No hay tiempo suficiente, o los resultados no son los deseados”.

Solución: si invertimos tiempo durante el sprint en el refinamiento del Backlog de Producto, las reuniones de planificación irán mucho mejor. El equipo estará mejor preparada, y se reducirá el tiempo necesario.  Y por supuesto, la calidad del plan de sprint, la ejecución y, en última instancia, los resultados mejorarán.

¡Hasta pronto!

JLVG

Post relacionados

Próxima masterclass Introducción a Agile y scrum El próximo miércoles 25 de enero tendrá lugar la Masterclass "Introducción a Agile y scrum". Una estupenda oportunidad par participar en sesión online...
Kanban y scrum: cómo mejorar la velocidad del sprint ¿Quién dice que se tenga que elegir entre Kanban y scrum? Te propongo tres soluciones para mejorar la velocidad del sprint combinando Kanban y scrum. ...
Retrospectivas scrum: cómo pasar a la acción Las retrospectivas son en mi opinión uno de los eventos fundamentales de scrum, por no decir el más importante. De todos los elementos que establece...

5 respuestas a “Cómo mejorar la planificación en scrum”

  1. Pedro dice:

    En pimer lugar agradecer por el site, me resulta muy interesante.
    Perdona por una pregunta tan larga, en realidad son varias, tengo la cabeza llena de información, pero es en el momento de los detalles cuando… cuando veo que hay cosas que no acaban de cuadrarme. Si no te parece mal, te digo como lo entiendo y te agradecería enormemente que me corrijas o llenes los gaps con como lo haceis vosotros.
    Entiendo que siempre es aconsejable realizar varias sesiónes de grooming antes de empezar el primer sprint. Es asi?
    En la sesión de grooming tratamos de que las US en la parte alta del Backlog cumplan la Def de Ready (DoR). Para ello el Product Owner (PO) las presenta al equipo y este va haciendo preguntas para entenderlas, una vez esta claro el requerimiento, el equipo discute sobre el diseño de la solución. Cierto?
    Teniendo en cuenta el diseño de la solucion y la Definicion de Done (DoD) con los criterios de aceptación el equipo estima la historia, si esta es demasiado grande para ser realizada en un sprint, entonces pasamos a dividirla en historias mas pequeñas, el PO las prioriza, volviendo al inicio del proceso en el cual se coge la historia con mayor prioridad, se discute sobre ella, para entenderla, diseño de la solución y se vuelve a estimar, asi, hasta que tenga un tamaño que nos haga sentir comodos de que se puede completar dentro del sprint.
    Para estimar el Equipo necesita que el PO detalle los criterios de aceptación, ya que estos son los que nos van a dar el alcance del requerimiento. Pero si los escribimos antes de estimar, y la historia recibe muchos puntos, se habrá invertido un buen rato en una tarea que no ha servido de nada, ya que al dividir la historia en otras mas pequeñas, los criterios de aceptación de estas nuevas van a ser distintos. Podeis indicar alguna manera practica de hacer esto?
    Una historia hasta que no entra en el Sprint es algo vivo y que puede evolucionar, siendo mayor o menor su alcance, por lo que la estimación podría varia. Entiendo que cuando se ha producido algún cambio en el alcance se reestime en el Sprint Planning. Pero si no ha habido ningún cambio, cual es el punto de que se vuelva a reestimar la historia en el Sprint Planning?
    Gracias por adelantado

    • Juan Luis Vila Grau dice:

      Hola Pedro, gracias por tu pregunta y disculpa el retraso en mi respuesta.

      Vamos por partes, por qué tu comentario es muy largo y aunque muy interesante hay partes que no consigo comprender. Por favor, cualquier cuestión al respecto no dudes en volver a escribir.

      Si nos encontramos en el primer sprint, lo que necesitamos es un Backlog trabajado o refinado, que nos permita empezar con la iteración. Recuerda que el Backlog de Producto es responsabilidad del Dueño del Producto.

      Para priorizarlo, el Dueño del producto debería haber considerado el valor de la historia de usuario (US), pero también el esfuerzo necesario para desarrollarla. Esto último solo deberían estimarlo los desarrolladores.

      La estimación en scrum NO es ni pretende ser una ciencia exacta; durante la estimación comparamos el esfuerzo relativo necesario para completar una US respecto de otra(s). No consiste en descomponer la US en todas y cada una de sus tareas, para luego calcular el esfuerzo de la US agregando el esfuerzo necesario para completar todas las tareas. Se trata de una estimación, como su propio nombre indica.

      Respecto al tamaño de la US y a la cuestión de si es muy grande; a nivel práctico, la US se debería seguir descomponiendo hasta que ya no puede hacerse más pequeña. La clave está en distinguir entre US y tarea (link).

      Una vez la US pasa a formar parte del Backlog del Sprint ya no hay nada que reestimar. Es decir, el equipo deberá o debería entregar la US conforme a lo acordado, que en ese punto es conforme con el Dueño del Producto. Si al respecto hay cualquier cambio, entonces en mi opinión sería una nueva US. Dicho esto, hay que recordar que una US permite hacer algo al usuario, es una funcionalidad no un objeto o una cosa.

      Por otro lado, durante la reunión de Planificación del Sprint NO hay obligación de estimar o reestimar las historias de usuario que se llevarán a cabo durante el Sprint, dependerá de cada caso. Pero cuanto más trabajadas estén al llegar a este reunión, meno trabajamos tendremos que hacer al respecto, y mejores serán los resultados de la sesión de planificación.

      Al final no sé si he respondido a tus dudas. Cualquier comentario al respecto será bienvenido.
      Saludos cordiales, y hasta la próxima.

      JLVG

  2. Jose dice:

    Hola,
    uff, yo tambien tengo todas esas dudas, bueno, alguna mas 🙂
    En relacion a una de las preguntas que hace el usuario anterior, Una historia de usuario se divide cuando consideramos que es grande para poder acabarse dentro de un sprint, pero para saber si es grande necesitamos estimarla y para ello conocer sus criterios de aceptacion entre otras cosas… Esto lleva bastante tiempo, una vez que vemos que es muy grande. Entiendo que deberiamos dividirla, escribir de nuevo los criterios de aceptacion de las nuevas historias y estimar… Es correcto?
    Pero a efectos practicos, esto llevaria mucho tiempo, ademas, que de la historia original a sus hijas, los criterios ya no serian los mismos, o al menos no estarian redactados de igual manera…
    En mi equipo estimar una historia puede llevar mucho tiempo, si encima nos encontramos con que la historia es grande y hay que dividirla en varias, escribir los criterios, estimar las nuevas historias, priorizar, etc… a veces se nos va la sesion de tiempo solo con una historia.
    Vamos que lo que me gustaria saber es si podrias ofrecer algun consejo sobre cuando y como dividir las historias sin que se convierta en un trabajo que lleve muchisimo tiempo.
    Gracias

    • Juan Luis Vila Grau dice:

      Hola Jose,

      Todo lo que indicas es bastante correcto, pero en mi opinión seria conveniente hacer algunas aclaraciones.

      Tal como le comentaba a Pedro en mi respuesta anterior la estimación es algo que debe hacerse de manera “ágil” y que no debería llevar tanto tiempo como comentas. La estimación no deja de ser una aproximación y se lleva a cabo por comparación. Para ello como bien señalas hay que conocer los requisitos.

      Dicho esto, debes considerar la estimación como un proceso que tiene lugar a lo largo de todo el sprint, y no solo durante la planificación. Llegar a la reunión de planificación sin haber trabajado previamente las historias de usuario seguro pondrá en riesgo los resultados de esta reunión.

      Sobre el tamaño de la historia de usuario y como ajustarlo, te doy un par de ideas. En primer lugar no tiene que ser ni muy grande ni muy pequeña. Si es muy grande nos daremos cuenta porque al estimarla y compararla con la capacidad del equipo veremos que no puede concluirse en un sprint; entonces hay que dividirla en historias ma pequeñas. Dichas historias podrían implicar desarrollar en futuros sprints requisitos que hemos te ido que dejar de hacer en una primera entrega. Y si es muy pequeña nos daremos cuenta, porque tendrá un carácter más técnico.

      ¿Cuando nos damos cuenta de si el tamaño es el apropiado? Pues durante la planificación, en la que si o si debe estar el dueño del producto. Pero también, durante todo el proceso de refinamiento durante el sprint.

      Espero haber sido de ayuda. Por favor, si tienes cualquier otro comentario al respecto no dudes en escribir.

  3. Pedro dice:

    Muchas gracias Juan por tus respuestas. Aquí voy a la carga con alguna pregunta mas sobre este tema.
    Si inicialmente tenemos una US con sus Acceptance criteria (AC), la estimamos (por comparación) y determinamos que es grande para un sprint, por lo que la tendremos que dividir, Imaginemos que en 3 historias mas pequeñas.
    Que sucede con los AC? En teoría, si hubiésemos trabajado bien la Epica, todos sus AC estarían incluidos en las US hijo. Es decir, el sumatorio de todos los AC de las US hijo debería coincidir con el de la Epica. Cierto? O podrían salir mas?
    Dejamos constancia de la Epica, o al haber sido dividida en US mas pequeñas desaparece. En JIRA por ej las US que están bajo una misma feature se agrupan utilizando un Label. Como se puede hacer para identificar las US que provienen de una misma Epica? Como se haría en JIRA?
    Respecto a la estimación por comparación, ya se que debemos localizar una o varias US que nos sirvan de base para estimar el resto de US con respecto a ellas. Podrias dar una recomendación sobre como identificar esas US?
    Respecto a que estimar debe hacerse de una forma “agil”, no estoy seguro de si te entiendo, querria que me confirmases lo siguiente: supongo que estamos de acuerdo en que en primer lugar la historia tiene que estar totalmente clara para el equipo, y te refieres a la estimación en se, es decir al momento de compararla con las US que tenemos como base. Es asi?

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

SAFe® 4 Certified Agilist, PRINCE2® Practitioner, Scrum Product Owner (PSPO I), 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