Tipos de Items en Scrum

Muchos equipos creen que en Scrum realizamos Historias de Usuario como medio para obtener los requisitos que el equipo realiza. De hecho, hay equipos que piensan que usando el típico esquema Guerking de “cómo-quiero-para” ya son ágiles. Scrum tiene su propuesta de centrarnos en valor y las Historias de Usuario tienen sentido cuando hay usuarios que nos pueden contar su historia. ¿Y todo el resto del trabajo que tenemos que realizar? Pues para eso existen diferentes tipos de Items que podemos incorporar a nuestro Product Backlog y que nos permite organizarnos para generar valor. ¡Lo estudiamos! 

Las Historias de Usuario NO son parte de Scrum

Hace unos años me senté a trabajar con un Product Owner sobre los próximos pasos que íbamos a ejecutar. Empezamos a hablar sobre Scrum y surgió la siguiente conversación:

• “por que las Historias de usuarios en Scrum…”  – dijo el Product Owner
• A lo que le contesté, “perdona, ¿sabes que las Historias de Usuario NO son de Scrum?”. 
• Giró la cabeza y me puso cara de sorpresa, “¿cómo?” hace años me dijeron que eran de Scrum”. 
• “Mira lo que pone en Scrum, no hay ninguna referencia a las Historias de Usuario”

Tras esto, empezamos a trabajar en lo que realmente propone Scrum y cómo utilizar el Product Backlgo para maximizar valor. 

Product Backlog Items

En Scrum existe el artefacto Product Backlog que sirve de soporte para organizar el trabajo que queremos realizar. El Product Backlog está ordenado para maximizar valor (que no significa que sea ordenador solo por valor). El Product Backlog está compuesto por Items (Product Backlog Items o PBIs) que representan los diferentes trabajos que debemos realizar. 

Es importante entender que, un PBI debería ser capaz de generar valor por sí mismo o, al menos, ser capaz de estar completo. Por ejemplo, tener un PBI que fuera “pantalla front” no sería correcto, al necesitar de la capa back o base de datos. Es decir, un PBI debe ser completo en su esencia. 

Lo ideal es que cada PBI nazca de una conversación entre el Product Owner y los Developers o, en su defecto, que se refine conversando entre ambas “partes”. Además, deberían de ser de un tamaño pequeño en la medida de lo posible. 

Recomiendo definir muchos tipos de PBIs para poder medirlos. Al finalizar un Sprint podemos medir el porcentaje que hemos dedicado a cada uno de ellos en términos de entrega. De esta manera podemos comprender a qué se dedica el equipo. Un equipo que dedica un 30% de su entrega a arreglar bugs puede ser un problema si es de reciente creación o con un producto que se está haciendo hueco en el mercado. 

Analizamos ahora los diferentes tipos de PBI que me he encontrado y cuándo utilizarlos. 

Historias de Usuario

Es el más habitual y el que más equipos utilizan. Las Historias de Usuario se plantean desde la perspectiva del usuario, es decir, a diferencia de los requisitos tradicionales no hablamos de lo que hace nuestro sistema sino de cómo el usuario usa nuestro sistema. 

Las Historias de Usuario son útiles cuando existe esa interacción con los usuarios, generalmente con pantallas o interfaces de usuario. Lo ideal es que sean escritos por los propios usuarios o personas cercanas a ellos. Recordemos que si usamos el lenguaje Gherkin, podremos incluso hacer TDD o BDD con ellos. Ahora bien, no deberíamos escribir cualquier PBI en formado Historia, sobre todo si no hay usuarios de por medio. 

Bugs o Errores

Los bugs o errores son uno de los tipos más habituales. Generalmente se usan para mostrar errores que se han producido y han detectado los usuarios del producto. Los bugs se pueden clasificar por diferentes categorías: tipología, criticidad e impacto. Para mí, tener una buena definición de errores es clave para sacar estadísticas de nuestra calidad de entrega y de servicio. 

Además, es esencial tener una política de resolución de errores para saber cuándo debemos atenderlos o esperamos al siguiente Sprint para incorporarlos. Deberíamos evitar que la resolución de bugs se haga a través de “Kanban” ya que deben ser parte de nuestro trabajo con el que debemos convivir. Si el número de bugs nos impide entregar más valor debemos hacer una reflexión sobre nuestra velocidad de entrega y la calidad de la misma. 

Defectos o Errores Internos

Hay otro tipo de errores que se suelen mezclar con los bugs. Cuándo una persona del Scrum Team detecta un fallo antes de que llegue a los usuarios. En estos casos, podemos diferenciarlo con un tipo Defecto que, siendo un fallo igualmente, no tiene un origen externo o de usuario final. Estos defectos pueden ir asociados a un determinado PBI desarrollo previamente.

Debemos evitar que los Defectos aparezcan porque un “departamento de calidad” o similar se encargue de hacer pruebas al final del desarrollo. Deberíamos de hacernos responsables como Developers de la calidad de nuestro código, por ejemplo, con pruebas cruzadas. 

Tareas Técnicas

Una Tarea Técnica es un trabajo que suele nacer de los Developers. Son tareas que suelen tener una difícil traducción en valor directo pero que son necesarias o de soporte. Identificar Tareas técnicas es clave para que el Product Owner entienda que ciertas labores deben cubrirse aunque un usuario no lo haya solicitado.

