actualizacion burndown

[elmenda...@gmail.com]

Buenas, esta mañana he tenido una conversación con un compañero sobre
la actualización del gráfico burndown. He de decir que estamos
empezando a poner en práctica en scrum, y que tanto él como yo
trabajamos en equipos distintos.
La cuestión era: ¿cuando se actualiza el burndown?
- Mi punto de vista: todos los dias, aunque haya una tarea a medio
terminar, si has trabajado 5 puntos de una tarea de 13, en el gráfico
se pinta que tienes 5 puntos menos de trabajo ese día.
- Su punto de vista: solo se actualiza cuando se termina la tarea de
13, es decir que tendría una forma de escalera.

Hemos buscado en internet, y los dos puntos de vista se discuten. Una
solución es reducir las tareas a tareas de un día, asi no tendriamos
la discusión :)

¿que pensais vosotros?

Saludos,

[Jorge Uriarte Aretxaga]

¿que una tarea sea de un día garantiza que se complete en un día?

Vaya... cómo no se me habrá ocurrido antes... ;)

Estimas las tareas (distinguir de las historias!) en "puntos" y sabes que "has trabajado 5 puntos"?
Hablas del "sprint burndown" o del product burndown?

 

El primero "en ocasiones" está en horas (ideales o no es otro tema), y se intenta centrar la pregunta más en cuanto queda, que en cuanto debe quedar teniendo en cuenta lo consumido.

Para el sprint burndown, actualiza diariamente. Para el product burndown, al final de cada sprint incorporando las reestimaciones.

Si las historias están en puntos y las tareas en horas, no tiene sentido pasar "el resto" al siguiente sprint. En todo caso pasarán las tareas pendientes con su estimación correspondiente.

 

Por cierto, sería interesante lanzar esta pregunta en "foro-agiles". Vocacionalmente la lista agile-spain va más orientada a discusiones geográficamente restringidas, e intentamos que "foro-agiles" sea el sitio de discusión metodológica (como es el caso).

 

Saludos!

_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte

2009/7/21 elmenda...@gmail.com <elmenda...@gmail.com>

[elmenda...@gmail.com]

Gracias Jorge, tienes razon lo mando a foro-agiles.

Por otra parte, las aclaraciones que pides: Hablo del sprint burndown.
Se estiman las tareas, en puntos. Las historias es la suma de las
tareas, y se estima todo en la misma unidad, no una cosa en horas y
otra en puntos. Muy agudo lo de la tarea diaria :D

De todas maneras, has dejado claro la respuesta.

Gracias!



On 21 jul, 21:34, Jorge Uriarte Aretxaga <jorge.uria...@gailen.es>
wrote:

> ¿que una tarea sea de un día garantiza que se complete en un día?
> Vaya... cómo no se me habrá ocurrido antes... ;)
>
> Estimas las tareas (distinguir de las historias!) en "puntos" y sabes que
> "has trabajado 5 puntos"?
> Hablas del "sprint burndown" o del product burndown?
>
> El primero "en ocasiones" está en horas (ideales o no es otro tema), y se
> intenta centrar la pregunta más en cuanto queda, que en cuanto debe quedar
> teniendo en cuenta lo consumido.
> Para el sprint burndown, actualiza diariamente. Para el product burndown, al
> final de cada sprint incorporando las reestimaciones.
> Si las historias están en puntos y las tareas en horas, no tiene sentido
> pasar "el resto" al siguiente sprint. En todo caso pasarán las tareas
> pendientes con su estimación correspondiente.
>
> Por cierto, sería interesante lanzar esta pregunta en "foro-agiles".
> Vocacionalmente la lista agile-spain va más orientada a discusiones
> geográficamente restringidas, e intentamos que "foro-agiles" sea el sitio de
> discusión metodológica (como es el caso).
>
> Saludos!
> _
> Jorge Uriarte Aretxagahttp://www.gailen.eshttp://www.linkedin.com/in/jorgeuriarte
>

