Product Backlog
Dentro del entorno de trabajo de Scrum, y de la planificación ágil, existe un documento que reúne todas las actividades que se deben realizar para que el producto final satisfaga las expectativas del cliente; a esta lista priorizada se le conoce como Product Backlog.
Definiendo qué es el Product Backlog, debes saber que su creación está en manos de Product Owner y contiene, de forma priorizada, cada elemento que aporta valor al producto final.
Por lo general, estas actividades contenidas en el Product Backlog se expresan con historias de usuario, usando al consumidor final como punto focal para que cada parte del producto satisfaga una necesidad, afectando positivamente el valor y la calidad del producto.
Entendiéndose como producto un objeto físico o digital, como una aplicación.
El Product Backlog puede, y debe, contener todas las actividades, incluso si el desarrollo se demorará años en finalizar.
Aun así, no es obligatorio que estén definidas todas las historias antes de implementar el método Scrum.
Mientras existan actividades por desarrollar en cada Sprint, el Product Backlog se puede ir nutriendo según avanza el tiempo.
Por lo general, se le da prioridad a lo que necesite al cliente y a lo que suponga más trabajo.
Como resultado de cada Sprint, el Product Backlog puede ir agregando historias con respecto al diseño y la funcionalidad del producto final.
Un aspecto importante de este documento es que no solo incluye tareas técnicas o de desarrollo que se deben completar para el producto, sino incluso todas aquellas actividades para la adquisición de nuevo conocimiento que mejore las habilidades del equipo de desarrollo.
Elementos que forman parte del Product Backlog
En el Product Backlog, estos elementos siempre deben estar presentes:
Features o características
En Features o características se incluyen todas aquellas actividades que suman al diseño o funcionalidad del producto desarrollado.
Podríamos decir que estas son actividades tangibles que le dan valor al producto.
Por ejemplo, cada una de las etapas del proceso de compra en una aplicación, es una característica de ese producto.
El desarrollo de la interfase de un videojuego es otra característica o feature.
Por lo general, estas son las actividades que se ponen a prueba al finalizar cada Sprint para ser aprobadas por el Product Owner.
Bugs o errores
Los bugs son errores que se van encontrando en el desarrollo del producto y deben agregarse como una actividad dentro del Product backlog, así se garantiza su solución en los próximos Sprints.
Mi sugerencia general es que se incluyan estas actividades solo cuando sean detectadas al finalizar un Sprint.
Si el desarrollo de una característica está en proceso y el bug se puede solucionar como parte de este, no es necesario crear una nueva actividad, al menos que la solución del problema requiere actividades muy complejas que no se puedan incluir en el flujo de la actividad en curso.
Technical work o trabajo técnico
El trabajo técnico está conformado con acciones específicas que se desarrollan para que el equipo de trabajo realice las tareas de desarrollo.
Puede ser tan sencillo como exigir que todos actualicen la versión del sistema operativo, o de un programa en específico, hasta la actualización del hardware para que el producto se desarrolle en las mejores condiciones posibles.
Knowledge acquisition o adquisición de conocimientos
La adquisición de conocimiento agrupa toda la base teórico-práctica con la que el equipo desarrolla un producto.
Se me ocurre un ejemplo muy sencillo como puede ser el estudio de las tecnologías disponibles para la selección de la que mejor se adapte al proceso o la comparación de herramientas o metodologías que hagan más eficiente el trabajo.
¿Qué son las historias de usuario?
Es importante definir qué son las historias del usuario o User Stories ya que esta es la manera en la que describimos las actividades en el Product Backlog aplicando la metodología Scrum.
Una historia de usuario es una pequeña descripción de cada requisito del cliente.
Una de las prácticas más comunes y recomendadas a la hora de crear las historias de usuario es que se toma en cuenta el rol, la función y el resultado esperado de cada funcionalidad que se está desarrollando.
No solo se define la historia, sino que se acuerdan los criterios de aceptación, es decir, en qué punto del desarrollo se puede decir que el resultado satisface la historia.
Por lo general, se define hasta 4 acuerdos de aceptación por historia y entre estos acuerdos se incluye el comportamiento que se espera de cada evento.
Como en Scrum se trata de maximizar el valor del resultado aportado al cliente, a la hora de definir la historia es importante definir de manera concisa qué beneficio aporta al desarrollo en su conjunto y al cliente en particular.
Los roles de las historias pueden ser muchos, pero siempre están basados en el usuario final del producto.
Un ejemplo de una historia de usuario
Como comprador (rol) quiero ver la lista de productos en mi cesta de compra (expresa la actividad que espera poder realizar) antes de pagar, para poder eliminar lo que no quiero y verificar cuál es la cantidad final de la compra(esto explica la razón u objetivo por lo que quiere realizar la acción)
Cuando el equipo de desarrollo recibe esta historia, tiene una idea más clara de lo que necesita desarrollar.
En este caso, los criterios de aceptación girarán en torno a la respuesta gráfica en la aplicación o página Web y qué tan sencillo es eliminar un producto.
Un criterio de aceptación puede ser que incluya la imagen del producto y botones para que se cumplan con las expectativas de una buena experiencia de usuario.
Product Backlog versus historias de usuario
La diferencia principal entre ambos conceptos es que uno contiene al otro. Dentro de un Product Backlog pueden existir distintas historias de usuarios.
Ahora bien, no debe confundirse historia de usuario con actividad, ya que una historia, como la que definimos anteriormente, puede incluir distintas actividades.
Las actividades son las que se verifican en las Daily Meetings durante el Sprint.
Asimismo, es importante destacar que existe una diferencia entre trabajar Scrum solo con un Product Backlog y hacerlo definiendo historias.
Por ejemplo, te comento:
Cuando se definen actividades sin historias es más difícil reconocer el punto final de cada actividad, asimismo, es más complicado entender qué le da valor al producto.
Cuando se definen historias se contempla todo lo que un usuario quiere hacer con el producto y, por ende, es más sencillo obtener como resultado un producto que satisfaga sus expectativas.
Ejemplos de Product Backlog
Es común que el Product backlog se cree a partir de historias.
Debido a que la creación de estas historias tiene un formato definido, se suele hacer una tabla que incluya la importancia de la historia y las columnas del rol, el deseo y el objetivo, además de una columna con los criterios de aceptación.
En el caso de un ejemplo de Product Backlog más habitual, podemos decir, que las historias o actividades se dividen según 4 tipos de prioridades.
- Elementos que no pueden faltar, aquí se incluye todo lo que sea crucial para el desarrollo del producto. Estas actividades tienen máxima prioridad, pues constituyen el esqueleto del proyecto.
- Elementos importantes, pero no imprescindibles, son los que le siguen en importancia a los primeros y suelen ser actividades derivadas de las primeras.
- Elementos que podrían incluirse. En esta categoría se contemplan oportunidades de mejora del producto, pero no son prioritarias, por lo que su desarrollo es condicional, en función del tiempo disponible y capacidad disponible así como otros criterios.
- Otros elementos opcionales. Son elementos que se pueden hacer, es decir, el equipo está en la capacidad de desarrollarla, pero no necesariamente aportan valor al producto. Por lo general, estas actividades se evitan en el desarrollo de productos ágiles si suponen desperdicio de tiempo o de dinero.
