Diferencia entre revisiones de «Backlog Del Producto»
De Dos Ideas.
(→Una técnica de priorización) |
|||
| (No se muestran 9 ediciones intermedias de 3 usuarios) | |||
| Línea 1: | Línea 1: | ||
[[Category:Scrum]] | [[Category:Scrum]] | ||
| + | |||
| + | == Qué es el backlog o pila de producto? == | ||
| + | |||
El backlog (o pila) del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario. | El backlog (o pila) del producto en [[Scrum]] es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario. | ||
| − | El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios | + | El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios y los interesados en el producto. Todo lo que aporte valor al usuario, en términos del producto final, tiene que estar reflejado en el backlog... |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo | + | == Cuándo está completo? == |
| − | Habitualmente se comienza a elaborar con el resultado de una | + | A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo, está en continuo crecimiento y evolución. |
| + | Habitualmente, se comienza a elaborar con el resultado de una lluvia de ideas o un proceso de “Exploración” ([[Extreme Programming]]), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto. | ||
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc. | El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc. | ||
| − | + | Es importante disponer de una visión real, comprendida y compartida por todo el equipo. | |
El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo. | El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo. | ||
| − | + | == Formato == | |
| + | |||
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo. | El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo. | ||
| + | |||
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea: | Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea: | ||
| − | * Identificador único de la [historia de usuario] | + | * Identificador único de la [[historia de usuario]] |
| − | * Títilo de la [historia de usuario] | + | * Títilo de la [[historia de usuario]] |
| − | * Descripción de la [historia de usuario] | + | * Descripción de la [[historia de usuario]] |
* Importancia | * Importancia | ||
* Estimación | * Estimación | ||
| Línea 35: | Línea 35: | ||
* Tiene etapas o fases y cada una aporta valor al usuario del producto | * Tiene etapas o fases y cada una aporta valor al usuario del producto | ||
* Permite entender la complejidad de la funcionalidad | * Permite entender la complejidad de la funcionalidad | ||
| − | * La funcionalidad revelante para el usuario y la funcionalidad compleja | + | * La funcionalidad revelante para el usuario y la funcionalidad compleja están al principio |
* Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto | * Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto | ||
* Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado | * Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado | ||
* Permite saber si una funcionalidad puede suplirse con la combinación de otras | * Permite saber si una funcionalidad puede suplirse con la combinación de otras | ||
| − | * Da noción de volúmen de información que se manipula en cada | + | * Da noción de volúmen de información que se manipula en cada funcionalidad |
== Pasos para priorizar el backlog del producto == | == Pasos para priorizar el backlog del producto == | ||
| Línea 46: | Línea 46: | ||
# Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto. | # Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto. | ||
# Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo. | # Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo. | ||
| + | |||
| + | == Una técnica de priorización == | ||
| + | |||
| + | # Proponer al dueño de producto y demás involucrados que ubiquen las tarjetas del backlog sobre la mesa (una tarjeta por cada historia). | ||
| + | # Explicar que se trata de establecer un orden de prioridad para que el equipo pueda dar el máximo valor en el menor tiempo. | ||
| + | # Explicar que la dinámica es de 30 minutos. | ||
| + | # Pedir a los participantes que dividan las tarjetas en dos columnas de igual tamaño -prioridad 1 y prioridad 2-, si queda un número impar de cartas, ubicar la carta extra en la columna de prioridad 1. | ||
| + | # Una vez hecho esto, cambiar el nombre de la columna de prioridad 2 como prioridad 3 y dejar a un lado. | ||
| + | # Ahora repita el paso 4 para las tarjetas de prioridad 1. | ||
| + | # Ahora debería tener 3 columnas (en orden de prioridad) de tarjetas, con no más de 10 tarjetas en cada una de las dos primeras columnas. | ||
| + | # Si usted todavía tiene tiempo, puede pedir a los participantes que ordene las tarjetas de prioridad 1. Una alternativa es seguir dividiendo la columna 1 hasta tener el número deseado de tarjetas. | ||
| + | |||
| + | == Material de referencia == | ||
| + | |||
| + | * [http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog] | ||
| + | * [http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/ http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/] | ||
| + | * [http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/ http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/] | ||
== Ver también == | == Ver también == | ||
| − | * [ | + | * [[Historia de usuario]] |
| − | |||
| − | |||
* [[Scrum]] | * [[Scrum]] | ||
* [[Backlog Del Sprint]] | * [[Backlog Del Sprint]] | ||
Revisión actual del 14:46 11 sep 2012
Contenido
Qué es el backlog o pila de producto?
El backlog (o pila) del producto en Scrum es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.
El backlog es un inventario o una lista priorizada de requerimientos de usuario que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios y los interesados en el producto. Todo lo que aporte valor al usuario, en términos del producto final, tiene que estar reflejado en el backlog...
Cuándo está completo?
A diferencia de un documento de requisitos del sistema, la pila del producto nunca se da por completo, está en continuo crecimiento y evolución. Habitualmente, se comienza a elaborar con el resultado de una lluvia de ideas o un proceso de “Exploración” (Extreme Programming), o en el Sprint 0 (preparación) donde colabora todo el equipo partiendo de la visión del propietario del producto. El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc. Es importante disponer de una visión real, comprendida y compartida por todo el equipo.
El backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.
Formato
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo.
Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:
- Identificador único de la historia de usuario
- Títilo de la historia de usuario
- Descripción de la historia de usuario
- Importancia
- Estimación
- Criterio de aceptación
- Notas a considerar por el equipo de trabajo
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El Dueño Del Producto es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.
Características de un backlog orientado al cliente
- Tiene etapas o fases y cada una aporta valor al usuario del producto
- Permite entender la complejidad de la funcionalidad
- La funcionalidad revelante para el usuario y la funcionalidad compleja están al principio
- Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto
- Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado
- Permite saber si una funcionalidad puede suplirse con la combinación de otras
- Da noción de volúmen de información que se manipula en cada funcionalidad
Pasos para priorizar el backlog del producto
- Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.
- Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto.
- Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.
Una técnica de priorización
- Proponer al dueño de producto y demás involucrados que ubiquen las tarjetas del backlog sobre la mesa (una tarjeta por cada historia).
- Explicar que se trata de establecer un orden de prioridad para que el equipo pueda dar el máximo valor en el menor tiempo.
- Explicar que la dinámica es de 30 minutos.
- Pedir a los participantes que dividan las tarjetas en dos columnas de igual tamaño -prioridad 1 y prioridad 2-, si queda un número impar de cartas, ubicar la carta extra en la columna de prioridad 1.
- Una vez hecho esto, cambiar el nombre de la columna de prioridad 2 como prioridad 3 y dejar a un lado.
- Ahora repita el paso 4 para las tarjetas de prioridad 1.
- Ahora debería tener 3 columnas (en orden de prioridad) de tarjetas, con no más de 10 tarjetas en cada una de las dos primeras columnas.
- Si usted todavía tiene tiempo, puede pedir a los participantes que ordene las tarjetas de prioridad 1. Una alternativa es seguir dividiendo la columna 1 hasta tener el número deseado de tarjetas.
Material de referencia
- http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog
- http://www.scrumargentina.com.ar/el-dueno-del-producto-agil/
- http://neilkillick.com/2011/12/17/tips-on-speedy-product-backlog-prioritisationordering/