> 2009/7/21 elmendalere...@gmail.com <elmendalere...@gmail.com>

[Xavier Quesada Allue]

Hola elmendalerenda,

Estimar tareas en general se considera desperdicio (waste). Esto se hacía hace algunos años y sigue figurando en algunos libros y blogs, pero nadie relevante (que yo sepa) sigue recomendando estimar a nivel de tareas. Recordemos que tareas en el contexto de Scrum significa trabajo parcial de una historia, por lo tanto trabajo que no entrega valor de negocios y que no será demostrado. Solo las historias entregan valor.

La forma de trabajar que hoy se suele recomendar es:

1) Estimar tus historias cuando son agregadas al backlog, en puntos de historia (story points)
2) Al principio del sprint, en la segunda parte del sprint planning, dividir tus historias en tareas de un día
3) Crear un taskboard, y aplicar best practices de gestion visual durante el sprint para visualizar y gestionar el flujo del trabajo.

Naturalmente sigue que si no se estiman tareas, el Sprint Burndown no tiene mucho sentido (lo único que podrías monitorear es el numero de tareas que quedan, pero eso se puede ver a simple vista). En efecto, el sprint burndown ha caído casi en desuso y yo al menos ya no lo enseño ni recomiendo.

Leyendo como trabajás hoy, pareciera que no estás estimando tus historias up front, las estás estimando en el momento que las vas a ejecutar, dividiéndolas en tareas y estimando las tareas. De esta forma, sin un backlog estimado de antemano, no veo como podés tener un Project Burndown chart que sí es super importante (sin el, no hay forma de monitorear el estado del proyecto)

Saludos,
Xavier

2009/7/22 elmenda...@gmail.com <elmenda...@gmail.com>

--
Xavier Quesada Allue
Visual Management Blog
http://www.xqa.com.ar/visualmanagement

[Jorge Uriarte Aretxaga]

Xavier, ¿quizás habría que profundizar en la diferencia entre "estimar
tareas" y "dividir tus historias en tareas de 1 día"?
En general, coincido en que 1 día es la duración ideal para trazar el
avance, aunque nosotros no lo restringimos. En la práctica, el equipo
tiende cada vez más a estimar (debería decir "dividir"?) en tareas de
1 día ;)

_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte

2009/7/22 Xavier Quesada Allue <xav...@xqa.com.ar>:

[Xavier Quesada Allue]

Hola Jorge,

Aclaremos primero que lo de tareas de un día debe tomarse como guía ("guideline") y no como una regla a seguir a rajatabla. En el mundo ágil no hay reglas, solo prácticas que surgen de buscar aplicar los principios y valores ágiles y Lean a nuestras situaciones cotidianas.

El objetivo de dividir historias en tareas es el de hacer un análisis más en detalle de la historia. El objetivo de dividir en tareas de un día es el de permitir la creación y visualización de flujo, uno de los principios Lean. Hasta aquí no hablamos de estimar. Pero claro, dividir una historia en tareas de un día es, en efecto, una forma de estimar. Ya que con solo contar las tareas, tenemos una estimación (cruda, como toda estimación) del número de días que pensamos llevará.

Pero en mi opinión esta estimación es un side-effect, y no por ello recomendaría hacer tracking de tareas dentro del sprint. Si el equipo ya ha mejorado el taskboard hasta un nivel aceptable, se puede ver a simple vista como viene el sprint. Si todavía alguien (el PO, un gerente, o el equipo mismo) necesita más visibilidad del progreso dentro del sprint y no se conforma con el avance que se demuestra durante la demo, recién ahi recomendaría que hagan un sprint burndown chart donde se cuentan tareas; pero mi experiencia es que dicho burndown lleva mucho tiempo mantener (hay que contar todas las tareas todos los días) y no entrega casi valor adicional.

La verdadera solucion en ese caso sería que acorten el Sprint.

Saludos,
Xavier

2009/7/22 Jorge Uriarte Aretxaga <jorge....@gailen.es>

[Jorge Uriarte Aretxaga]

