En el primer post de la serie hablábamos sobre la terminología ágil y del Product Backlog de manera breve, te dejamos el enlace “Jira Agile y Scrum, cómo combinarlos de manera correcta (1/4): Terminología ágil y el Product Backlog«.
En esta segunda parte vamos a explicar las buenas prácticas a tener presentes sobre el Product Backlog (recuerda, Backlog, sólo, en terminoloía JIRA Agile) y la manera correcta de gestionarlo en JIRA Agile según sus patrones más destacados y, al final, una de «confusiones frecuentes».
Y, ojo, todas estas prácticas no sólo se aplican a JIRA Agile, sino que se aplican a la gestión ágil en general.
Buenas prácticas de carácter general para el Product Backlog a aplicar a JIRA Agile
Empecemos primero con algunas cuestiones generales, que aplican a JIRA Agile (o a cualquier gestión ágil).
Resumiendo mucho, un Product Backlog según se describe en “Agile product management with scrum: Creating products that customers love” y en «Gestión de proyectos ágil» tiene cuatro cualidades:
1. Detallado adecuadamente, lo que suele ir de la mano con la prioridad de sus ítems, ya que normalmente los que tienen una prioridad mayor… se describirán con más detalle (evitamos detallar mucho incidencias que sabemos que por ahora no se harán). Es decir, yendo a JIRA Agile, que las incidencias (normalmente tipo historia) de la parte superior del Backlog serán las más detalladas.
2. Estimado, ayudando a dar prioridad y a planificar. Para ello, veremos en siguientes post los direrentes mecanismos que tiene JIRA Agile para estimar, mientras puedes darle al anterior enlace para ver cuestiones generales de estimacion ágil.
3. Emergente, las necesidades y sus contenidos cambian. A diferencia de un sprint backlog, con tareas, ya hablaremos, un product backlog puede cambiar continuamente.
4. Priorizado, apareciendo los elementos más importantes y de mayor prioridad en la parte superior, relacionado con el punto 1.
Dos patrones del Product Backlog importantes a tener en cuenta al usar JIRA Agile
Como comentamos en el post “Un catálogo de patrones para Scrum y agildad”, un patrón es una buena solución para un problema recurrente en un contexto específico. Eso como definición general.
Veámos una breve descripción de dos de los patrones más relevantes de aplicación al Product Backlog y que, cómo no, también debemos tener presentes en lo que respecta a JIRA Agile.
1 – El cambio es gratis, con este patrón se apoya la libertad de cambiar los ítems el Product Backlog (PBIs), en nuestro caso incidencias (normalemnte tipo historia), en cualquier momento del desarrollo. No se permiten cambios, por lo general, en las tareas acordadas a realizar en el Sprint. Los «stakeholder», siempre por medio del product owner, pueden intercambiar un requisito nuevo por cualquier PBI existente de igual o menor valor.
El Product Backlog por tanto es dinámico, podremos añadir incidencias (que ya sabemos que pueden ser de tipo historia de usuario) a lo largo del tiempo, siempre y cuando no modifiquemos un Sprint ya iniciado. Pero, respecto a esto JIRA Agile no pone restricciones, ya que nos permite, por ejemplo, añadir incidencias a un Sprint ya iniciado y eso no es apropiado, salvo que pasen por los criterios acordados con el Product Owner.
Como ves, aquí es importante, mucho, el papel que juega el Product Owner, que ya hemos tratado muchas veces, te dejamos algunos post sobre el tema (qué es crítico):
- Una infografía (en español) sobre el Rol del Product Owner
- Claves para implantar el rol de Product Owner, uno de los roles clave en un desarrollo ágil (1/2)
- La página del product owner
2 – El elemento de mayor valor será el primero, segundo patrón que tratamos aquí, los ítems del Product Backlog tienen diferentes valores y estimaciones, a la hora de gestionar el valor en un entorno que cambia con frecuencia se deben poner primero los elementos con mayor valor.
En JIRA Agile, se pueden arrastrar las incidencias en el Backlog, ordenarlas, así las incidencias con mayor prioridad estarán en la parte superior del Backlog.
Confusiones frecuentes en JIRA Agile: Product Backlog frente a Pizarras Clásicas
Antes de terminar este segundo post, os dejamos una de «confusiones frecuentes».
Es frecuente que nada más entrar en JIRA Agile, las primeras ocasiones lleguemos a las pizarras clásicas (ver ejemplo, en la figura de abajo) desde la pestaña Agile y escogiendo la opción Clásicas, o desde el mismo proyecto, accediendo a la información general.
Aquí tienes una imagen de la pizarra de planificación clásica, de nuestro proyecto Space Invaders.
En muchas ocasiones se utilizan pizarras como Product Backlog, este es el caso de la pizarra que se crea por defecto, recibe el nombre de pizarra de planificación clásica.
Nos encontramos frente a una práctica que puede conducir a error, ya que con el uso de una pizarra clásica no podemos dar soporte a múltiples proyectos de JIRA Agile, no podemos obtener gráficos de cómo terminan nuestros Sprints y tampoco nos puede mantener informados de los cambios que se van estableciendo en nuestras incidencias.
Es más, hoy en día, el mismo Atlassian informa de que las pizarras clásicas ya no son mejoradas activamente y no nos recomienda su uso para proyectos nuevos.
Con esto terminamos esta segunda entrega de JIRA Agile, el próximo miércoles os dejaremos la tercera parte, y en ella veremos el corazón de JIRA: las incidencias.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Os dejo el enlace del siguiente post 😉
https://www.javiergarzas.com/2014/07/jira-agile-scrum-3.html
¿Cómo se puede dar soporte a múltiples proyectos en un mismo Sprint?