Product Burndown Chart cuando la Product backlog esta parcialmente estimada

[anali...@gmail.com]

Acabo de terminar el training de Scrum Master y estudiando para la Certificación me surgió la siguiente duda:


Como ya todos sabeis, en la gráfica Product Burndown se considera los story points de los PBI´s X cantidad de Sprints; tal como se muestra en la siguientee imgen:


http://www.scrum-institute.org/images_scrum/Simple_Burndown_Chart.jpg

http://www.scrum-institute.org/images_scrum/Simple_Burndown_Chart.jpg


Pero, en el curso, se sugirió que tener estimada toda la Producto Bcklog era desperdiciar trabajo puesto que los requisitos cambian. Nos sugirieron que tuvieramos estimados los PBI´s de los 2 siguientes Sprint´s aprox.

Siguiendo esta regla, ¿como se puede hacer una gráfica Product Burndown realista si la Product Backlog no esta estimada totalmente? 

gracias

[José María Valiente]

Hola,

Precisamente por eso no me gustan los Burndown charts. Prefiero usar Cumulative Flow Diagrams que irán creciendo conforme tu Backlog vaya siendo refinado.
Aún así, prueba igualmente a estimar/guestimar más allá de 2 sprints y luego vas rectificando conforme el producto va evolucionando.

Espero que te ayude.

José María

[Jorge Muria]

Si sigues la norma de que las historias deben ser pequeñas, deberias encontrare una distribución uniforme de tamaños en los sprints. Usa el tamaño medio de historia para las nuevas que crees sin estimar asi 'hacen bulto' y tu product burnup será más util. En la sesiones de sprint planning y Backlog grooming podeis ir ajustando estos tamaños.

Un saludo

[Gabriel Osorio]

*Concientes

El 15 de septiembre de 2016, 10:04, Gabriel Osorio <ge.e...@gmail.com> escribió:

Se estima todo el Product Backlog siendo consientes de la poca granularidad de las tareas con menor prioridad. 

Se estiman los Sprint Backlogs porque su granularidad es alta, y se recomienda tener uno o dos Sprint Backlogs adelante totalmente estimados.

Un Burndown más realista está relacionado directamente con la madurez del equipo. Hay que recordar la regla 80/20, que da una visión más "realista" del desperdicio y por lo tanto del tiempo y esfuerzo finales.

http://cuspideagil.blogspot.com.co/2016/07/ParetoBacklog.html

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/1350eac3-ec55-4e7c-9263-fe6ab685c1c8%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Gabriel Osorio]

Se estima todo el Product Backlog siendo consientes de la poca granularidad de las tareas con menor prioridad. 

Se estiman los Sprint Backlogs porque su granularidad es alta, y se recomienda tener uno o dos Sprint Backlogs adelante totalmente estimados.

Un Burndown más realista está relacionado directamente con la madurez del equipo. Hay que recordar la regla 80/20, que da una visión más "realista" del desperdicio y por lo tanto del tiempo y esfuerzo finales.

http://cuspideagil.blogspot.com.co/2016/07/ParetoBacklog.html

El 15 de septiembre de 2016, 4:14, <anali...@gmail.com> escribió:

--

[Xavier Albaladejo]

Hola,

Espero que en esa "certificación" hiciesen más sugerencias que sólo estimar los dos siguientes Sprints o, al menos, que se explicase cómo decirle a un cliente / a alguien de Negocio / al Product Owner "oye, es que no te puedo dar una estimación del proyecto, sólo del mes siguiente, sino sería desperdiciar mi trabajo".

Salud,

Xavi

[anali...@gmail.com]

Bien, ¿y con respecto a la pregunta vas a darme alguna respuesta?

[Alex Ballarin]

Hola a todos,

"es para flipar" este Scrum Institute. Certificaciones desde 29$. Es una pena que estas organizaciones confundan al público. En fin.

Respondiendo a tu pregunta, es imposible hacer un "project o release burndown" sin tener una estimación del backlog, o almenos de la parte que quieres seguir (p.e. una release). Salvando las distancias, es como decir "Me voy a no-se-donde y quiero saber cuanto me queda".

El que te dijo que estimar todo el backlog era un desperdicio se cubrió de gloria: es no tener ni idea de lo que es un Product Backlog. Puedes perfectamente tener todo el backlog estimado, dependiendo del caso, y aquellas partes que quedan más lejos en el tiempo estar estimadas a más alto nivel. Seguramente esto de estimar los PBI de los 2 próximos sprints se refería a tenerlos estimados a un nivel más fino, porque esos PBI ya tiene sentido refinarlos y estimarlos, es probable que sean incluídos en los sprints. El resto del backlog es cada vez más difuso.