Jeje... ahí te quería traer, estamos de acuerdo ;)

A mí me gustan otros efectos laterales de la enumeración y estimación
"en crudo" de las tareas, y es que permite a los miembros del equipo
reflexionar comunitariamente sobre lo que implica técnicamente una
historia dada.

Lo que me llama la atención es que hablas de "hacer tracking", y de
"visualización del flow" como si fueran términos contrapuestos, y para
mí, ambas cosas son lo mismo, sólo que pueden hacerse de manera
eficiente o ineficiente (como casi todo en esta vida).

Un abrazo (y por qué no habremos pasado la conversación a foro-agiles... :P)

[José Manuel Beas]

Siento llegar tarde a la discusión (incluso aunque no sea en foro-agiles) :-)

Antes de empezar, quisiera aclarar un concepto: "gráfico de quemado de sprint". Para mi, en éste gráfico no hacemos seguimiento de tareas sino de historias acabadas (done-done). Si para vosotros es otra cosa, quizás yo haya confundido cosas que habéis dicho antes.

En cualquier caso, mi experiencia es que en la reunión de definición (y estimación) de tareas para el sprint empleábamos mucho tiempo (demasiado). Pienso que se trataba de que no preparábamos suficientemente bien las historias de usuario antes de entrar en esta reunión con todo el equipo, por lo que normalmente surgían muchas dudas y era necesario asegurarnos de que la estimación previa de la historia "encajaba" con la suma de las estimaciones de las tareas. Esto, lejos de ser de utilidad, creo que nos servía más que nada para que muchos hicieran cábalas sobre "cuántas horas son un punto de historia de usuario".

Por otro lado, nosotros teníamos la restricción de que nuestras tareas no debían de ser de más de 4 horas (para que estuvieran muy, muy enfocadas). Esto era, sobre todo, porque nuestras iteraciones eran de 1 semana, con lo que era muy importante lograr sensación de avance y obtener "feedback" muy, muy rápido y así tener oportunidad para reaccionar. En realidad, cuando digo 4 horas quiero decir "una mañana", "una tarde"... "una o dos sesiones de trabajo individual o en pareja (depende de si hacéis sesiones de 2 o 4 horas)". Supongo que cuando Xavier dice "tareas de un día" viene a decir algo parecido: "un par de mañanas", "un mañana y una tarde"....

Mi pregunta, entonces, es la siguiente:

Si no estimo las tareas de mis historias de usuario ni tengo un gráfico de quemado por iteración, ¿cómo me daré cuenta de que me estoy retrasando en lo previsto para esa iteración? ¿Cómo podré avisar al dueño de producto de que en la demo de esa iteración no irá todo a lo que nos comprometimos y la razón por lo que eso no podrá entrar?

Veo que en las reuniones diarias, como scrummaster, puedo conocer los impedimentos, pero qué pasa si no hay impedimentos sino que "simplemente" se infraestimó la historia en el backlog. Tengo la sensación de que con un gráfico por sprint (que herramientas como Xplanner o un simple Excel te hacen fácilmente) ayuda bastante en esto, además de dar esa sensación de "avance" que a veces es tan útil para la motivación del equipo.

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com

[Joserra]

Hola,

Pues nosotros usamos la gráfica de burndown como dice JMB. Representa
las historias pendientes que no se han terminado, o sea que bajamos la
gráfica en el número de horas (sí, horas) que estimamos la historia
terminada (done-done). Y lo considero bastante útil, nos da la imagen
de cómo va el sprint ciertamente.
Los puntos de historia será otra cuestión que introduciremos
paulatinamente,...

On 22 jul, 18:23, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> Siento llegar tarde a la discusión (incluso aunque no sea en foro-agiles)
> :-)
>

> Ante de empezar, quisiera aclarar un concepto: "gráfico de quemado de

[elmenda...@gmail.com]

Coincido con JMB. Si no tengo un seguimiento del sprint me estoy
dejando información por el camino que no saldrá hasta el final.
Esta claro que si no uso un gráfico a nivel de sprint, no me preocupa
cuando ni como actualizarlo.

