Reasignacion de puntos de historia durante un sprint.

[Marco A. Alba]

Hola compañeros, soy P.O. en un proyecto hace poco (mi primer proyecto) y me gustaría ver cómo resolveis este caso los veteranos en esta metodología para llevar el control de la velocidad del equipo y los puntos de historia resueltos.
Cuando a mitad de un sprint hay una reevaluación de puntos de historia porque hubo una evaluación muy optimista.
¿Cómo lo tratais?
¿Y si la evaluación fue pesimista y los puntos de historia son menores?

Usamos Jira y al final del sprint no nos cuadrarán las gráficas que genere de Burndown con las reales del sprint que llevamos en el panel porque variarán los puntos de historia conseguidos.
¿Cómo cuadráis este desfase?

Gracias y un saludo.
Marco A. Alba

[Juanma Gómez]

Hola Marco.

Si esto que te pasa es ocasional, no le daría mayor importancia, en el conjunto del proyecto no debería tener mucha repercusión. Sin embargo, si es algo habitual, creo que es síntoma de otra cosa, y ahí pondría el foco entonces. 

Entiendo, así mismo, que lleváis un cálculo de la desviación entre el esfuerzo estimado y el real. ¿Es así?

Un saludo.

--

Juanma Gómez

http://juanmagomezr.es

--
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 mensaje de correo a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un mensaje de correo a agile...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/164e307e-2575-4bae-9983-14f9f67acabd%40googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Marco A. Alba]

Efectivamente, aunque como estamos empezando, ese cálculo de la desviación es sólo orientativo. No le damos prácticamente valor. Ahora para nosotros es más importante detectar cuál es la velocidad de crucero del equipo, para que nuestras estimaciones sean más realistas.
Mi preocupación es, por ser un poco purista, dónde quedan reflejados esos puntos de esfuerzo que se han realizado de más o de menos. En Jira no podemos reevaluar puntos de historia en medio de un sprint y hay un desfase que no se recupera. Quería saber qué hacen otros equipos en relación con este tema. Por lo que veo, no tiene mayor importancia.
Gracias Juanma

[Helder De Oliveira]

Hola Marco.

Felicidades por el inicio del proyecto.

Varias cosas:

• "Cuando a mitad de un sprint hay una reevaluación de puntos de historia porque...": no reevaluéis, sin importar los motivos, seguid adelante y aprended de ello sprint tras sprint. 
• "...porque hubo una evaluación muy optimista": sprint tras sprint tenderá a realista, los primeros sprints, mientras el equipo conoce su velocidad y sus capacidades, pueden llegar a existir estos desconocimientos...
• Pero!, pero hay que mirar con lupa otras cosillas:
• Estimadores: es el equipo quien estima las historias que entran en el sprint gracias a las aclaratorias del Product Owner y la guía del ScrumMaster, por lo tanto...
• Árbitro: ...es importante que el ScrumMaster guíe, sobre todo en las primeras etapas, los eventos de planificación intentando garantizar la correcta ejecución del evento, y además...
• Compromiso: al final del proceso de planificación el resultado es el compromiso del equipo sobre las tareas que entran en el sprint una vez consensuadas con todas las partes.
• Y una cosa más: es muy raro ver una curva esperada del sprint idéntica a una curva real del sprint. Siempre habrá alguna desviación, algún pequeño retraso o adelanto en alguna tarea, pero el compromiso del equipo se debe perseguir y debe ser manifestado en la demo...
• Si no se ha llegado al objetivo del sprint, la retrospectiva es un momento espectacular y único para sacar este tema y buscar soluciones:
• ¿Hemos estimado mal?
• ¿No hemos puesto todo el empeño necesario en entregar a tiempo y con calidad lo prometido?
• ¿Nos hemos centrado demasiado en una planificación pensada en tiempo en lugar de una planificación pensada en pesos ponderados? (ej: una facilidad para que el usuario obtenga una información puntual vs. una facilidad para que el usuario realice una tarea compleja)
• ¿No ha aburrido tanto la planificación que hemos pasado de discutir los pesos y hemos promediado las respuestas diversas de todo el equipo?
• ¿Qué podemos hacer en la siguiente planificación para que esto mejore?
• ¿Cuáles son las tareas que podemos ejecutar y quién se encargará de perseguirlas para mejorar en este tema?
• etc etc etc

