Resumen de contenidos
Una nueva entrada y esta vez es especial porque un compañero de trabajo se ha animado a dejar un pensamiento en FixedBuffer. Sin más preámbulos, os dejo con Ander que va a hablarnos de como dejar fino el sprint backlog para evitar sorpresas durante el desarrollo del trabajo.
¿En qué me va a ayudar esta entrada?
- ¿No consigues cerrar historias de usuario o tareas porque quien las ha pedido dice que aún no están terminadas y añade nueva funcionalidad cada vez que os juntáis para intentar cerrarla?
- ¿Te comprometes a realizar historias de usuario o tareas por las que no sabes ni por dónde empezar porque no las entiendes?
- ¿Te preguntas una y otra vez por qué se te ha pedido hacer esa funcionalidad que parece no tener sentido?
- ¿Te cuesta encontrar el valor que aportará al usuario final la tarea que se te ha encomendado?
- ¿Te piden solucionar errores de software que nadie consigue reproducir?
- ¿Pasas horas hablando con tu contacto (el cliente, el departamento de marketing, el product owner…) para que te diga lo que realmente quiere que esa historia de usuario o tarea consiga, tirando una y otra vez de la cuerda hasta conseguir, al fin, empezar?
- ¿Empezaste una historia a la que solo le faltaba un recurso (una imagen, unos textos…) y no pudiste cerrarla porque el recurso nunca llegó?
En esta entrada trataré de responder a todas esas preguntas y, posiblemente, a muchas otras que no se me ha ocurrido incluir en este primer apartado de la misma.
Introducción
En primer lugar, me gustaría aclarar que me voy a basar en cómo hago las cosas en mi actual empresa, centrándome en los proyectos en los que yo he trabajado o estoy trabajando.
Por tanto, los ejemplos estarán basados en Scrum, lo cual no quiere decir que, si en tu empresa utilizáis Kanban, XP Programming o cualquier otra metodología o framework o como toque llamarlo en este minuto, no podáis aplicarlo. Lo que vais a leer en esta entrada es compatible con cualquier metodología o framework y, a su vez, con no utilizar ninguno. Es organización y sentido común, de toda la vida. Aclarado esto, vamos al grano.
El Backlog y el Sprint Backlog. Oro parece, plátano es
¿Qué es el Backlog? ¿Qué es el Sprint Backlog? ¿Qué les diferencia? Responder a todas estas preguntas requeriría de otra entrada en el blog de mi compañero Jorge (si os interesa el tema, no tenéis más que pedirlo en los comentarios).
Para resumir, podríamos decir sin temor a equivocarnos lo siguiente:
Un backlog es una lista de tareas, a muy alto nivel, mediante las cuales conseguiremos alcanzar los objetivos funcionales establecidos en las fases preliminares de un proyecto o en cualquiera de sus revisiones y que nos ayudará a hacernos una idea del estado general del proyecto.
Un sprint backlog no es más que una lista de tareas, detalladas, priorizadas y listas para trabajar en ellas.
Como bien habéis podido leer en el título, lo que a nosotros nos ocupa es el Sprint Backlog, así que vamos a ver qué hacer para dejar fino el Sprint Backlog.
Los tiempos
Digamos que trabajamos en el marco de Scrum, y que, por tanto, participamos en, al menos, las siguientes liturgias (o como esté de moda decirlo ahora…):
- Scrum Planning Meeting
- Scrum Daily Meeting
- Scrum Demo Meeting
- Scrum Retrospective Meeting
Tras la Scrum Planning Meeting acordamos y dejamos cerrada con nuestro cliente la fecha de la Scrum Demo Meeting. También cerraremos fechas para la Scrum Retrospective Meeting y de la reunión de refinamiento del backlog en la que dejaremos fino el Sprint Backlog.
El cliente puede ser una persona de otra empresa si trabajas en una consultora o una persona de tu misma empresa, pero de otro departamento si trabajas en una empresa de producto, como Marketing.
Lo ideal es que la reunión de refinamiento del backlog ocurra más o menos una semana antes de la Scrum Planning Meeting siguiente. La idea detrás de esto es que el cliente tenga toda una semana para hacer frente a los flecos sueltos que puedan quedar tras la misma.
La reunión de refinamiento de backlog
En esta reunión, en la que deberán estar presentes las siguientes figuras:
- Equipo de desarrollo (o una parte del mismo si somos muchos)
- Cliente o su interlocutor
- Product Owner (si es que hay)
El Product Owner es la persona responsable de asegurar que el equipo aporte valor al negocio.
El cliente nos mostrará su propuesta de Sprint Backlog, que, como podéis leer unos apartados más arriba, será el resultado de refinar y priorizar el backlog general. Esto habrá tenido lugar sin nuestra presencia y es responsabilidad suya, teniendo en mente las prioridades para conseguir los objetivos funcionales establecidos para cada periodo.
Lo ideal es repasar tarea a tarea, intentando que cada una cumpla unos mínimos que habremos acordado anteriormente ambas partes. Ya existe un concepto llamado Definition Of Ready (DOR a partir de ahora) que, si te sirve, podrás utilizar.
Ambas partes, cliente y equipo de desarrollo, tendréis que llegar a un acuerdo y comprometeros a cumplir con el DOR.
A continuación, os pongo el que uso yo, personalmente, en mis proyectos. Hay que tomarlo como ejemplo y guía y no al pie de la letra, ya que cada proyecto es un mundo y el DOR deberá adaptarse en consecuencia.
Ejemplo de Definition Of Ready
- El valor que aportará la historia de usuario para el usuario a quien va dirigida está claramente indicado.
- Los criterios de aceptación están claramente definidos.
- Las dependencias de la historia de usuario están identificadas.
- La historia de usuario ha sido estimada por el equipo de desarrollo.
- Criterio de rendimiento, cuando sea aplicable.
- En la pantalla XXX, al cargar la información sobre… necesitaremos pasar de YYY segundos a ZZZ segundos
- Persona que aceptará la historia de usuario identificada.
- En nuestro caso, el PO
- El equipo de desarrollo sabe cómo hacer una demostración de la historia en funcionamiento.
- Todo el equipo de desarrollo, no solo la persona que escribió la historia. Todo el equipo que participe en ese proyecto debería tener claros los pasos para demostrar esa historia solo con leer.
Toda tarea que no cumpla con el DOR será claramente marcada como tal y, una vez terminado el repaso, se centralizará la información recogida. Todas las partes deben ser conscientes de que falta por terminar para dejar fino el Sprint Backlog.
Lo ideal es que cada punto que falte tenga un encargado, con nombre y apellidos, y asegurarnos de que tenemos contacto con dicha persona y ésta es consciente del trabajo que tiene que hacer.
Las primeras veces veréis que el timebox se os va un poco de las manos. No os preocupéis, será normal al principio. Una de las medidas que podréis usar para saber si esto va bien o no, será precisamente que cada vez tardaréis menos en terminar la reunión de refinamiento de backlog. Esto es porque el cliente vendrá con los deberes hechos de antemano.
Por si os interesan datos reales, las primeras reuniones de refinamiento de backlog para un equipo de 4 desarrolladores con 2 o 3 clientes o interlocutores nos llevaron de 2 a 3 horas. En la actualidad, raro es el día que pasamos más de 1 hora.
La semana entre la reunión de refinamiento de backlog y la Scrum Planning Meeting
Sin prisa pero sin pausa, seremos los encargados de estar un poco encima de que los responsables de rellenar la información en las tareas que no cumplieron con el DOR lo hagan. En caso de que necesiten ayuda para hacerlo, debemos asegurar que la reciban.
Lo ideal, si sois varias personas en el equipo y formáis parte de un equipo autogestionado o autoorganizado, es que vayáis rotando de «encargado». En nuestro caso, cada mes hay una persona encargada, una especie de portavoz que se encarga de todo lo que estáis leyendo en esta entrada, mientras el resto del equipo se centra al 100 % en el desarrollo.
Además, intentamos que «el encargado» nunca esté solo en las reuniones, siempre vamos en pareja.
Inter-Sprint
Quizás este sea el punto que más le cuesta entender y llevar a cabo a toda persona que comienza a ponerse serio con estos temas.
El día anterior a la Scrum Planning Meeting se hace una última revisión de las tareas que marcamos como inválidas por no cumplir con el DOR en la reunión de refinamiento de backlog.
Si alguna de las tareas sigue sin estar fina para el Sprint Backlog, se avisa al cliente de que toda tarea que no cumpla el DOR. Si no está lista para la Scrum Planning Meeting, se sacará del Sprint Backlog y se dejará en el Backlog hasta que lo cumpla.
¡Ojo! En este punto muchos clientes descubren que su prioridad no era tan prioritaria por el mero hecho de verse obligados a detallarla y desarrollarla. Incluso en ocasiones descubren que ¡ni tan siquiera era necesaria!
Pura magia
Vale, Ander ¿me estás diciendo entonces que le diga a mi cliente lo que es prioritario y lo que no y que haga y deshaga a mis anchas? No me van a dejar. No voy a poder. Me van a echar. Me van a matar.
¡No! El hecho de sacar una tarea que no cumple el DOR del Sprint Backlog no quiere decir que el cliente no vaya a poder meterla de nuevo en el Sprint Backlog. Una vez hayan completado el DOR y puede volver a colocarla si decide que la tarea sigue siendo prioritaria.
Lo único que estamos haciendo en este punto es educar al cliente para que, si de verdad una tarea es prioritaria, ponga tanto de su parte como espera que nosotros pongamos de la nuestra.
Una vez el cliente termine con el DOR, si sigue considerando que la tarea es prioritaria, está en su derecho de cambiar el alcance del Sprint Backlog. Repriorizar la tarea respecto a otras o cambiar una que considera menos prioritaria por otra. Para este proceso tendrá que contar (o no si no lo hay) con el PO.
El equipo de desarrollo se adaptará al cambio e iterará (¡joe, qué agile suena esto, ¿no?!) y, una vez se termine la tarea que tenga entre manos (¡y no antes!), cogerá la siguiente en prioridad. Esta podrá ser, perfectamente, aquella que al principio se había sacado del Sprint Backlog por no cumplir con el DOR.
Vale, a ver si lo he entendido bien…
¿Quieres que haga esto así, de sopetón, sin avisar, a lo loco? ¡Vaya película te has montado, Ander! De nuevo, ¡no!
Cada uno conoce a su cliente, a su empresa, a su proyecto, sus capacidades personales y un sinfín de variables. Lo que os puedo asegurar es que ningún cambio será un éxito si, como en el caso que nos ocupa, además de quitar tiempo al cliente, no se entiende el valor que puede aportar.
Mi recomendación personal es que, antes de nada, es decir, antes siquiera de hablarles de esto, de empezar a educarles, de empezar a hacer nada, intentéis mostrarles el valor de la propuesta. Por ejemplo, explicándoles claramente qué ganarán ellos y por qué compensará que dediquen tiempo a lo que les pides…
¡No hables, actúa!
Siguiendo con el ejemplo personal, yo suelo empezar a hacer todo esto de una forma informal y no oficial. Es decir, no organizo una reunión de refinamiento, pero consigo el contacto de mi cliente, me junto con él y le pido que me explique cada tarea que quiere que acometamos en el siguiente sprint de forma detallada.
Posteriormente, no digo explícitamente que dedicaré mi tiempo a eso, pero dedico mi tiempo a dejar fino el Sprint Backlog antes de la Scrum Planning Meeting (Inter-Sprint) y antes y después de la misma. Es decir, intento que todas las tareas del siguiente sprint cumplan con la primera versión del DOR que posteriormente, si todo va bien, acabaré modificando con el cliente o interlocutor.
Como bien dice uno de mis compañeros, un día ni quita ni pone rey… ¡aprovechadlo!
Dejo pasar el sprint y dejo que mis propios compañeros vayan notando que no necesitan contactar tanto con el cliente, que vean que saben exactamente cuándo una tarea está terminada porque cumple con ciertos criterios y, en definitiva, intento que el equipo de desarrollo vea el valor de ese trabajo.
En la Scrum Retrospective Meeting, y tras haber hecho un seguimiento continuo durante toda la iteración, hablo con el equipo de desarrollo sobre el tema. Este es el punto más importante. Si el equipo de desarrollo no ve valor, no sigas. No lo hables con el cliente. No la líes. Tenéis que estar de acuerdo, y mostrar esa seguridad y confianza al cliente.
Si el equipo de desarrollo está conforme, entonces pasamos a hablar al cliente de lo que hemos hecho, y vamos haciendo un seguimiento de, por ejemplo, si ha notado que le hemos «molestado» menos, si ha notado menos «ruido» por nuestra parte, etcétera.
Además, le enseñamos el Sprint Backlog y le invitamos a participar con nosotros, aún de manera informal, en el refinamiento del siguiente. Esta vez, lo hacemos a medias, y repetimos. Que pase toda una iteración, que vayan viendo el valor…
Poco a poco, si todos estamos contentos y de acuerdo en que puede aportarnos algo… ¡lo vamos haciendo oficial! La cosa es adaptar todo a cada proyecto, cliente, interlocutor, empresa…
Conclusiones
¡No seas vago, lee todo el artículo, saca tus propias conclusiones y coméntamelas por LinkedIn, Twitter o comentando en esta entrada! Pon en práctica esto y te aseguro que tú y los tuyos seréis más felices, pero no más guapos y posiblemente no tendréis más dinero (o sí, quién sabe).
¡Muchas gracias Ander por compartir tu conocimiento con nosotros! Gracias por ofrecer información útil sobre como mejorar nuestro día a día como desarrolladores, y estas invitado para volver cuando quieras a hablar de este y cualquier otro tema.