Es una pregunta que suelo hacer a los equipos y que también me he tomado la libertad de hacer en algunos procesos de selección. Las respuestas suelen ser variadas. La más común: “el máximo posible de tareas de lo que se planificó”, otros me han dicho “las tareas técnicas”, y también, “¡todo lo que hay para el sprint! Incluso si eso implica hacer horas extra”.
Mi teoría respecto a esto es que existe una masificación del mindset de que “más es mejor”, o que “más entrega es igual a mayor productividad”. Propongo entonces lo siguiente: ¿Qué pasaría si “menos”, fuese en realidad “más”? Muchos equipos de Scrum (y organizaciones) tienen arraigada la idea de que entregar más equivale a mejor performance, o que tener una “velocidad estable” es tener un equipo con mejor desempeño.
El mito de la velocidad y la cantidad
Para ir por partes, comenzaré mencionando que está generalizada la práctica de querer “entrenar” al team para generar una velocidad “estable”, en general, en puntos de historia. Sinceramente, ¿en base a qué hemos pensado que esto habla de un equipo de alto desempeño o de que lo que se entrega con la velocidad “estable” genera un impacto en la organización?
Con esta forma de pensar, ¿en qué lugar dejamos el valor que queremos entregar en cada delivery?
Si entregamos mucho y a la “velocidad promedio”, pero todo eso es sólo deuda técnica, ¿es una buena performance? ¿Qué pasaría si todo un sprint backlog queda completo, pero no tenemos software funcionando?
Puede suceder que por tener un foco en la velocidad, en que el gráfico burndown baje o en que la cantidad de ítems entregados suba, el scrum team tenga mayor “foco en la tarea” que en la entrega de valor, pudiendo generar equipos mecánicos, con una visión de producto acotada y faltos de compromiso. Poniéndolo en términos prácticos, logrando una velocidad estable no necesariamente garantizamos la entrega de software funcional. Si vamos aumentando la cantidad de ítems entregados no necesariamente aumentamos también el impacto en valor de negocio. El gran error del “foco en la tarea” y en la “cantidad” hace aumentar el riesgo de que tengamos un equipo con altos niveles de stress que, aunque cumpla números de output, tenga además altas cuotas de deuda técnica.
Entonces, ¿sirven las métricas de output? ¡Claro que sí! Siempre y cuando estén orientadas a ayudar al PO en proyectar o acotar el time to market para el feedback temprano de usuarios con un software funcional y que impacte en las métricas de negocio definidas. También son una gran ayuda si se ocupan al servicio del equipo, para cuidar su salud en cuanto a carga (en una sprint planning, por ejemplo).
Démosle foco a lo que estamos haciendo
OK. Tenemos que los puntos de historia no son lo más importante en términos de entrega. La cantidad de PBIs tampoco. ¿Entonces? Pues, si estamos deduciendo bien, lo más importante a entregar cuando trabajamos con Scrum es software funcionando que genere valor al negocio, y para eso, es primordial dar foco al equipo mediante un sprint goal (objetivo de sprint).
En esto, es esencial el feedback del PO en cuanto a sus expectativas tanto dentro del sprint como de lo que se viene manteniendo un product backlog actualizado. También, es muy importante el empoderamiento del equipo para dar feedback oportuno sobre lo que es viable o no, tanto en lo técnico como en cuanto a capacidad.
Otro punto muy importante a considerar es que siempre los sprints vengan acompañados de un sprint goal, ya que “proporciona una guía al Equipo de Desarrollo acerca de por qué está construyendo el incremento (…). A medida que el equipo de desarrollo trabaja mantiene el objetivo del Sprint en mente. Con el fin de satisfacer el objetivo del Sprint, el equipo implementa funcionalidad y tecnología” (Scrum Guide). En otras palabras, gracias al sprint goal no sólo ayudamos al equipo a tener un norte, algo que le dé sentido a lo que se esté haciendo durante el sprint, sino que también eso ayuda al PO a visibilizar qué es lo que quiere ver como incremento, o como resultado de ese sprint. También, puede ser la guía del PO a la hora de interactuar con sus stakeholders para tomar decisiones, setear expectativas o negociar, por ejemplo.
El sprint goal es definido durante la sprint planning y todo el scrum team debe participar en la articulación de esta visión. Algunos ejemplos:
- Mostrar el total de proveedores facturados en los últimos dos meses
- Lograr perfilamiento para usuarios tipo editor, admin y super admin
Sólo para registro, comparto también, un “anti ejemplo”, donde hay “foco en la tarea” y no en la visión de producto:
- Terminar los ítems ASDF-3476 y ASDF-8765
- Resolver el bug de precarga de datos
Si no tienes incorporada esta práctica en tu equipo, te animo a desarrollarla. Verás cómo se genera mayor sinergia en el equipo, y los sprints realmente cobran mayor sentido y propósito. Enfoquémonos en un sprint goal que genere valor a nuestra organización, y complementemos con las métricas de output a la hora de hacer forecast de cara a stakeholders, o para ayudar al PO y al team en una sprint planning. Fomentemos en nuestros equipos la entrega de valor, recordando la calidad por sobre la cantidad.