Por lo pronto no te estreses con el Jira ni con cualquier herramienta que uséis, intercambia esta información de forma transparente con la persona que crees que pueda "echar chispas" si las gráficas son diferentes y tráelo al proyecto, implícalo en el proceso y en sus mejoras...

...al final esto va de personas, no de procesos ni herramientas.

Éxito! y ya nos contarás

Helder De Oliveira
http://about.me/helderdeoliveira
https://twitter.com/HelderDOliveira

http://www.ambidieXtro.com

El 18 de marzo de 2014, 12:07, Marco A. Alba <malb...@gmail.com> escribió:

[Helder De Oliveira]

Te dejo por aquí un escrito de Rasmusson sobre "la manera espartana" de lograr objetivos y qué ocurre cuando se estima mal:

http://pragprog.com/magazines/2010-12/way-of-the-agile-warrior

Espero sea de ayuda.

Saludos.

Helder De Oliveira
http://about.me/helderdeoliveira
https://twitter.com/HelderDOliveira

http://www.ambidieXtro.com

[Israel Alcázar]

Hola,

Por añadir algo mas a las respuestas:

1.- Coincido con ambos en que si es el primer sprint suele ocurrir que las estimaciones no son muy buenas sobre todo si el equipo es la primera vez que trabajan juntos y la tecnología es mas o menos conocida.

2.- Nunca estires los sprints como "solución fácil" al problema de no llegar ya que a la larga perderemos ritmo.

3.- Utiliza la retro, es el mejor lugar para tratar esto como bien se comenta.

4.- Puede ser que ese problema en las estimaciones venga por una mala definición de requisitos al inicio del sprint?. Esto es por echar algo de responsabilidad al PO ;-)

5.- A mi me gusta mucho el método MOSCOW para establecer la pila del sprint. De manera que se establecen unos mínimos a entregar y unos deseables. 

http://en.wikipedia.org/wiki/MoSCoW_method

Mis dos céntimos.

Un saludo.

Israel Alcázar Rodríguez
israel...@gmail.com

--

Foodies experiences in: http://agiletaste.com

About me: http://ialcazar.com

My blog: http://www.farmerdev.com

Twitter: @ialcazar

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAFyq09c%2BifgOtqyGGR%2BTMZuv-nWzJbX83E-M0Jq6FEGPQLxkBg%40mail.gmail.com.

[Agustín Villena]

Hola Marco:

Algunos tips que te pueden servir:

- Los puntos son ESTIMACIONES antes de que realmente sepoas que tan complejo es un trabajo. Te recomiendo al final de cada semana MEDIR el esfuerzo real de las tareas finalizadas para ir creando una "regla de medicion" que te permita estimar mejor. Este metodo esta explciado en este video que hice hace unos años atras https://drive.google.com/file/d/0B2d43jac4M4ELVNmNFlEd3lHSk0/edit?usp=sharing

Para realizar la medicion de lo ya realizado, el juego màs eficiente que conozco es el Team Estimation Game propuesto por Alan Shalloway http://www.netobjectives.com/resources/articles/team-estimation-game

- Si la herramienta no te permite aprender, usa una màs liviana, por ejemplo, en papel o pizarra o excel. Este principio se llama "Tavel Light" y fue propiuesto por XP http://tutorials.csharp-online.net/Introducing_XP%E2%80%94XP_Principle_14:_Travel_Light 

- Es mejor hablar de "tasa de entrega" en vez de "velocidad" para medir la capacidad del equipo. Si hablamos de "Velocidad" estamos sugiriendo que se puede "acelerar", y no es asi. Al poner mas demanda la tasa de entrega disminuye por la congestion provocada

Saludos

  Agustin

[José Manuel Beas]

Hola a todos,

¿Para qué estimamos las historias? A ver, no quiero abrir el debate #NoEstimates. Suponiendo que habéis decidido estimar (y que no lo hacéis porque sí o "porque nos han dicho que lo hagamos"), ¿cuál es la utilidad de estimar el trabajo que planificamos?

Para no dejarlo en un pregunta retórica voy a dar mi respuesta.

