Empecemos con un poco de teoría. Cuando trabajamos sobre una implementación de Scrum tenemos dos restricciones: costo y tiempo. Sabemos que tenemos iteraciones de dos semanas y eso (en general) es inamovible. Pero… ¡nuestros pedidos nos llevan más tiempo que eso!, ¡no es realista!, ¡tenemos que hacer horas extras!
Este esfuerzo extra que obliga a nuestros equipos a volverse ninjas que todo lo resuelven, los termina desgastando. ¿Cómo hacemos entonces para poder avanzar y no caer en el proceso?
El alcance
Lo que conocemos como el triángulo de la triple restricción (costo, tiempo, alcance) nos dice que podemos restringir dos variables, pero no las tres… y Scrum es especialmente bueno liberando la tercera variable: alcance.
¿Qué quiere decir que el alcance sea variable? Cuando escribimos historias de usuario decimos que son una invitación a la negociación, en contraposición con los requerimientos definidos por casos de uso que no dejan mucho margen para negociación (o innovación) ya que son un contrato. Las historias de usuario por el contrario, invitan a la discusión y empoderan al equipo a tomar decisiones.
¿Qué tipo de decisiones podemos tomar?. Las historias (en general) vienen definidas por una narrativa (“as a [user] I want to [what] so that I can [value]”, check: https://www.mountaingoatsoftware.com/agile/user-stories), aquí se define el qué, el por qué y para quién, finalizando con un criterio de aceptación. Este criterio de aceptación es el resultado de la negociación entre el equipo y el Product Owner, es un ida y vuelta de lo que se puede hacer y lo que puede llevar más tiempo/esfuerzo. Luego el PO evalúa qué retorna más valor dado el esfuerzo del equipo. Es entonces que durante reuniones de refinamiento o planificaciones el equipo puede negociar ese criterio y con eso delimitar el alcance de cada historia de usuario.
Pero… nuestras historias de usuario siguen siendo demasiado grandes… y al final tenemos que hacer todo. Yo me preguntaría… ¿qué queremos lograr? Debemos recordar que: la historia de usuario tiene un objetivo claro, pero no habla sobre cómo implementarlo, por lo que (pensando con mente muy fría) podemos jugar un ajedrez. El ajedrez no se trata de comer piezas, se trata de capturar al rey, nuestro objetivo es claro y cuantos menos movimientos hagamos para capturar al rey mejores jugadores nos volvemos; por otro lado, una estrategia con demasiados movimientos puede llevar al error.
Incertidumbre
Hablemos entonces sobre acumular errores. Cuando estimamos historias de usuario usando story points, lo que estamos midiendo es esfuerzo, pero también medimos riesgo. Recordemos que Scrum trabaja sobre la incertidumbre de los pedidos que nos llegan, y cuanto más puntuamos una historia, más error acumulamos y con esto más riesgo de no completar lo comprometido.
¿Qué puedo hacer entonces para reducir este riesgo de no cumplir?
Divide & conquer
Hablamos del alcance, de los objetivos que queremos cumplir, de las estimaciones y su incertidumbre, ahora… ¿cómo puedo cumplir con mis compromisos?
Si queremos lograr nuestros objetivos tenemos que enfocarnos en lo que más importa, en lo que genera más valor o incluso a veces aquello que da poco valor pero requiere un esfuerzo menor. Debemos trabajar con nuestros product owners a la hora de definir la mejor estrategia que maximice el ROI. Pero volvemos al mismo tema, a veces el usuario necesita algo que requiere demasiado esfuerzo en construir, y teniendo en mente que debemos entregar algo de valor con cada historia, es ahí que debemos pensar en dividir la historia en piezas más pequeñas que sigan aportando valor… ¿pero cómo lo hacemos? En este artículo escrito por Christiaan Verwijs se pueden observar 10 estrategias para dividir historias de usuario (tl;dr: cheatsheet). Un ejemplo podría ser dividir una historia en los diferentes flujos que puede tomar el usuario. Pensemos en un Login, podríamos crear diferentes historias para:
- Login simple (usuario y contraseña). Se validan solo credenciales correctas, todo otro camino o posible error se despliega “no se pudo loguear”.
- Una historia para validar que usuario y contraseña no estén vacíos, desplegando el mensaje correspondiente.
- Una historia para integrar con un login de terceros.
Siempre buscamos entregar valor al final de una historia de usuario, por lo cual a la hora de dividir nos tenemos que preguntar: ¿qué es lo mínimo que puedo hacer para entregar valor a mi usuario?, pensemos en flujos, reglas, etc. Teniendo en cuenta que una historia de usuario es como una torta… nadie quiere recibir solo una capa de la torta (salvo que sea el dulce de leche :P), todos van a querer un corte vertical, es decir: no me sirve que se haga una parte del desarrollo del frontend si no tengo el backend.
Otra cosa que podemos buscar son esas historias compuestas de varios pedidos, ¿tenemos que hacer todo? La respuesta está en la conversación. Hablemos con nuestro PO y negociemos el alcance buscando ser eficaces (cumplir) y eficientes (maximizando el retorno de inversión de nuestro tiempo).
Sabremos cumplir
Como ya hemos visto hay herramientas que nos permiten cumplir con nuestros objetivos, teniendo en cuenta las necesidades de nuestros clientes (y usuarios). Cumplir nos lleva también a una mejor coordinación entre todas las partes involucradas, ya que si yo sé cuándo va a estar lista la funcionalidad, puedo organizar mi tiempo, y también me ayuda a saber qué esperar; puede ser que no sea una funcionalidad completa, pero sí algo que me ayude a salir del paso, y si no va a salir como yo espero también puedo hacer planes para mitigar esa necesidad.