Por ejemplo, si queremos almacenar tarjetas de crédito en nuestra base de datos tendremos que cumplir ciertas restricciones técnicas que, en el caso de España, nos exige el Banco de España. 

Casos de Uso

Los Casos de Uso son una técnica más tradicional de toma de requisitos. Generalmente, los Casos de Uso ponen el foco en lo que hace el Producto. Podemos tener Casos de Uso si los necesitamos o si consideramos adecuado su uso. Scrum no tiene instrucciones o reglas sobre cómo tomar requisitos, se queda abierto a decisión del Scrum Team.

Si consideramos que necesitamos tomar requisitos en forma de Casos de Uso, ¡adelante! Recordad que un equipo no se mide por su calidad tomando requisitos sino por su capacidad de entregar valor. 

Mejora Técnica

Las mejoras técnicas son tareas técnicas sobre algo existente que queremos mejorar. Por ejemplo: una actualización de una librería, un nuevo tipo de securización o un cambio en base de datos. 

Las mejoras técnicas sirven para reducir el coste de mantenimiento de nuestro código y es importante incorporar alguna de ellas en nuestro trabajo de Sprint para evitar convertir nuestro código en un spaghetti inmanejable que nos reste capacidad de entrega de valor. 

Experimento o Spike

A veces, tendremos dudas sobre un determinado PBI que no sabremos abordar por algún motivo técnico. Podemos usar el elemento Spike o Experimento que sirve para investigar una determinada tecnología o problema técnico. Hay que tener cuidado con los Spikes porque no se pueden estimar, en vez de eso, se entienden como una inversión que hacemos para aclarar algún concepto. 

Es clave evitar que todo PBI venga siempre precedido de un Spike porque podemos convertir cada uno de ellos en un mini-waterfall. Los Spikes se deben usar con mesura y para hechos que realmente sean difíciles. 

Reunions o Meetings

Hay equipos que miden el número de reuniones que tienen por Sprint. Para hacerlo, podemos crear el item Reunión que recoja cada reunión que realizamos en el tiempo. Además, podemos incluir información sobre la misma: tiempo, personas, objetivo… Esto puede servir en la Sprint Retrospective para analizar si estamos dedicando demasiado tiempo a reuniones y si podemos encontrar maneras de generar valor sin tanta reunión. 

Estimaciones

Cuenta la leyenda que el primer equipo que aplicó Kanban al mundo del desarrollo software fue en la India gracias a David Andersson. Este equipo realizaba dos tipos de tareas: desarrollos e incidencias (errores/bugs). Sin embargo, el equipo detectaba que invertía mucho tiempo en estimar fruto de la burocracía interna. Así que, para explicitar este hecho crearon el item “estimación” por parte de su trabajo. De hecho, al medirlo, vieron que dedican un 30% del tiempo a las mismas. ¡Estimar no aporta valor! Gracias a ello, pudieron eliminarlas y usar otro tipo de métricas de predictibilidad. 

Épicas, Temas o Features

Dentro del Product Backlog podemos tener diferentes tamaños de items. Podemos tener épicas o temas que representen conjuntos de items que debemos obtener al trabajar sobre ellos. Esto sirve para visualizar el trabajo de “dividir” futuro que tendremos que acometer. Por ejemplo, si estamos realizando una aplicación para dar de alta tarjetas de créditos por personas físicas, podemos tener la épica “persona jurídica” para saber que, en algún momento, debemos introducir todos los items relacionado con esa épica. 

Aprendizaje

Algunos equipos incluyen el tipo “aprendizaje” para poder dedicar tiempo al mismo. Debemos entregar valor en el presente pero también en el futuro. Para ello, debemos estar bien formados y lleva tiempo. Un equipo puede tener items para recordar que tienen que dedicar tiempo a aprender. De esta manera, podemos medir nuestra dedicación a aprendizaje con respecto al total de capacidad que tenemos. 

Tipos específicos de items

Muchos equipos crean tipos de items en función de su contexto. Por ejemplo, si tenemos un Departamento de Recursos Humanos podemos tener un item que sea “candidato” en referencia a un proceso de selección y otro item que sea “promoción” de cada a una subida salarial que hay que gestionar. En NeuronForest hemos creado un tablero para trabajar los potenciales clientes y cada item es de tipo “cliente” con información de cada uno de ellos. 

Podemos querer dividir el trabajo en tipos específicos que nos permita medir y obtener estadísticas. Es mejor dividir y medir que tener un tipo único que nos aporte poca información. 

Deuda Técnica

Podemos considerar Deuda Técnica aquellos items que representan elementos que están fallando o que deberían de mejorar. A veces, ocurren por cambios conscientes (hemos bajado la calidad para llegar a una entrega) y otras veces aparecen por sorpresa. A mi me gusta ver la Deuda Técnica como trabajo que deberíamos haber incorporado y no lo hicimos. Aún así, podemos considerar también deuda los errores, defectos e incluso ciertas tareas técnicas. 

La Deuda Técnica debe servir para entender que estamos corriendo demasiado y que, de no resolverse o reducirse, podemos acabar prestando un mal servicio y finalmente reduciendo el valor de nuestro producto. 

La Deuda Técnica puede ser un item propio o una etique para diferentes tipos de items que hemos visto antes. 

Y tú, ¿qué tipos de Items utilizas?