Sprint Planning, claves y evitando malas interpretaciones

Hoy te voy a dejar un post de un tema que puede parecer obvio pero que, por lo que yo me encuentro, no lo es, hoy vamos a hablar del Sprint Planning. Uno de los eventos clásicos en Scrum, que a todo el mundo le suena, pero en el que he visto hacer «cosas muy raras».

El Sprint Planning es la reunión de arranque del Sprint, en la que se planifica el trabajo de ese Sprint que está comenzando. Como todo evento, este también es un evento Time-Box. Y, teniendo siempre presente el Shuhari y sin caer en una religiosidad del asunto

¿Quién participa?

Al Sprint Planning asiste el Product Owner, el Scrum Master y todo el equipo técnico.
Por poder, el Product Owner puede invitar a algún Stakeholder para explicar algún elemento de negocio, aunque no suele suceder con frecuencia.

¿Qué se hace principalmente en un Sprint Planning y que se obtiene?

La tarea principal es crear el Sprint Backlog, ya sabes, aquel que contiene las historias de usuario (o items) en los que trabajará el equipo durante el Sprint más las tareas necesarias para incorporar esas historias de usuario (o items) al producto.

En el Sprint Backlog también puede, debe, haber otro tipo de tareas no directamente derivadas de items o historias, típicamente, las de control de deuda técnica, calidad, etc. Por aquello de que el ciclo de vida ágil es iterativo e incremental y por el riesgo de olvidarse del iterativo y quedarse solo con el incremental.

Te he repetido varias veces lo de item en los párrafos anteriores, para recordarte de que no sólo historias de usuario pueden ir en el Product Backlog y en el Sprint Backlog, de hecho, Scrum como tal solo habla de items. Ya sabes que la historia de usuario es algo funcional, etc., pero hay equipos que meten otro tipo de cosas de negocio en los Backlogs, nosotros en 233, por ejemplo, hacemos así.

En el Sprint Planning también se define el objetivo del Sprint, que lo definen entre todos, Product Owner y equipo técnico, y que también está pensado para que los Stakeholders sepan en qué se está trabajando sin tener que entrar al detalle de las historias de usuario que se realizarán en ese Sprint (aquí convendría recordar el post de ayer sobre darle un poco de «cariño» a los Stakeholders).

¿Con cuantas historias de usuario trabajamos en el Sprint Planning?

No sé si leíste aquel post de que la información irrelevante en una especificación o Product Backlog suele conllevar a mayores estimaciones. Bueno, en cualquier caso, el Product Owner lleva al Sprint Planning un conjunto razonable de items, los que, por Sprints anteriores, se entiende que pueden entrar en el siguiente Sprint (aunque la decisión final de cuántos se harán es del equipo técnico).

Para evitar que el Product Owner llegue al Sprint Planning con un número no apropiado de items, o que esos items no tengan la calidad, tamaño, etc., suficiente, y evitar el riesgo de que acabe mal Sprint Planning, algunos equipos hacen un evento previo, más cortito, de refinamiento del Product Backlog.

¿Quién decide cuántas historias pasan al Sprint?

Es decir, cuántas historias de usuario se convierten en tareas del Sprint Backlog. Ya te lo conté antes, pero por hacerlo más explícito, la decisión es del equipo técnico. No voy a entrar en temas de estimación, que se va del tema, y hay muchos post sobre esto (y hasta una guía que te puedes bajar gratis en pdf).
 

Javier Garzás

1 comentario en “Sprint Planning, claves y evitando malas interpretaciones”

  1. Hola Javier,
    gracias por continuar ayudando a la comunidad con tus artículos sobre agilidad.
    Con el ánimo de ayudar, me gustaría comentar un aspecto al que normalmente se le presta poca atención: la meta del Sprint. Es cierto que ayuda a los externos a conocer mejor el objetivo del Sprint sin mirar una lista de «tickets», pero querría destacar que sirve principalmente al equipo para optimizar el resultado del Sprint.
    A pesar que los PBI hayan sido refinados previamente a la planificación del Sprint y revisados conjuntamente en este evento, el Sprint Backlog no suele ser exhaustivo (ni se espera que lo sea). Cuando el Equipo de Desarrollo (no me gusta llamarlo técnico, puede tener capacidades funcionales) mete «manos en harina» una vez iniciado el Sprint, pueden aparecer necesidades de desarrollo (p.e. nuevos PBI, historias o tareas) que pudieran no quedar recogidos en el Sprint Backlog, y poder evaluar si están dentro o fuera de la meta del Sprint, ayuda a mantener el foco y a aprovechar la creatividad del equipo.
    Espero que ayude. 🙂
    Alex @ http://www.itnove.com

Deja un comentario

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

Ir arriba