A mi me gusta estimar en aquellas condiciones en las que ser predecible es un valor, es decir, cuando tenemos que dar respuesta a preguntas del tipo "¿para cuándo crees que este montón de funcionalidad podrá estar acabada?". También me gusta estimar cuando el equipo recibe historias que a veces son muy grandes y el trabajo de estimar provoca conversaciones que ayudan en el proceso de refinamiento. Pero también me gusta estimar cuando los equipos tienen problemas (sobre todo por falta de madurez) a la hora de conocer su ritmo sostenible.

En general, me uno a los comentarios anteriores que el análisis sobre cómo evitar las grandes variabilidades entre estimaciones en el sprint plan y el sprint review a la retrospectiva. Personalmente no aconsejo revisar la estimación porque es "waste". La reducción en la velocidad del equipo ya nos da la pista de que algo no ha funcionado en el sprint. También me gusta usar post-its de otro color para que el equipo indique aquellas tareas que han emergido durante el desarrollo fruto de una mala planificación en el sprint planning meeting.

Sólo un último apunte respecto al "compromiso" del equipo respecto del sprint plan. No me gusta asociar la palabra compromiso a la palabra estimación. Prefiero decir que el equipo se compromete a "hacer el mejor trabajo posible, a un ritmo sostenible y respetando el plan elaborado junto al PO durante la reunión de planificación".

Un cordial saludo,

Jose Manuel Beas

http://about.me/jmbeas

[Helder De Oliveira]

Macho es que "hacer el mejor trabajo posible, a un ritmo sostenible y respetando el plan elaborado junto al PO durante la reunión de planificación" en twitter solo me deja 6 caracteres para despedirme 

Ahora que comentas lo de y que no lo hacéis porque sí o "porque nos han dicho que lo hagamos", creo que tenemos que abrir un debate en el que no estamos entrando, o hemos entrado poco y me temo que la gente que necesita escuchar sus conclusiones no está por la lista o no estamos llegando lo suficiente a ellos: Jefes y Proyectos Cerrados

Un abrazo.

Helder De Oliveira
http://about.me/helderdeoliveira
https://twitter.com/HelderDOliveira

http://www.ambidieXtro.com

--
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 mensaje de correo a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un mensaje de correo a agile...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAD8mR92AXouRTf10UJBb9Kuf3HZ7WJEh-vfj8YrbX%2BancPT90Q%40mail.gmail.com.

[Marco A. Alba]

No quiero meterme en medio de vuestra discusión, aunque me encanta de modo indirecto haberla provocado. Estoy empezando así que mi experiencia es casi nula.
Yo creo que está todo relacionado con lo mismo. El error es mío porque no me he quitado todavía los malos hábitos adquiridos. En este caso el utilizar tiempo para justificar que las cosas se han hecho del modo correcto en lugar de aprovecharlo en estudiar cómo mejorar mis capacidades y aplicar esa mejora al siguiente sprint.
No es tan importante justificar la desviación como conocer el por qué se ha producido o qué la ha generado, para corregirlo. Mejorar y avanzar.

Tengo que decir que me encanta esta comunidad, sois muy participativos y compartis enseñanzas que no tienen precio. Para los que empezamos tiene un valor enorme. Espero algún día poder aportar tambien yo mi granito de arena, y seguir aprendiendo de vosotros.
Muchas gracias a todos.
Marco

[Alfredo Casado]

Si mal no recuerdo en jira tienes 3 cosas:

  - La estimación inicial.

  - El tiempo empleado

  - Lo que falta para terminar

No me gusta mucho de jira que fuerza a trabajar con tiempo en lugar de con historias estimadas en tamaño que es IMMO mejor idea, puedes apañarlo y entender horas o días como puntos claro. De todos modos, simplemente todos los días vas ajustando lo que te falta para terminar (que es el valor más importante) y la estimación inicial no la cambies, de esta manera tienes todos los datos para luego como te comentan en la retrospectiva investigar entre todos que ha pasado, si la desviación es importante o es algo puntual etc,etc. y como bien dices, sacar enseñanzas para mejorar.

Y las gráficas y tal, eso de que cuadren o no tampoco me preocuparía demasiado, no hacemos gráficas, hacemos software.

Para anular tu suscripción a este grupo y dejar de recibir sus mensajes, envía un mensaje a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un mensaje a agile...@googlegroups.com.

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/0c6af330-d5aa-4ba4-b8fd-897f7f1bd9fb%40googlegroups.com.

[Israel Alcázar]

