Como comenté en una entrada anterior (Implementando Scrum: Cómo empezamos), nuestro Product Owner se encontraba hasta hace poco fuera del país. Recientemente volvió a trabajar desde nuestra oficina, lo que nos permitió realizar una primera planificación de Sprint con el Product Owner presente. Las ventajas de contar con su presencia saltaron a la vista, ya que la priorización y negociación de tareas se hizo de una forma muy fluída, así como también se despejaron algunas dudas instantáneamente durante la planificación misma.

Además de eso, este Sprint tuvo varias características que lo hicieron único respecto a los anteriores:

• La planificación se realizó fuera de horario. Debido a complicaciones varias del lunes, nos juntamos en la tarde, mientras que los Sprints anteriores se hacían lo más temprano posible. Esto no cumple con el espíritu de Scrum en cuanto al enfoque de time-box, mantener el ritmo, la disciplina y compromiso. Sin embargo, hay que tomar lo que sirve, y en este caso nos sirvió hacerla tarde.
• El equipo constaba de 7 programadores. Ahora se sumaron a la planificación los 2 diseñadores gráficos del proyecto. Estamos en etapa de maquetación e integración del código PHP con el diseño, por lo que volvimos a juntar a todos los responsables del desarrollo del proyecto. Además, el Scrum Master (yo) abandona temporalmente su puesto de director en el equipo, por razones planteadas en el siguiente punto, y se integra como un programador más.
• Nos encontramos muy cerca a una fecha de entrega, dos semanas. Teníamos varias características del producto definidas para esta entrega, que veíamos difícil de implementar. Por esto, hicimos una planificación bastante profunda, para tratar de meter todas las tareas importantes en un Sprint que por primera vez contaría con dos semanas de duración. Esta era la idea inicial, pero al estar empezando con Scrum, decidimos que una semana permitiría estimaciones más precisas. Desde mi punto de vista, el equipo ya se encuentra en condiciones de planificar los Sprints a dos semanas. Además la presencia del Product Owner facilita las cosas.
• Implementamos el Scrum Task Board. Como comenté, usábamos el pizarrón como Task Board. Ahora usamos un espejo que hay en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida de Scrum. Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint. Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo. También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre. Todos los movimientos en el Task Board se realizan únicamente en el Daily Meeting, de manera que todo el equipo esté al tanto de lo que sucede, y por el compromiso que implica llevar una tarea a la columna de «finalizado»
• En lo personal, es un Sprint más «feliz», ya que dejé mi puesto de Project Manager y Director, para meterme de lleno en el código. Así que ahora estoy cumpliendo el rol de Scrum Master así como de desarrollador del equipo.

Lo interesante de la planificación fueron las etapas . En un principio se sentía mucha tensión, presión, nervios, miedo, stress… Pero la presencia del Product Owner (también jefe del equipo), se hizo notar, y las cosas llegaron a una buena conclusión. Demoramos algunas horas en definirlo, pero llegamos a una planificación completa de las dos semanas siguientes de trabajo. Esto fue el lunes de la semana pasada, y a más de una semana, puedo decir que ha resultado. Hoy el Task Board tiene mucho más tareas naranjas agregadas, así como algunas amarillas más (mayor granulación de algunas tareas), pero la columna de «terminado» está colmada.

Un Sprint muy especial, por todo lo comentado. En teoría, tendríamos un review y reflexión de este «Sprint heróico» el día 3 de agosto, así que ya comentaré cómo estuvo eso. Mientras tanto, ¡a programar!