Con respecto a la estimacion Xavier, lo que comentas de estimar
historias, pocos desarrolladores conozco que tengan tal nivel de
abstraccion y al final todos se ayudan de dividirlo en tareas mas
cortas, estimarlas por separado y luego sumarlas, aunque se haga
mentalmente. Esto enlaza con lo que comenta JMB, reuniones de
estimación muy largas.

¿Que cantidad de tiempo se requiere para desmenuzar una historia de
usuario en tareas de un solo dia?

Quizas algo no estoy comprendiendo bien.

[Xavier Quesada Allue]

2009/7/22 José Manuel Beas <jose....@gmail.com>:

> Antes de empezar, quisiera aclarar un concepto: "gráfico de quemado de
> sprint". Para mi, en éste gráfico no hacemos seguimiento de tareas sino de
> historias acabadas (done-done). Si para vosotros es otra cosa, quizás yo
> haya confundido cosas que habéis dicho antes.

Yo la verdad nunca escuché de un sprint burndown donde se quemen
historias. No veo la utilidad. El taskboard muestra claramente las
historias terminadas. (Tip: son la que tienen todas sus tareas en la
ultima columna :)

>
> En cualquier caso, mi experiencia es que en la reunión de definición (y
> estimación) de tareas para el sprint empleábamos mucho tiempo (demasiado).
> Pienso que se trataba de que no preparábamos suficientemente bien las
> historias de usuario antes de entrar en esta reunión con todo el equipo, por
> lo que normalmente surgían muchas dudas y era necesario asegurarnos de que
> la estimación previa de la historia "encajaba" con la suma de las
> estimaciones de las tareas.
> Esto, lejos de ser de utilidad, creo que nos
> servía más que nada para que muchos hicieran cábalas sobre "cuántas horas
> son un punto de historia de usuario".

Ok, pero la solucion es preparar mejor las historias, no estimar las
tareas o hacer un sprint burndown. Vos mismo lo dijiste.

>
> Por otro lado, nosotros teníamos la restricción de que nuestras tareas no
> debían de ser de más de 4 horas (para que estuvieran muy, muy enfocadas).
> Esto era, sobre todo, porque nuestras iteraciones eran de 1 semana, con lo
> que era muy importante lograr sensación de avance y obtener "feedback" muy,
> muy rápido y así tener oportunidad para reaccionar. En realidad, cuando digo
> 4 horas quiero decir "una mañana", "una tarde"... "una o dos sesiones de
> trabajo individual o en pareja (depende de si hacéis sesiones de 2 o 4
> horas)". Supongo que cuando Xavier dice "tareas de un día" viene a decir
> algo parecido: "un par de mañanas", "un mañana y una tarde"....

Correcto

>
> Mi pregunta, entonces, es la siguiente:
>
> Si no estimo las tareas de mis historias de usuario ni tengo un gráfico de
> quemado por iteración, ¿cómo me daré cuenta de que me estoy retrasando en lo
> previsto para esa iteración? ¿Cómo podré avisar al dueño de producto de que
> en la demo de esa iteración no irá todo a lo que nos comprometimos y la
> razón por lo que eso no podrá entrar?

Primero que nada, en mi opinion no debería importarte tanto si te
estás atrasando. El concepto de "estar atrasado" viene del pensamiento
predictivo waterfallista y ganttista. Uno de los grandes cambios de
paradigma que promueven las metodologías ágiles y en particular el
movimiento Kanban es pasar de pensar en terminos de "schedules" y
"estar atrasado" a pensar en crear y establecer flujo continuo y medir
(a posteriori) el valor entregado.

Dicho esto, si te estás atrasando, deberia ser evidente durante los
daily scrums. Y además un simple vistazo del taskboard lo deberia
mostrar con total claridad.