Alfredo, lo bueno de Jira es que siempre puedes añadir campos y crear tus propios schemas de issues para adaptarlo a la problemática :D

No es que me lleve comisión pero es una de las herramientas mas versátiles que conozco para poder adaptarlo a todas las necesidades.

Israel Alcázar Rodríguez
israel...@gmail.com

--

Foodies experiences in: http://agiletaste.com

About me: http://ialcazar.com

My blog: http://www.farmerdev.com

Twitter: @ialcazar

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/CAJUW-yZxXuFZB2VT3uspbGsp0-%2BfShGL77ZapZY8%3DBM4VRhLAg%40mail.gmail.com.

[Juanma Gómez]

De todas formas, chicos, estaría bien no desviar el foco hacia una herramienta :D

Marco, te recomendaría que tiraras hacia adelante y nos vayas contando. Así podremos serte de más ayuda,

¡Un abrazo!

--

Juanma Gómez

http://juanmagomezr.es

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/CAKCURLzXgCXJ-dYwK%2Bh8nfgUL0QhrebVSXTu36uLiQfZad%2B70A%40mail.gmail.com.

[Antonio de la Torre]

Hola!

Espero no llegar tarde.

Marco, creo que entiendo tu problema.

Estoy de acuerdo con lo hablado y que tú has dicho con tus palabras:

- preocúpate de mejorar y ver qué ha sucedido

- no te preocupes en justificarte.

Y es que de eso se trata. 

Los puntos es una estimación de complejidad, no es una cantidad de trabajo, no sabes lo que te va a llevar, pero te hueles algo. 

Los puntos al final del sprint no es un parte de horas.

Si alguien hecha la cuenta: "Si sois cuatro y hacéis 1 punto al día por persona, entonces tendríais que hacer 40 puntos. Habéis hecho 22. ¿Dónde están el resto de puntos?"

Que supongo de ahí viene lo de reestimar.

No reestimes para justificar que has estado trabajando toda la semana. Eso se supone. No has estado en otros proyectos o tocándote las narices.

Dices:

"Mi preocupación es, por ser un poco purista, dónde quedan reflejados esos puntos de esfuerzo que se han realizado de más o de menos."

Si has hecho 22 puntos, pues esa es tu velocidad del sprint que acaba de terminar.

En la retrospectiva analiza y aprende a estimar mejor aquellas historias que te han explotado en la cara y sigue adelante.

Pero es que realmente no has hecho puntos de más o puntos de menos, has entregado (o no) una historia. Period.

A partir de ahí, si quieres puedes llevar una cuenta de horas invertidas en el sprint, para conocer la ratio punto/hora, pero eso lo puedes sacar de vuestro parte de horas de proyecto o lo que tengáis para imputar horas, que seguro que tenéis algo :-)

Espero no haya quedado muy largo.

Saludos,

Antonio

--
Twitter: @adelatorrefoss

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAN1zvPfzVLK%3DXLjjbUcue1joKKas%2BEdM_icGphSK3OZjPTso6A%40mail.gmail.com.

[José Manuel Beas]

+1 a Antonio, menos a lo del parte de horas. Un equipo estable hace tantas horas como han pasado desde el inicio del sprint hasta el final, e.d., las mismas en cada sprint (vacaciones aparte). No hay que darle más vueltas IMHO. El tiempo pasa (y no perdona, je, je). Lo que cuenta, e.d. lo que deberíamos medir es el valor de negocio aportado durante cada sprint (o una buena simplificación, como los puntos de las historias entregadas).

BTW, Marco, esta generosidad no es gratuita. A cambio estás adquiriendo el compromiso de hacer lo mismo en el futuro para que los nuevos también puedan obtener ayuda. ;)

Un saludo,

Jmbeas

--

[Marco A. Alba]

Por supuesto Jose Manuel, si no lo hiciera sería muy egoista por mi parte. Aunque haya que poner mis cometarios en cuarentena ;-) , aquí hay mucho conocimiento y mucha experiencia. Procuraré no decir tonterias.
De todas formas me encanta el ambiente colaborativo y de divulgación que teneis, ha sido un acierto caer aquí.

Antonio, muchas gracias por tu aportación. Me has entendido perfectamente. Supongo que me adaptaré conforme vayan cayendo historias, como horas de vuelo para los pilotos.

Un saludo.
Marco A. Alba.