Como dicen los compañeros, usar los diagramas de burn up o de cumulative flow sería útil en estas situaciones, pero la pregunta no me cuadra.

Suerte con esa "certificación".

---

Àlex Ballarin - Professional Scrum Trainer en Scrum.org.

[Xavier Albaladejo]

Hola,

 

Con falta de mucho contexto, si el objetivo es conocer el progreso del proyecto (o mejor, cuánto falta para acabar), se podrían dar al menos dos situaciones:

 

a)      Se trabaja en un producto.

b)      Se trabaja en un proyecto.

 

 

En la situación (a), si se trata de un desarrollo continuo (que puede llegar a ser muy flexible para ir ajustándose a las necesidades del tipo de usuario/cliente mercado), además de métricas relacionadas con el propio resultado a nivel de producto (lo más importante), se podría utilizar un diagrama de flujo acumulado (como ya se indica en el hilo).

 

Incluso en esta situación también podría ser necesario estimar lo que cuesta lanzar una release (por situaciones concretas o externas de lanzamiento de producto al mercado, etc.), y ahí un Release Burndown también podría ayudar a entender la velocidad (si se llega a tiempo) y tomar decisiones sobre qué alcance recortar (esta es la variable favorita a gestionar cuando trabajamos en Agile).

 

Todo esto en línea de “Responding to change over following a plan”. Es decir, tener un plan es BUENO, pero no por eso vas a dejar de ser flexible para adaptarte a las necesidades del entorno, a cambios de contexto o a aportar más valor.

 

Mencionar que también puede ser necesario estimar una idea de negocio / experimento / proyecto / épica … para ver si sale a cuenta el Business Case, entender mejor lo que se necesita y/o llegar a una solución que sea suficientemente sencilla para que ese Business Case salga.

 

En la situación (b), si se trata de realizar un proyecto para un tercero, lo más común será realizar una estimación inicial del Product Backlog, acordar desde el inicio las reglas del juego para trabajar en Agile (por ejemplo, cómo realizar cambios de alcance manteniendo el coste (*)) e incluso realizar spikes (pruebas de concepto de “usar y tirar”) para conocer la viabilidad técnica y/o mejorar esa estimación. Un gráfico que puede ayudar para ver cuánto falta para acabar es el PBL Burndown.

 

(*) Todo esto va a depender mucho del tipo de relación que tengamos con el cliente. “customer collaboration over contract negotiation”.

 

Para conocer un poco mejor todos estos temas, te recomiendo que tires del siguiente artículo de Xavier Quesada y de los comentarios que allí aparecen: https://proyectosagiles.org/2009/06/08/introduccion-estimacion-planificacion-agil/

 

Espero que ayude,

Xavi

[Jose Manuel Beas]

Hola a todos,

Yo hace años que desaconsejo el "burn-down chart" porque, de alguna manera, mantiene a la gente que lo usa en una mentalidad de planificación predictiva en vez de adaptativa. En su lugar, como decía Jorge Muria al principio de este hilo, yo aconsejo los Diagramas de Flujo Acumulado (si haces Kanban) o su versión Scrum (el "burn-up chart"). Creo que en este artículo que escribí hace tiempo lo explico mejor de lo que podría hacerlo ahora.

Claro que, si haces Kanban, seguramente estimar se convierta en una actividad innecesaria pues con un buen "run chart" (gráfico donde visualizas el "lead time" de cada tarea acabada sobre el eje del tiempo) puedes identificar tipos de tareas por el tiempo que se suelen emplear en entregar, de modo que puedes hacer predicciones basadas en un comportamiento habitual en vez de en un deseo más o menos optimista. Incluso puedes complementar esa predicción con una simulación (p.ej. con el método de Montecarlo) y responder a la respuesta de "para cuándo puedo esperar razonablemente que entreguéis esto que acabamos de poner en duodécima posición del backlog". Por supuesto, la respuesta, igual que con el "burn-up chart", debería ser del estilo "con un 85% de probabilidades podríamos esperar que esté para dentro de 4 semanas".

Si la conversación sigue con un "pues lo necesito para la semana que viene", entonces, como ya sabes, el problema no tiene que ver con las estimaciones. ;-)

Un cordial saludo,
Jose Manuel Beas

http://jmbeas.es

[anali...@gmail.com]

En realidad, repasando los apuntes, no me dijo "exactamente" que no había que estimar todo el backlog, sino que no tendría por que estar estimado todo al detalle, que no es exactamente lo mismo, perdón por la confusión.
Tu respuesta me sirve, gracias


pd. acabo de ver lo del Scrum Institute, de haberlo sabido antes me hubiera ahorrado un montón de dinero ...

[anali...@gmail.com]

muy detallado, gracias :P