Plantillas Scrum: Pila de producto (Product Backlog)
La Pila de Producto (Product Backlog) es el instrumento metodológico del marco de trabajo Scrum, que se usa para listar las características (Features) o funcionalidades del software a desarrollar, para priorizarlas de acuerdo a las necesidades del área de negocio. Su contenido se desarrolla a partir de las historias de usuario identificadas por el dueño de producto (Product Owner).
La pila de producto permitirá tener visualización de las funcionalidades a desarrollar, priorizar las características del software según las necesidades del negocio, dejar registrado el esfuerzo necesario para desarrollar la historia y asignarla a una iteración (Sprint). Para ello, se deben seguir las reglas de administración de la pila de producto.
¿Quien se encarga de mantener el Product Backlog?
En Scrum, el encargado de elaborar los elementos del Product Backlog es el Product Owner, aunque Scrum permite que este se apoyo en integrantes del equipo de desarrollo que puedan colaborar con el.
El Scrum Master tiene la tarea de ayudar al equipo Scrum (Product Owner y desarrolladores) a aplicar técnicas para que los elementos del Product Backlog sean claros y concisos.
Descripción de la plantilla
La Pila de Producto (Product Backlog), se rellena a partir de las historias de usuario identificadas por el dueño de producto (Product Owner).
Asumiendo que se ha asignado un código a cada historia, se debe crear un renglón para cada historia en la pila de producto. Para mejor referencia se sugiere usar el mismo código y enunciado de historia.
A continuación el contenido de la plantilla:
- Identificador (ID) de la Historia: Código que identifica a la historia de forma unívoca, una vez asignado, no debe ser re-usado en otra historia, ni siquiera si es descartada. El código identifica la historia en otros documentos, como por ejemplo la plantilla de historias de usuario.
- Enunciado de la Historia: Nombre de la historia, el cual debe ser el mismo que se utiliza en otros documentos. Se puede utilizar el formato siguiente:
Como un [Rol], Necesito [Descripción de la Funcionalidad], con la finalidad de [Razón o Resultado]
- Alias: Título de la historia alternativo a la descripción, que servirá para identificar más fácilmente la historia sin tener que repetir todo su enunciado. Se puede utilizar por ejemplo el nombre de la funcionalidad o requerimiento que se pretende desarrollar.
- Estado: Identifica los posibles estados de la historia durante su ciclo de vida:
- Vacío: La historia fue identifica pero aún no ha sido asignada a una iteración.
- Planificada: La historia fue asignada a una iteración y aún no ha comenzado su ejecución. Puede tener este estado incluyendo en la iteración donde está planificado ejecutarla (pero que aún no ha comenzado).
- En Proceso: La historia fue seleccionada por el equipo y está en proceso de desarrollo (en ejecución).
- Hecho (Donde): La historia fue desarrollada. Es importante clarificar la definición de “Hecho” con el equipo de trabajo. “Hecho” no sólo incluye el desarrollo sino la integración y pruebas integrales del Software. Una historia hecha puede presentarse al dueño de producto para sus pruebas de aceptación.
- Descartada: Se determinó que la historia ya no es relevante, su contenido se incluyó en otro grupo de historias o fue cancelada.
- Dimensión / Esfuerzo: Medida del esfuerzo (tamaño) que implica desarrollar la historia, existen distintos métodos para medirlo, un ejemplo es los “puntos de historia” una medida de complejidad no necesariamente relacionado con jornadas o días. Otra forma de medirlo es con días o jornadas ideales.
- Iteración (Sprint): Iteración o Sprint al que se asigna la historia. Esta asignación puede cambiar en cada iteración donde se haga la revisión de la pila de producto (Product Backlog Review), según las prioridades indicadas por el dueño de producto. Por medio de este campo se puede crear un “Plan de Salidas a Productivo” (Release Plan).
- Prioridad: Siguiendo el marco de trabajo ágil y Scrum, se le deben asignar prioridades a las historias, según las instrucciones del dueño de producto (ProductOwner). De esta forma pueden ordenarse. Las historias de mayor prioridad deben ser las que agregan más valor al negocio, y deben ser originadas en sus necesidades.
- Comentarios: Comentarios o detalles relacionadas que expliquen la historia. Para definiciones de mayor longitud deben usarse documentos externos, por ejemplo la plantilla de historias de usuario.