>
> Veo que en las reuniones diarias, como scrummaster, puedo conocer los
> impedimentos, pero qué pasa si no hay impedimentos sino que "simplemente" se
> infraestimó la historia en el backlog. Tengo la sensación de que con un
> gráfico por sprint (que herramientas como Xplanner o un simple Excel te
> hacen fácilmente) ayuda bastante en esto, además de dar esa sensación de
> "avance" que a veces es tan útil para la motivación del equipo.

Todo esto no tiene ningun sentido si usamos estimacion en story points
y velocidad. No tiene sentido decir "se subestimó una historia". Solo
podemos decir "nuestra velocidad es menor a lo que pensábamos".

Bah, me corrijo. Puede pasar que hayan subestimado una historia. Si
una historia fue groseramente subestimada en story points (digamos que
se dijo que era un 2, y cuando la vamos a hacer vemos que es un 8)
esto deberia salir a la luz durante sprint planning cuando todavía
estamos a tiempo de cambiarle el tamaño y seguir como si nada. Pero
esto es muy poco comun.

Otro tema que me queda muy poco claro es la granularidad con la que
estás trabajando. Cuantas historias ponen en un sprint? Una? Cinco?
Veinte? El tamaño de tus historias es tan importante como el tamaño de
tus tareas. Con historias demasiado grandes, vas a tardar demasiado en
saber tu velocidad real. Solo tiene sentido para proyectos muy
grandes. Historias demasiado chicas, por otro lado, implican demasiado
overhead.

Para cerrar: todo el tema alrededor de estimacion de tareas,
commitment del sprint, micro-management... todo esto hay que tirarlo
por la borda y pasar a un paradigma empírico y de flujo, en el cual
establecemos las condiciones ideales de trabajo, hacemos el trabajo,
medimos nuestro progreso regularmente, y mejoramos el proceso
continuamente. No tomar medidas micro-predictivas como estimar tareas
en horas y llevar el control de cuanto tiempo consumieron y entrar en
pánico si estamos "atrasados". Todo eso es waste y además conduce a un
espíritu opresivo y de micromanagement.

Saludos,
Xavier

[Jorge Uriarte Aretxaga]

Ay... qué pena estos debates por email, y no viéndonos las caras y con
unas pizarras, eh? :)

> Yo la verdad nunca escuché de un sprint burndown donde se quemen
> historias. No veo la utilidad. El taskboard muestra claramente las

http://jeffsutherland.com/scrum/2009/04/sprint-burndown-by-hours-or-by-story.html

> Primero que nada, en mi opinion no debería importarte tanto si te
> estás atrasando. El concepto de "estar atrasado" viene del pensamiento
> predictivo waterfallista y ganttista. Uno de los grandes cambios de
> paradigma que promueven las metodologías ágiles y en particular el
> movimiento Kanban es pasar de pensar en terminos de "schedules" y
> "estar atrasado" a pensar en crear y establecer flujo continuo y medir
> (a posteriori) el valor entregado.

Ay.... jajaja... lo pienso decir en la próxima reunión con mis clientes.
Probablemente son parte de la conspiración
"predicto-waterf-ganttista", pero les venceremos!!! :P

De todos modos... una pregunta que me atormenta... ¿hablamos de Scrum?
¿de Scrum++? ¿de Scrum-but? ¿De Lean?
XQ, tú eres un hombre visual, eso está claro, y todo lo enfocas desde
el dashboard... pero hay otros enfoques que a algunos les pueden ir
bien o mal :)

Mi humildísima opinión (sin chequearlo) es que la pregunta inicial iba
sobre las recomendaciones de Scrum. Intentar que todo el mundo de el
salto a Kanban y a la release continua es en mi opinión demasiado
ambicioso, aunque está bien tener objetivos ambiciosos ;)
En ese sentido, el propio Sutherland me parece bastante pragmático en
ese post que he copiado antes:

"For new teams, breaking down the Sprint Backlog into tasks and
estimating in hours is normally recommended as the teams need to learn
to manage resource loading."

Esa frase tiene mucho contenido; *new teams*, *normally recommended*,
*teams need to learn...", ...

