Reflejar replanificación en burndown.
34 views
Skip to first unread message
fegoal
Mar 1, 2012, 7:34:30 AM3/1/12
to agile-spain
Buenas tardes a todos.
Me ha surgido un problema en el sprint y algunos de los items del
Productbacklog deben cambiar y además incluir alguna ota cosilla. Los
cambio son muy pocos y pequeños pero exige una replanificación.
El tema es que tengo que reflejar esto en el burndown de cada
compañero del equipo implicado en los cambios.
Existe alguna forma estandar de hacer esto ?, como lo haceis
vosotros ?.
Muchas gracias de antemano y un saludo a todos.
Me ha surgido un problema en el sprint y algunos de los items del
Productbacklog deben cambiar y además incluir alguna ota cosilla. Los
cambio son muy pocos y pequeños pero exige una replanificación.
El tema es que tengo que reflejar esto en el burndown de cada
compañero del equipo implicado en los cambios.
Existe alguna forma estandar de hacer esto ?, como lo haceis
vosotros ?.
Muchas gracias de antemano y un saludo a todos.
Marc Florit
Mar 1, 2012, 7:50:17 AM3/1/12
to agile...@googlegroups.com
buenas,
el problema que comentas veo que no es tal...
Si los Items que han cambiado son de historias ya finalizadas, simplemente deberías añadir nuevas historias con el cambio en el siguiente sprint.
Si los Items que han cambiado son futuros pues simplemente debereis hacer el gromming cuando toque para darle forma y que entren "limpios" en el correspondiente Sprint Planning.
Si el caso es que los Items que han cambiado afectan al Sprint en curso (que es lo que me temo x tu explicacion) deberias intentar lo siguiente:
1) Convencer al PO dejar el cambio para el siguiente sprint. si no es viable,
2) Estimar una tarea/historia de USPlanning para que el equipo pueda estimar el cambio y poder detallar las tareas resultantes.
3) confirmar que no hay impedimentos por parte del equipo para imcluir las historias en el sprint.
--- Dada una complejidad resultante (ejemplo: USPlanning = 3PH, NewUS = 13PH) de 16PH
3) Eliminar del Sprint las historias de menor valor que sumen 16PHs
4) Añadir las nuevas historias al Sprint
A mi entender los burnsdowns no deberian verse afectados.
En caso que esto tampoco sea viable la única opción seria romper el Sprint..!! pero creo que sería peor el remedio q la enfermedad...
Nota: Me sorprende el uso de burndowns individuales (dices: de cada compañero) puedes darnos un par de pinceladas?
No se si hacerlo así te puede llegar a servir. Ya me dirás!
Gracias,
el problema que comentas veo que no es tal...
Si los Items que han cambiado son de historias ya finalizadas, simplemente deberías añadir nuevas historias con el cambio en el siguiente sprint.
Si los Items que han cambiado son futuros pues simplemente debereis hacer el gromming cuando toque para darle forma y que entren "limpios" en el correspondiente Sprint Planning.
Si el caso es que los Items que han cambiado afectan al Sprint en curso (que es lo que me temo x tu explicacion) deberias intentar lo siguiente:
1) Convencer al PO dejar el cambio para el siguiente sprint. si no es viable,
2) Estimar una tarea/historia de USPlanning para que el equipo pueda estimar el cambio y poder detallar las tareas resultantes.
3) confirmar que no hay impedimentos por parte del equipo para imcluir las historias en el sprint.
--- Dada una complejidad resultante (ejemplo: USPlanning = 3PH, NewUS = 13PH) de 16PH
3) Eliminar del Sprint las historias de menor valor que sumen 16PHs
4) Añadir las nuevas historias al Sprint
A mi entender los burnsdowns no deberian verse afectados.
En caso que esto tampoco sea viable la única opción seria romper el Sprint..!! pero creo que sería peor el remedio q la enfermedad...
Nota: Me sorprende el uso de burndowns individuales (dices: de cada compañero) puedes darnos un par de pinceladas?
No se si hacerlo así te puede llegar a servir. Ya me dirás!
Gracias,
Daniel Ceillan
Mar 1, 2012, 7:52:54 AM3/1/12
to agile...@googlegroups.com
El 1 de marzo de 2012 09:34, fegoal <sgom...@gmail.com> escribió:
Buenas tardes a todos.
Me ha surgido un problema en el sprint y algunos de los items del
Productbacklog deben cambiar y además incluir alguna ota cosilla. Los
cambio son muy pocos y pequeños pero exige una replanificación.
El tema es que tengo que reflejar esto en el burndown de cada
compañero del equipo implicado en los cambios.
Si hablas de sprints supongo que usas Scrum. Si no es asi, cual metodologia usas?
Si es el Product backlog, no habria problema en cambiar cosas, o es el Sprint backlog? Si es el segundo caso te recomendaria que no cambies las historias, y de ser requerido, retirarlas del sprint.
No entendi porque hablas de "burndown de cada compañero", el brundown es del equipo, o estas en un scrum de scrums?
Saludos!
--
Daniel Ceillan
Blog: www.agile-patterns.com
fegoal
Mar 1, 2012, 1:03:01 PM3/1/12
to agile-spain
Por qué os sorprende tanto el uso de burndowns individuales ? Además
de tener al burndown general del sprint (o del equipo), quiero medir
la velocidad de quemado de cada uno de los compañeros y teniendo en
cuenta que todos tienen asignados una cantidad de puntos muy parecida,
creo que no está mal ver en un gráfico como los van quemando a lo
largo de la duración total del sprint.
Con respecto al tema de cambiar el backlog sacando tareas me es
imposible, lo único que puedo hacer es añadir dos tareas mas (de pocos
puntos). Pero quiero reflejarlo en los gráficos de burndown del sprint
y en los gráficos de burndown de las personas que les toque
acometerlas.
Las tareas ya están estimadas, son posibles de realizar en el tiempo
establecido. La pregunta era como reflejarlas en los gráficos de
burndown correspondientes. Hay que rehacer cada gráfica hay que poner
una gráfica paralela ?, no se como se hace de la forma mas correcta.
Gracias por vuestras respuestas.
Lo que quiero cambiar es el product backlog añandiendo un par de
tareas ya estimadas por mi equipo.
On 1 mar, 13:52, Daniel Ceillan <codigodan...@gmail.com> wrote:
de tener al burndown general del sprint (o del equipo), quiero medir
la velocidad de quemado de cada uno de los compañeros y teniendo en
cuenta que todos tienen asignados una cantidad de puntos muy parecida,
creo que no está mal ver en un gráfico como los van quemando a lo
largo de la duración total del sprint.
Con respecto al tema de cambiar el backlog sacando tareas me es
imposible, lo único que puedo hacer es añadir dos tareas mas (de pocos
puntos). Pero quiero reflejarlo en los gráficos de burndown del sprint
y en los gráficos de burndown de las personas que les toque
acometerlas.
Las tareas ya están estimadas, son posibles de realizar en el tiempo
establecido. La pregunta era como reflejarlas en los gráficos de
burndown correspondientes. Hay que rehacer cada gráfica hay que poner
una gráfica paralela ?, no se como se hace de la forma mas correcta.
Gracias por vuestras respuestas.
Lo que quiero cambiar es el product backlog añandiendo un par de
tareas ya estimadas por mi equipo.
On 1 mar, 13:52, Daniel Ceillan <codigodan...@gmail.com> wrote:
Adrian Perreau de Pinninck
Mar 1, 2012, 1:59:47 PM3/1/12
to agile...@googlegroups.com
Aunque hay muchas cosas de las que comentas en las que no estoy de acuerdo, voy a ir directo a responder tu pregunta.
En el gráfico de burndown, haz una marca en el dia del sprint (D) en el que se acuerde añadir las historias de usuario, P puntos por encima de la marca de referencia para ese día. (P es el número de puntos de historia añadidos al sprint)
Traza una linea recta desde esa marca al punto final del sprint, preferiblemente en otro color llamativo (como el rojo)
Te adjunto una imagen que ayudará a explicarme mejor.
Saludos,
--
En el gráfico de burndown, haz una marca en el dia del sprint (D) en el que se acuerde añadir las historias de usuario, P puntos por encima de la marca de referencia para ese día. (P es el número de puntos de historia añadidos al sprint)
Traza una linea recta desde esa marca al punto final del sprint, preferiblemente en otro color llamativo (como el rojo)
Te adjunto una imagen que ayudará a explicarme mejor.
Saludos,
2012/3/1 fegoal <sgom...@gmail.com>
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.
--
Adrián Perreau de Pinninck Bas, Ph.D
LinkedIn: http://es.linkedin.com/in/eidrien
Twitter: @eidrien
Antonio de la Torre
Mar 1, 2012, 6:20:21 PM3/1/12
to agile...@googlegroups.com
Hola:
Creo que la solución que propone Adrián está muy bien. Te preocupa
solo la gráfica por lo que he entendido.
Es una gráfica normal, sólo que marcas cuándo se produjo la entrada de
nuevas historias.
Pero vamos, ya que preguntas va pregunta de vuelta.... eso de medir
cada miembro del equipo por separado suena bastante fuerte. Qué opina
tu equipo de eso? Asignas puntos a cada miembro del equipo... eso no
suena muy auto-organizado.
Creo que hay que darle una vuelta a ese concepto de equipo si quieres
que sea ágil.
Saludos
El día 1 de marzo de 2012 19:59, Adrian Perreau de Pinninck
<aper...@gmail.com> escribió:
Harald Messemer
Mar 1, 2012, 7:52:17 PM3/1/12
to agile...@googlegroups.com
Una manera alternativa para reflejar un cambio de alcance es esta:
La ventaja es que se mantiene la escala que refleja la velocidad del equipo y a la vez se ve el cambio del alcance.
Un saludo,
Harald
<Burndown.jpg>
Daniel Ceillan
Mar 1, 2012, 7:58:59 PM3/1/12
to agile...@googlegroups.com
El 1 de marzo de 2012 15:03, fegoal <sgom...@gmail.com> escribió:
Por qué os sorprende tanto el uso de burndowns individuales ? Además
de tener al burndown general del sprint (o del equipo), quiero medir
la velocidad de quemado de cada uno de los compañeros y teniendo en
cuenta que todos tienen asignados una cantidad de puntos muy parecida,
creo que no está mal ver en un gráfico como los van quemando a lo
largo de la duración total del sprint.
Esta perfecto si es lo que necesitas hacer, pero definitivamente no es agil.
Por ejemplo nunca haces pair programming. Perdiendo sus beneficios.
Es un factor de presion psicológica para el individuo, y alienta la competencia entre pares, lo cual puede llevar al desastre.
Estas pretendiendo que todos los desarrolladores lleven el mismo ritmo, lo cual es un gran desperdicio. Mas alla de lo agil o no agil, es un desperdicio.
Por lo que dices, tu les asignas los puntos o tareas, eso es todo lo contrario a un equipo auto-organizado. Esto resta motivacion.
Con respecto al tema de cambiar el backlog sacando tareas me es
imposible, lo único que puedo hacer es añadir dos tareas mas (de pocos
puntos). Pero quiero reflejarlo en los gráficos de burndown del sprint
y en los gráficos de burndown de las personas que les toque
acometerlas.
A esto la respuesta es la que te dieron. Se hace una recta vertical con los puntos que añadiste y desde ahi sigues quemando.
Las tareas ya están estimadas, son posibles de realizar en el tiempo
establecido. La pregunta era como reflejarlas en los gráficos de
burndown correspondientes. Hay que rehacer cada gráfica hay que poner
una gráfica paralela ?, no se como se hace de la forma mas correcta.
Bueno ya que preguntas, lo mas correcto seria tener un solo burndown. Y no debes rehacerlo sino actualizarlo.
Saludos y suerte!
fegoal
Mar 2, 2012, 2:33:28 AM3/2/12
to agile-spain
Tampoco yo soy partidario de medir la velocidad de quemado de cada uno
de los miembros del equipo. No es un equipo heterogeneo, no tienen la
misma experiencia, no conocen el sistema con la misma profundidad,
etc.... Pero como todos sabemos muchas veces (quizá demasiadas),
tenemos que hacer cosas con las que no estamos de acuerdo.
Por otra parte estos graficos individuales, son sólo para mi y mi jefe
y no están accesibles a todo el mundo.
En la compañía llevamos muy poco tiempo intentando dar un enfoque ágil
a la gestión del dpto. de desarrollo. Vamos aprendiendo de nuestros
errores (eso espero). Hace poco tiempo que tuve la primera toma de
contacto con Scrum y me parece un modelo muy a tener en cuenta, aunque
haya que luchar con el usuario, el director, etc.... creo que lo
seguiré intentando.
Desde ya, quiero daros las gracias por vuestras aportaciones, y en un
plazo razonable de tiempo poder hacer aportaciones a este grupo.
On 2 mar, 01:58, Daniel Ceillan <codigodan...@gmail.com> wrote:
de los miembros del equipo. No es un equipo heterogeneo, no tienen la
misma experiencia, no conocen el sistema con la misma profundidad,
etc.... Pero como todos sabemos muchas veces (quizá demasiadas),
tenemos que hacer cosas con las que no estamos de acuerdo.
Por otra parte estos graficos individuales, son sólo para mi y mi jefe
y no están accesibles a todo el mundo.
En la compañía llevamos muy poco tiempo intentando dar un enfoque ágil
a la gestión del dpto. de desarrollo. Vamos aprendiendo de nuestros
errores (eso espero). Hace poco tiempo que tuve la primera toma de
contacto con Scrum y me parece un modelo muy a tener en cuenta, aunque
haya que luchar con el usuario, el director, etc.... creo que lo
seguiré intentando.
Desde ya, quiero daros las gracias por vuestras aportaciones, y en un
plazo razonable de tiempo poder hacer aportaciones a este grupo.
On 2 mar, 01:58, Daniel Ceillan <codigodan...@gmail.com> wrote:
Patricio Letelier
Mar 2, 2012, 3:04:48 AM3/2/12
to agile...@googlegroups.com
Hola,
Lo que comentas es uno de los posibles eventos que pueden ocurrir durante el sprint, en este caso se trata de un "Ajuste en Estimación" o de "Trabajo Añadido". Otros eventos pueden ser: Introducción de estimación faltante,Ítem añadido al sprint, Ítem quitado del sprint, Ítem sin estimación, etc. Cuando estos eventos NO son tenidos en cuenta en la lectura de los puntos del Burndown probablemente la interpretación será incorrecta.
Puedes encontrar más detalles al repecto en este post.
Un saludo,
Daniel Ceillan
Mar 2, 2012, 8:33:33 AM3/2/12
to agile...@googlegroups.com
El 2 de marzo de 2012 04:33, fegoal <sgom...@gmail.com> escribió:
Tampoco yo soy partidario de medir la velocidad de quemado de cada uno
de los miembros del equipo. No es un equipo heterogeneo, no tienen la
misma experiencia, no conocen el sistema con la misma profundidad,
etc.... Pero como todos sabemos muchas veces (quizá demasiadas),
tenemos que hacer cosas con las que no estamos de acuerdo.
Por otra parte estos graficos individuales, son sólo para mi y mi jefe
y no están accesibles a todo el mundo.
En la compañía llevamos muy poco tiempo intentando dar un enfoque ágil
a la gestión del dpto. de desarrollo. Vamos aprendiendo de nuestros
errores (eso espero). Hace poco tiempo que tuve la primera toma de
contacto con Scrum y me parece un modelo muy a tener en cuenta, aunque
haya que luchar con el usuario, el director, etc.... creo que lo
seguiré intentando.
Desde ya, quiero daros las gracias por vuestras aportaciones, y en un
plazo razonable de tiempo poder hacer aportaciones a este grupo.
Hola!
Solo tratamos de ayudarte, no era mi intencion intimidarte. Por supuesto que cuentas con nuestra ayuda!
La migración a ágiles es dura. La filosofía es fácil de entender pero dificil de aplicar. Sobre todo porque involucra abandonar viejos habitos toxicos, y adquirir nuevos no-toxicos. Es equivalente a dejar de fumar... asi que paciencia!
Justamente uno de los habitos tóxicos es el "control del personal". Por eso el agilismo plantea que parte de las responsabilidades del antiguo "Manager" ahora recaigan en el "Equipo". Y muchas responsabilidades son del "Equipo" no de Juan o Pedro. En este caso queda naturalmente en manos del equipo ver si alguien esta haciendo bien el trabajo o no. Sucede naturalmente en un ambiente libre de manipulacion.
Lo primero que te recomendaria para empezar a ser "agil" es "no hagas nada y observa". Deja que tu equipo se auto-organice, y estate atento a sus necesidades. No manipules, no asignes tareas, no comandes.
Y el otro punto importante son las retrospectivas. Una por sprint pero debe haber mejoras semanales.
Saludos!
fegoal
Mar 3, 2012, 2:57:03 AM3/3/12
to agile-spain
Hola Daniel.
No te preocupes que no me has intimidado. Creo que aquí estamos todos
a lo mismo. Aprender y compartir experiencias.
Gracias y un saludo.
On 2 mar, 14:33, Daniel Ceillan <codigodan...@gmail.com> wrote:
No te preocupes que no me has intimidado. Creo que aquí estamos todos
a lo mismo. Aprender y compartir experiencias.
Gracias y un saludo.
On 2 mar, 14:33, Daniel Ceillan <codigodan...@gmail.com> wrote:
Reply all
Reply to author
Forward
0 new messages