La definición mas simple de la Scrum Product Backlog es una lista de cosas que se necesita que esten listas para el proyecto. Esta reemplaza los artefactos tradicionales de especificación de requerimientos. Estos elementos puede ser de naturaleza tecnica o pueden ser usuario-centricos por ejemplo en forma de historias de usuarios. El propietario de la Scrum Product Backlog es el Scrum Product Owner . El Scrum Master y otros interesados contribuirán con ella para ampliar y completar el To-Do list.
Trabajar con luna Scrum Product Backlog no significa que el Scrum Team no pueda crear y usar otro(s) artefactos. Por ejemplo en artefactos adicionales puede ser un resumen de varios roles de usuario, descripciones de flujo, guías de usuario de interfaz, storyboards, o prototipos. Sin embargo esos artegacons no reemplazan la Scrum Product Backlog pero complementan del detalle de su contenido.
El Scrum Product Owner usa el Scrum Product Backlog durante el Sprint Planning Meeting para describir las entradas mas importantes al equipo, El equipo determina que elementos ellos pueden completar durante el siguiente Sprint.
Cada Scrum Product Backlog tiene ciertas propiedades que la diferencian de una simple to-do list:
Solo entradas que añaden valor
Cada entrada en la Scrum Product Backlog deben tener algún tipo de valor al cliente, Entradas sin ningún valor al cliente son desperdicio y no deberían estar presente de todas maneras. La Scrum Product Backlog puede incluir entradas para exploración de necesidades o varias opciones técnicas una descripción de ambos requerimientos funcionales y no funcionales, el trabajo necesario para lanzar el producto y otros elementos que convengan como la configuración del ambiente o arreglar defectos. Algunas tareas podrían no añadir valor directo a la funcionalidad. Sin embargo podrían añadir valor incrementando la calidad o reduciendo los incidentes a largo plazo
Documento vivo
La Scrum Product Backlog es cambiante a través de todo el proyecto. Si es necesario, nuevos requerimientos son añadidos y requerimientos existentes pueden ser modificados, definidos a mayor detalle o eliminados. Los requerimientos no permanecen fijos todo el tiempo, En su lugar el conjunto final de requerimientos es desarrollado de manera iterativa junto con el software resultante. Esto difiere a la manera tradicional de ingeniería de requerimientos, pero permite maximizar valor al cliente y minimizar el esfuerzo de desarrollo.
Diferente nivel de detalle
Los requerimientos en una Scrum Product Backlog tienen diferente granularidad. Únicamente esos requerimientos que serán implementados durante el siguiente sprint son definidos con mayor detalle los demás requerimientos puede tener menos granularidad. la simple razón para esto es que no tiene sentido invertir tiempo y esfuerzo en la especificación de esos requerimientos, ya que de todos modos la mayoría de esos requerimientos van a cambiar hasta que su implementación inicie.
No tareas de bajo nivel
La Scrum Product Backlog no debe contener a detalle la información del requerimiento. Idealmente el requerimiento final es definido junto al cliente durante el sprint. El rompimiento del requerimiento y su distribución es responsabilidad del Scrum Team.
La Scrum Product Backlog es ordenada
Todas las entradas son priorizadas y la Scrum Product Backlog es ordenada. El Scrum Product Owner con la ayuda del Scrum Team realiza la priorización. Valor agregado, Costo y riesgo son los factores mas comunes para la priorización. Con estas prioridades el Scrum Product Owner decide que sera lo próximo que estará listo.
Todas las entradas son estimadas
Todas las entradas en el Scrum Product Backlog tienen que ser estimadas acorde a la definición de aceptación por ejemplo con puntos de historia. Esta estimacion tambien puede ser utilizada para la priorizacion de entradas en el Scrum Product Backlog para el plan de lanzamientos.
Trabajando con la Backlog
La Backlog necesita una atención regular y cuidado, necesita ser administrada con cuidado. Al inicio del proyecto el Scrum Team y su Scrum Product Owner inician escribiendo todo lo que ellos piensan puede ser fácil. Esto es casi siempre mas que suficiente para el primer sprint.
Después de la configuración inicial el Scrum Product Backlog tiene que que ser mantenido en un proceso en marcha que comprende los siguientes pasos.
El Scrum product Owner es el responsable de estar seguro que el Scrum Product Backlog este en buena forma este es un proceso colaborativo, cuando se usa la metodología Scrum cerca del 10% del tiempo total del Scrum Team podría ser reservado para el mantenimiento del Scrum Product Backlog (discusión, estimación, etc.).
El mantenimiento colaborativo del scrum product Backlog ayuda a clarificar los requerimientos y crea un lazo con el Scrum Team.
Trabajar con luna Scrum Product Backlog no significa que el Scrum Team no pueda crear y usar otro(s) artefactos. Por ejemplo en artefactos adicionales puede ser un resumen de varios roles de usuario, descripciones de flujo, guías de usuario de interfaz, storyboards, o prototipos. Sin embargo esos artegacons no reemplazan la Scrum Product Backlog pero complementan del detalle de su contenido.
El Scrum Product Owner usa el Scrum Product Backlog durante el Sprint Planning Meeting para describir las entradas mas importantes al equipo, El equipo determina que elementos ellos pueden completar durante el siguiente Sprint.
Cada Scrum Product Backlog tiene ciertas propiedades que la diferencian de una simple to-do list:
- una entrada en la Scrum Product Backlog siempre añade valor al cliente
- las entradas en la Scrum Product Backlog estan priorizados y ordenados en orden consecuente
- el nivel de detalle depende de la posicion de la entrada en la Scrum Product Backlog
- todas las entradas estan estimadas
- la Scrum Product Backlog es un documento vivo
- no hay elementos de accion o tareas de bajo nivel en la Scrum Product Backlog
Solo entradas que añaden valor
Cada entrada en la Scrum Product Backlog deben tener algún tipo de valor al cliente, Entradas sin ningún valor al cliente son desperdicio y no deberían estar presente de todas maneras. La Scrum Product Backlog puede incluir entradas para exploración de necesidades o varias opciones técnicas una descripción de ambos requerimientos funcionales y no funcionales, el trabajo necesario para lanzar el producto y otros elementos que convengan como la configuración del ambiente o arreglar defectos. Algunas tareas podrían no añadir valor directo a la funcionalidad. Sin embargo podrían añadir valor incrementando la calidad o reduciendo los incidentes a largo plazo
Documento vivo
La Scrum Product Backlog es cambiante a través de todo el proyecto. Si es necesario, nuevos requerimientos son añadidos y requerimientos existentes pueden ser modificados, definidos a mayor detalle o eliminados. Los requerimientos no permanecen fijos todo el tiempo, En su lugar el conjunto final de requerimientos es desarrollado de manera iterativa junto con el software resultante. Esto difiere a la manera tradicional de ingeniería de requerimientos, pero permite maximizar valor al cliente y minimizar el esfuerzo de desarrollo.
Diferente nivel de detalle
Los requerimientos en una Scrum Product Backlog tienen diferente granularidad. Únicamente esos requerimientos que serán implementados durante el siguiente sprint son definidos con mayor detalle los demás requerimientos puede tener menos granularidad. la simple razón para esto es que no tiene sentido invertir tiempo y esfuerzo en la especificación de esos requerimientos, ya que de todos modos la mayoría de esos requerimientos van a cambiar hasta que su implementación inicie.
No tareas de bajo nivel
La Scrum Product Backlog no debe contener a detalle la información del requerimiento. Idealmente el requerimiento final es definido junto al cliente durante el sprint. El rompimiento del requerimiento y su distribución es responsabilidad del Scrum Team.
La Scrum Product Backlog es ordenada
Todas las entradas son priorizadas y la Scrum Product Backlog es ordenada. El Scrum Product Owner con la ayuda del Scrum Team realiza la priorización. Valor agregado, Costo y riesgo son los factores mas comunes para la priorización. Con estas prioridades el Scrum Product Owner decide que sera lo próximo que estará listo.
Todas las entradas son estimadas
Todas las entradas en el Scrum Product Backlog tienen que ser estimadas acorde a la definición de aceptación por ejemplo con puntos de historia. Esta estimacion tambien puede ser utilizada para la priorizacion de entradas en el Scrum Product Backlog para el plan de lanzamientos.
Trabajando con la Backlog
La Backlog necesita una atención regular y cuidado, necesita ser administrada con cuidado. Al inicio del proyecto el Scrum Team y su Scrum Product Owner inician escribiendo todo lo que ellos piensan puede ser fácil. Esto es casi siempre mas que suficiente para el primer sprint.
Después de la configuración inicial el Scrum Product Backlog tiene que que ser mantenido en un proceso en marcha que comprende los siguientes pasos.
- A medida que los nuevos elementos son descubiertos, son descritos y agregados a la lista . Los existentes son cambiados o removidos como sea apropiado.
- Ordenando el Scrum Product Backlog . El ítem mas importante debe ser movido al inicio.
- Se preparan las mas altas prioridades para el próximo Sprint Planning Meeting
- Re (estimando) las entradas en la Scrum Product Backlog
El Scrum product Owner es el responsable de estar seguro que el Scrum Product Backlog este en buena forma este es un proceso colaborativo, cuando se usa la metodología Scrum cerca del 10% del tiempo total del Scrum Team podría ser reservado para el mantenimiento del Scrum Product Backlog (discusión, estimación, etc.).
El mantenimiento colaborativo del scrum product Backlog ayuda a clarificar los requerimientos y crea un lazo con el Scrum Team.
Comentarios