Espero que pronto discutamos todo esto con unas cervezas!!

_
Jorge

[Xavier Quesada Allue]

2009/7/23 Jorge Uriarte Aretxaga <jorge....@gailen.es>:

>
> Ay... qué pena estos debates por email, y no viéndonos las caras y con
> unas pizarras, eh? :)
>
>> Yo la verdad nunca escuché de un sprint burndown donde se quemen
>> historias. No veo la utilidad. El taskboard muestra claramente las
>
> http://jeffsutherland.com/scrum/2009/04/sprint-burndown-by-hours-or-by-story.html

"To do this, the team needs to have small stories."

Por eso aclaré lo de granularidad. Estoy 100% de acuerdo que con
micro-historias (en la práctica serían tareas que entregan valor) se
puede actualizar un burndown dentro del sprint. Pero para qué sprint
burdown, si podés ir actualizando tu project burndown directamente?
Para qué llevar dos gráficos?

Por otro lado, historias pequeñas en proyectos grandes son muchas
veces completamente irrealistas. Todo depende de la naturaleza del
trabajo.

>
>> Primero que nada, en mi opinion no debería importarte tanto si te
>> estás atrasando. El concepto de "estar atrasado" viene del pensamiento
>> predictivo waterfallista y ganttista. Uno de los grandes cambios de
>> paradigma que promueven las metodologías ágiles y en particular el
>> movimiento Kanban es pasar de pensar en terminos de "schedules" y
>> "estar atrasado" a pensar en crear y establecer flujo continuo y medir
>> (a posteriori) el valor entregado.
>
> Ay.... jajaja... lo pienso decir en la próxima reunión con mis clientes.
> Probablemente son parte de la conspiración
> "predicto-waterf-ganttista", pero les venceremos!!! :P
>
> De todos modos... una pregunta que me atormenta... ¿hablamos de Scrum?
> ¿de Scrum++? ¿de Scrum-but? ¿De Lean?
> XQ, tú eres un hombre visual, eso está claro, y todo lo enfocas desde
> el dashboard... pero hay otros enfoques que a algunos les pueden ir
> bien o mal :)

Hasta donde yo se, hablamos de Metodologías Ágiles y de Lean Thinking.
Es todo lo mismo.

>
> Mi humildísima opinión (sin chequearlo) es que la pregunta inicial iba
> sobre las recomendaciones de Scrum. Intentar que todo el mundo de el
> salto a Kanban y a la release continua es en mi opinión demasiado
> ambicioso, aunque está bien tener objetivos ambiciosos ;)

No recomiendo a NADIE Kanban por encima de Scrum. Recomiendo aplicar
bien Scrum. Desde el principio.

> En ese sentido, el propio Sutherland me parece bastante pragmático en
> ese post que he copiado antes:
>
> "For new teams, breaking down the Sprint Backlog into tasks and
> estimating in hours is normally recommended as the teams need to learn
> to manage resource loading."
>
> Esa frase tiene mucho contenido; *new teams*, *normally recommended*,
> *teams need to learn...", ...
>
> Espero que pronto discutamos todo esto con unas cervezas!!

+1. Invitame y voy. Agile Open Bilbao?

Abrazo,
Xavier

[Jorge Uriarte Aretxaga]

2009/7/23 Xavier Quesada Allue <xav...@xqa.com.ar>:

>>
>> Espero que pronto discutamos todo esto con unas cervezas!!
>
> +1. Invitame y voy. Agile Open Bilbao?
>

Primero nos veremos en el de Madrid. Qué son 400Km?

[Ángel Medinilla]

> Primero que nada, en mi opinion no debería importarte tanto si te
> estás atrasando. El concepto de "estar atrasado" viene del pensamiento
> predictivo waterfallista y ganttista. Uno de los grandes cambios de
> paradigma que promueven las metodologías ágiles y en particular el
> movimiento Kanban es pasar de pensar en terminos de "schedules" y
> "estar atrasado" a pensar en crear y establecer flujo continuo y medir
> (a posteriori) el valor entregado.

