.

El Backlog de Producto

Cuando trabajamos con Scrum, lo primero que debemos hacer es crear el Product Backlog” o Backlog de Producto en castellano. Este no es más que la lista de características que hemos pensado para el proyecto. Es lo mismo que si estuviéramos hablando de la definición del alcance.

Recuerda que Scrum no es predictivo, por lo que no planea por adelantado; en lugar de crear un completo y detallado Backlog del Producto, simplemente añadimos los suficientes elementos para los próximos ciclos (también conocidos como iteraciones o Sprints). A continuación, empezamos inmediatamente con el primer ciclo y mantendremos el Backlog del Producto continuamente actualizado (“adaptativa”). Esto significa que iremos añadiendo elementos conforme surjan.

Tablero del Backlog de Producto

La simplicidad es uno de los principios ágiles. Por ello, preferiremos crear el Backlog de Producto en un tablero físico, en lugar de utilizar software. Para capturar los elementos del Backlog de Producto, emplearemos tarjetas o notas adhesivas. En una ocasión empleamos tantas notas adhesivas que alguien me preguntó, muy en serio, si 3M había sido el inventor de Scrum!

Backlog del Producto en Scrum

Bien, entonces en tu opinión ¿Cómo deberían ser los elementos del Backlog Producto? Por ejemplo, ¿estaría bien que su contenido fuera algo como “crear el diseño de la solución”?… No, no estaría bien, porque eso es predictivo. Tenemos que diseñar el producto de forma iterativa.

El Backlog de Producto debe estar compuesto únicamente por funciones; cosas que el cliente pueda entender, y cuando se han desarrollado, pueda probar y darnos su opinión. Es por eso que los elementos del Backlog de Producto deben tener dos características:

  • Deben ser no técnicos, porque los usamos para comunicarse con el cliente y la comprensión mutua es la clave de nuestro. Normalmente el cliente no es o tiene un carácter técnico. Así pues, no utilizamos una documentación sofisticada para hablar con el cliente sobre la definición del producto; necesitamos que se sienta cómodo y colabore.
  • Deben ser independientes entre sí, porque queremos ser capaces de ordenarlo libremente en función de su valor de negocio (importancia) y centrarnos primero en los elementos más importantes.

Una muy buena opción para redactar los elementos del Backlog de Producto es utilizar “historias de usuario”. Pero, ¿qué es una historia de usuario?.

Historias de usuario

Como te comentaba una buena manera de redactar elementos del Backlog de Producto es utilizando “historias de usuario”. Este es un ejemplo de una historia de usuario:

“Como usuario final, quiero obtener un informe sobre la actividad de mi cuenta, para comprobar si todo está bien”.

Sí, es my breve. ¡Pero es que esa a es la clave! En Agile preferimos tener objetos pequeños, ya que hace más fácil el control del proyecto. Además, durante una iteración también podemos producir o completar al 100% varios artículos pequeños, mientras que si los artículos son grandes, es difícil decir saber cuándo se completan realmente.

La plantilla genérica para una historia de usuario es la siguiente:

Como (rol)… , quiero (función)… , para (propósito)…Historia de ususario

El tercer elemento de la plantilla es opcional y no lo mencionaremos cuando sea obvio. Fijae en el siguiente ejemplo:

Como administrador del sistema (rol), quiero poder restablecer las contraseñas (función), para… (no es necesario mostrar el propósito).

¡Es tu turno! ¿qué piensas acerca de la siguiente historia de usuario: Como administrador del sistema, quiero tener una base de datos SQL para el sistema.

¿Te parece que es una historia de usuario correctamente formulada?

No. La segunda parte de la historia de usuario debe ser de una acción; se trata de hacer las cosas, en lugar de tener las cosas.

Hasta la próxima.

Saludos,

JLVG

QuieresCursoGratisImagen700X150_3

Otros lecciones de este curso

01. Curso Gratis de Introducción a Scrum

02. Entonces… ¿qué son los sistemas predictivos y adaptativos?

03. El Backlog de Producto

04. El scrum team: el Dueño del Producto

05. Los sprints

06. La estimación de los elementos de Backlog de Producto

07. Puntos de historia y velocidad

08. Póker de Planificación

09. El scrum team: el Scrum Máster

10. ¿Quien es el Project Manager en scrum?

11. ¿Cómo se desarrolla un sprint?

12. El desarrollo del sprint: medición y cancelación

13. Eventos scrum: el Scrum Diario

14. Eventos scrum (II): la Retrospectiva del Sprint

15. Artefactos scrum (I)

16. Artefactos scrum (II)

17. La “definición de completo”

18. ¿Cómo funciona scrum?

19. Certificaciones scrum

20. Referencias

2 respuestas a “El Backlog de Producto”

  1. Juan Irigoyen dice:

    Buen Post, solo un apunte, yo creo que la mayor parte de las veces es mas adecuado utilizar un tablero Kanban virtual al estilo de http://kanbantool.com/, hay varias herramientas gratuitas que permiten hacer esto, los backlog de algunos programas suelen hacerse muy grandes y al final acabas por perder visibilidad pues los posit se van acumulando unos encima de otros, además hay muchas funciones que nos permiten ver el histórico de cada backlog y las tareas en las que se descompone, filtrar por el trabajo de cada usuario y un sinfín de tareas mas, además de permitirnos trabajar con equipos desubicados, por otro lado somos un poco mas ecológicos, no olvidemos que somos informáticos, podemos utilizar el Abaco en lugar de Excel pero esto no tiene mucho sentido. 🙂

    Un saludo.

    Aunque lo cierto es que el tablero Kanban tiene su

    • Juan Luis Vila Grau dice:

      Hola Juan!

      Muchas gracias por el comentario, y por el link a la herramienta. Es cierto que en algunas ocasiones el backlog de producto puede crecer hasta hacerse inmenso, y también que una aplicación informática puede ayudarnos a gestionarlo mejor. También me ha gustado el punto ecológico que has señalado. No obstante, la visibilidad y transparencia que nos ofrece un tablero físico es para mi el principal punto a su favor. Además, cuando empezamos con scrum es mejor hacerlo desde lo básico.

      Saludos cordiales,

      JLVG

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR