Cómo nos organizamos ágilmente en 233: Los Sprints

Como nos toca pasar por tantos sitios, ver tantas situaciones, equipos, empresas, preguntas, necesidad de consejos, etc., se nos ocurrió que no estaría de más ayudar a la comunidad compartiendo nuestra propia experiencia, cómo nos organizamos de manera ágil nosotros, en 233 Grados de TI.
Así que, en el post de hoy, vamos a hablarte de cómo organizamos nostros nuestros Sprints, en post posteriores trataremos otros temas.
Ya sabes, un Sprint es un periodo de duración (no superior a 30 días) que debe finalizar con un prototipo operativo potencialmente entregable o incremento. Y en 233 Grados de TI llevamos registrados en nuestra herramienta de gestión, en Jira, actualmente 70 Sprints (en realidad llevamos más Sprints, pero registrados 70, ya que previamente sólo haciamos uso de pizarras en papel).

¿Sprint fijo o variable?

Hace un tiempo ya tratamos si la duración de un Sprint es fija o variable, el post ¿Deberían todos los Sprint, o las iteraciones, durar el mismo tiempo? En aquel post la recomendación clara era que fueran todos de la misma duración (no te repito las razones, están en aquel post).

En nuestro caso, todos, con algunas excepciones, han durado una semana. Y han empezado siempre en lunes y han terminado el siguiente lunes (por ello los lunes hacemos el cierre, apertura y retospectiva, todo en unas 2- 3 horas). Las excepciones son los “Sprints 233 holidays” como nosotros los llamamos, que no tienen la misma duración que el resto.
Abajo te dejamos una imagen en la que puedes ver los puntos historia (te recomiendo leer antes de seguir ¿Por qué utilizamos Puntos Historia para estimar y no horas?) estimados por Sprint (línea azul) y los cumplidos (línea verde), donde se aprecian los periodos de vacaciones en los cuales también hacemos Sprints, pero la duración no es de una semana, más el bajón en puntos historia.
Sprints 233 Grados de TI

¿Qué tareas y/o historias incluimos en el Sprint?

Hemos visto cuánto duran nuestros Sprints, veamos ahora los elementos con los que trabajamos durante la semana y su procedencia. Hablemos del Product Backlog y el Sprint Backlog.

Como te contamos en El Product Backlog, el Product Ganttklog y otros seres y estares, extraído literalmente de la citada Guía de Scrum en castellano, el Product Backlog es …

“…una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación.”

“…Una Lista de Producto nunca está completa. El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al principio.”

“…enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras. Los elementos de la Lista de Producto tienen como atributos la descripción, la ordenación, la estimación y el valor…”

Y lo anterior lo dice todo. Nuestro Product Backlog, o Backlog, contiene items, que no sólo historias de usuario, que aportan valor, priorizados. Todo lo que aporta valor de negocio, a un tamamaño mínimo (pocos días de trabajo), es un item en el Backlog que, posteriormente, se descompondrá en tareas.

Cuando planificamos el Sprint, como conocemos nuestra velocidad en Puntos Historia, y tenemos estimados en puntos historia los items más prioritarios del Product Backlog… vamos metiendo en el Sprint, según orden por valor de negocio, hasta que la suma de los puntos historia de los items ronda la velocidad media que tenemos.
Valor de negocio, por cierto, es, normalmente, valor que aportamos con la realización de ese item a una comunidad externa (empresa, equipo, grupo de personas, etc.). Valor puede venir de «un proyecto» (en el que, por ejemplo, estamos haciendo un mentoring ágil) y puede venir de una acción de ayuda a la comunidad (si, por ejemplo, queremos aportar a la comunidad una guía de puntos historia).
Ah, y como trababajo orientados por el «equipo», en vez de «por proyectos», como debe ser, hay un único Product Backlog para todos aunque en ese Product Backlog pueda haber items de muchos «proyectos». Así, hay una única prioridad, un único orden, etc.

Concluyendo…

A las personas que formamos 233 Grados de TI nos gusta probar las técnicas, buenas prácticas, etc., y luego compartirlas. ¿Qué nos equivocamos? No pasa nada, siempre aprendemos algo, aunque el resultado no sea como esperábamos, eso también es experiencia.
Hasta aquí el estilo de vida de 233 lifestyle de este viernes 😉

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Cómo nos organizamos ágilmente en 233: Los Sprints”

  1. Muchas gracias por el post Noemí. Permíteme una pregunta en relación a esta sección del post:
    ‘Ah, y como trababajo orientados por el “equipo”, en vez de “por proyectos”, como debe ser, hay un único Product Backlog para todos aunque en ese Product Backlog pueda haber items de muchos “proyectos”. Así, hay una única prioridad, un único orden, etc.’
    Nosotros hasta día de hoy aplicamos la idea de un product backlog por equipo, en donde cada equipo solo tiene un proyecto a la vez (otra cosa son los mantenimientos…). Entiendo que lo que comentas se refiere a que si tienes los proyectos A, B y C completamente independientes entre sí, ¿todos las HU de estos proyectos estan ‘a la vez’ incluidas en un único product backlog general? ¿Podrías ampliar esta parte o darnos alguna referencia para investigar?
    ¡Muchas gracias de antemano y buen fin de semana!

  2. Hola César,
    Lo primero vais por buen camino aplicando el concepto de un Product Backlog por equipo 🙂
    Respecto a tu pregunta, sí, así es, utilizamos un Product Backlog por equipo aunque los items que le componen no pertenezcan al mismo proyecto.
    Siguiendo tu ejemplo serían Historias de Usuario del proyecto A, del B y del C en un mismo Product Backlog, aunque sean independientes entre sí, representan el trabajo de todo el equipo y es mejor respecto a la prioridad de las HU y a la velocidad del equipo trabajar de esta manera.
    Podéis leer más en el libro de Henrik Kniberg titulado: Kanban and Scrum – Making the Most of Both que podeís encontrar en https://www.crisp.se/konsulter/henrik-kniberg, en el capítulo 12 nos cuentan como tanto Scrum como Kanban nos permiten trabajar de esta forma.
    ¡Buen fin de semana para ti también!

Dejar un comentario

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