Ay.... jajaja... lo pienso decir en la próxima reunión con mis clientes.
Probablemente son parte de la conspiración
"predicto-waterf-ganttista", pero les venceremos!!! :P

XD

Muy buena, Jorge. Creo que habéis dado en el clavo de un factor importante y distintivo: ¿Trabajamos para nosotros, en un proyecto de desarrollo, o trabajamos para otros en un modelo fixed everything? 

El diagrama de Burn-Down se hace por tareas, y a veces se hacen dos gráficas en los mismos ejes: unas "hacia abajo" y lineales (burn down) y otras "hacia arriba" y en escalones (historias completadas). Ambas dan información que no te da el tablón solamente. Si estamos en el día 18 de un sprint de 20 días y veo casi todas las historias completadas en el tablón puedo pensar "que bien". Si veo el burn down correspondiente y veo que TODAS se han completado en el día 18 en vez de ir haciendo "escalera" hacia arriba, pensaré "que mal, si nos llegamos a deslizar dos días no entregamos ni una sola historia en este sprint, debo hablar con el equipo y hacerles ver que están paralelizando demasiado". El burn-down nos cuenta la historia del Sprint. Ergo otro uso importante es su revisión durante la retrospectiva. El conjunto de burn-downs me permite estudiar el "cross-sprint behaviour", cosa que no me permiten los tablones solos.


¿Que estimo en story points? Magnífico. Si soy capaz de estimar la tarea completa, soy capaz de estimar cuanto me queda de la tarea. "Esta tarea son 4 puntos, llevo hechos algo menos de la mitad... er... Pon que quedan 3". ¿Y qué si no somos "certeros"? El objetivo en la estimación no es ser super-exacto en TODAS las estimaciones (buf, esto daría, más que para otro correo, para un libro entero, que se lo digan a MIke Cohn ;)

"Estas cosas saldran en el scrum diario". Magnífico para el scrum master. No tan bueno para el dueño de producto. De nuevo, si somos un grupo de programadores trabajando "para nosotros", fetén. De hecho, tirad Scrum y pasaos a Kanban (menos "obligaciones"). Si estamos en el mundo comercial y hay una fecha de entrega recordad que Scrum es "el sistema más simple posible, pero no más simple" (A. Einstein). Cada vez que quitamos algo, estamos rompiendo algo. Si somos suficientemente disciplinados y diestros como para manejar este factor "roto" por nuestra cuenta, magnífico. Pero de ahí a decir que el burn-down no sirve o recomedar a todo el que esté empezando que se pasen a los sistemas más "abiertos"... ¡Uf! Creo que va un trecho. ;)

My two cents.
 

[Jorge Uriarte Aretxaga]

2009/7/23 Ángel Medinilla <angel.m...@gmail.com>:

>
> El burn-down nos cuenta la historia del Sprint.
> Ergo otro uso importante es su revisión durante la retrospectiva. El
> conjunto de burn-downs me permite estudiar el "cross-sprint behaviour", cosa
> que no me permiten los tablones solos.
>

+1 ! No lo había mencionado, pero los equipos aprenden a reflexionar
sobre la gráfica como indicativo de las virtudes y defectos del equipo
de proyecto. Para mí suele ser importante también marcar las tareas
"sobrevenidas", porque alteran la gráfica y muestran errores de
previsión que sirven para aprender. Pero lo compleja o no que quieras
hacer la(s) gráfica(s) depende de nuevo del retorno que aporte al
equipo (al fin y al cabo son también herramientas de visualización)

[elmenda...@gmail.com]

> El diagrama de Burn-Down se hace por tareas, y a veces se hacen dos gráficas
> en los mismos ejes: unas "hacia abajo" y lineales (burn down) y otras "hacia
> arriba" y en escalones (historias completadas). Ambas dan información que no
> te da el tablón solamente.

Exacto, la luz al final del tunel. Bueno esta es la respuesta a mi
pregunta inicial, pero el debate que habeis abierto es muy
interesante!