Quién estima las historias

[José Manuel Beas]

He cambiado el asunto porque me ha parecido interesante un aspecto que comentaba Jorge en el hilo "Mi primera vez: estimar historias" y que yo hago diferente.

Se trata de quién y cuándo se estiman las historias de usuario que forman la pila de producto (no la del sprint, sino la del producto).

Para mi es más que suficiente que las historias las estimen el dueño del producto y el líder tecnológico (no hablo del scrummaster ni tampoco hablo del arquitecto). Me refiero a ese miembro del equipo al que todos le preguntan cuando hay que decidir algo técnicamente hablando. Mi experiencia es que las reuniones de todo el equipo más el dueño del producto y algún allegado al final no son mucho más productivas ni reveladoras que una serie de pequeñas reuniones del dueño del producto y el líder tecnológico que sirven para ir manteniendo actualizada la pila de producto. Además, es más barato. ¿Habéis pensado alguna vez cuánto dinero cuesta una reunión de 7 personas durante dos horas? ;-)

Obviamente, las tareas las estima el equipo. Nadie mejor que el equipo para decidir cómo se hace una historia y, por tanto, cuánto costará en detalle. Pero normalmente, no va a ser muy diferente lo que "sumen" las estimaciones del equipo con lo que se haya estimado previamente la historia de usuario.

¿Cuál es vuestra experiencia? ¿Cómo os funciona mejor?

Un saludo,
JMB

2010/3/2 Jorge Uriarte Aretxaga <jorge....@gailen.es>

Lo que es muy importante es que la estimación de las historias se haga
en equipo, se use planning poker o cualquier otra técnica que evite la
influencia excesiva de unos sobre otros (obligar a pensar y opinar a
todos), se debatan las historias e incluso se amplíen sus definiciones
si se ve necesario pero, sobre todo, que *se desvincule esa estimación
de la división en tareas de cada historia y de su esfuerzo temporal
previso*

Luego, en otra reunión, se puede hacer la autoasignacion de historias,
división de tareas, y las proyecciones temporales de esas tareas si
las hay (porque eso, si deben estimarse las tareas o no, o si deben
reducirse todo a tareas "talla única" o sí... eso es otro debate ;) )

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

[Jorge Uriarte Aretxaga]

A mí me funciona mejor que las estimaciones las haga el equipo por
varios motivos:
- Se recorre el dominio de la aplicación y se aclaran dudas para todos
- Se transmite experiencia (los juniors descubren cosas que deben
tener en cuenta y que los seniors sacan a relucir, tanto soluciones
que simplifican la complejidad como problemas que pueden aparecer
ocultos a ojos inexpertos.
- Genera sensación de *proyecto* y elimina los silos funcionales de inicio.
- Facilita que todos entendamos *de antemano* las historias para luego
generar tareas.

Entiendo tu enfoque, JM, y estoy de acuerdo en que si, por ejemplo, yo
me reuno con el owner, voy a poder hacer la estimación de complejidad
de todas las tareas. Pero ese tiempo que quieres ahorrar... lo vas a
emplear después poniendo en común la información, aclarando las dudas,
etc... durante la asignación y estimación de tareas, y para mí, es
mejor empleado y se obtiene mejor rendimiento de él *subiendo un
nivel* y poniendo a todo el equipo a pensar.

Hace unos meses, en unas charlas a jefes de proyecto de un cliente,
este era un punto que les dolía especialmente, y surgieron muchas
dudas:
- "¿Para qué voy a preguntar a un junior?" - Para que aprenda, para
que conocerle mejor, para aprender yo cuando él tenga razón!
- "¿Y si se equivocan?" - Normalmente los perfiles seniors (y el
"lider tecnológico") tienen influencia sobre los demás, basada en su
experiencia y en su respeto. Yo nunca he necesitado *imponer* una
estimación, y si nos atascamos, suelo considerar que es mejor ceder
(al fin y al cabo el desfase de una historia no es crítico en el
alcance de un proyecto) para favorecer el aprendizaje de todos.
- "Es más lento y costoso!" - A corto plazo, sí, te puede costar el
triple esa reunión (¿100 + 100 contra 100 + 100 + 50 + 80 + 80 + 60 +
50?) pero... ¿qué devuelve esa reunión? Conocimiento, equipo,
implicación, ritmo...

Para mí no hay duda. Si puedo elegir, prefiero que estime el equipo.

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

2010/3/2 José Manuel Beas <jose....@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.
>

[Vicenç Garcia]

+1 a Jorge

--
Vicenç García
http://devnettips.blogspot.com

[jorge]

Nosotros teníamos una reunión con el equipo y el product owner, repasábamos un poco el product backlog hasta donde creíamos que odríamos llegar... a ojo ;) Luego nos reuníamos nosotros, el equipo de desarrollo, y estimábamos por nuestra cuenta, decíamos cómo iba a quedar la iteración y listo. Tiempo total empleado: unas 4 horas.

Ahora lo que hacemos es reunirnos igualmente y hacer un taller de requisitos en toda regla en el que intentamos conocer el máximo detalle de lo que vamos a hacer en la iteración. Además, estimamos en directo basándonos en el criterio 'el experto'.

Después de esta reunión, nos volvemos a reunir el equipo brevemente y repasamos las estimaciones y las ajustamos. Después hay una reunión muy breve entre el product owner y yo mismo para comunicar cómo va a quedar finalmente y hacer los cambios y ajustes finales. total: 5 horas de reunión + 1h de ajuste.

La segunda aproximación nos evita la incertidumbre de tener que ajustar las tareas a mitad de sprint, problemas con el alcance y sabemos de qué hablamos con más o menos precisión pero aún creo que necesitamos mejorar para emplear menos tiempo. Además, el hecho de profundizar (relativamente, ojo) ha dado la sensación de que se hablaba de temas que NO se iban a abordar en el sprint, cosa que, sin entrar en debates, me parece buena porque tenemos el big picture y mala porque se *pierde* el tiempo.

Otra cosa que queremos introducir es una preview entre el product owner y yo mismo antes del planning, incluso mucho antes, en la que recojamos el product backlog y demos una aproximación de tamaño que ayude a priorizar y generar el sprint backlog. Esto lo podría llevar al equipo siguiendo el criterio 'el experto'.

Estoy 100% con Jorge en que el equipo tiene que participar, pero me da la sensación de que somos demasiados en la reunión y que se emplean muchos petrodólares. Supongo que iremos mejorando esto...

2010/3/2 José Manuel Beas <jose....@gmail.com>

He cambiado el asunto porque me ha parecido interesante un aspecto que comentaba Jorge en el hilo "Mi primera vez: estimar historias" y que yo hago diferente.

[José Manuel Beas]

Creo que a Jorge (Báez) y a mi nos pasa algo parecido con lo que dice Jorge (Uriarte).

Una parte de mi me dice que debería hacerte caso y CONFIAR en el equipo, pero otra parte de mi (la que ha sufrido infinidad de reuniones de horas y horas para discutir las historias de usuario y al final llegar poco más o menos a lo mismo que teníamos al principio) me dice que no es rentable.

No quiero decir que el equipo no sea el que tenga la última palabra sobre el CÓMO se debe hacer una historia de usuario. Estoy plenamente convencido que el equipo debe ser el único dueño del CÓMO se hace. Pero igual creo que el dueño del producto es el que decide QUÉ se hace. Pero en mi opinión es mucho más fácil de aclarar y acordar los detalles fundamentales del QUÉ se hace entre dos personas expertas y con visión de conjunto que con un grupo heterogéneo de varias personas, y no porque sean menos capaces sino porque son personas y la comunicación se dificulta cuando hay mucha gente a comunicar.

Creo que los detalles finos no deberían (condicional simple) modificar la estimación, salvo que ésta no se haya trabajado suficientemente o que, durante la preparación del sprint, surja algo realmente significativo que quizás nos debería llevar a plantearnos el "scope" de la historia.

Peligros:
* que el dueño de producto y/o el líder tecnológico no trabajen suficientemente las historias => nos encontramos con reuniones de sprint planning como las que he descrito, donde se hace necesaria la presencia del dueño del producto para aclarar las dudas que el lider técnico no puede resolver
* que el líder técnico no sea muy bueno => el equipo encuentra en el sprint planning problemas o soluciones que cambian sustancialmente las estimaciones

Pero ambos problemas, si aparecen, me parece incluso bueno porque es una oportunidad de mejora.

Un saludo,
Jose Manuel Beas

http://agilismo.es
http://jmbeas.iExpertos.com <-- ¡Me he mudado!
http://twitter.com/jmbeas

[jorge]

Ojo: yo creo que el equipo es el que tiene que hacerlo para mantener la sensación de eso, de equipo, de adquirir un compromiso, objetivo común, participación, etc. Lo que yo creo que se puede mejorar es la preparación del planning, ni más ni menos. ;)

Aún no lo he hecho, pero creo que antes es bueno que el PO tenga una estimación preliminar de tamaño que le puede ayudar a priorizar o a *partir* la funcionalidad deliberadamente en lugar de hacerlo en la propia reunión. Esto puede ser tan tonto como hacer la lista de las n primeras entradas en el backlog, que me las pase y yo las circulo informalmente por el equipo a quien crea conveniente. Con esto podemos enfocar el planning detectando posibles necesidades y adelantándonos, quizá trabajando conjuntamente para elaborar material para la reunión en función de la complejidad detectada: si esto es muy chungo, mejor que lo tengamos relativamente claro, lo hayamos pensado, hayamos hablado antes con tal o cual, detectado alguna dependencia (tenemos el diseño y maquetación web externalizado y esto no encaja siempre todo lo bien que querríamos :P ) o lo que sea.

Ahora mismo somo 4 humanoides + PO + algún invitado * 5horas = 30horas. Se acerca mucho al trabajo de una semana de una persona, que me parece una auténtica locura... Aunque sería como dedicarle una hora y media al día a planificar, que tampoco es tanto :P

La reunión se hace pesada, hacemos breaks y tal pero son 5 horazas. Yo creo que si conseguimos bajarlas a 3 habiendo sacado la misma información podemos considerarlo un auténtico éxito. Otra opción es acortar las iteraciones.

Quiero añadir que nosotros somos una empresa pequeña en la que todos somos arte y parte, así que estas reuniones sirven para que participemos en general en las cosas que hacemos y que cada uno ponga su granito de arena... sí, también está el product backlog ;)

2010/3/2 José Manuel Beas <jose....@gmail.com>

Creo que a Jorge (Báez) y a mi nos pasa algo parecido con lo que dice Jorge (Uriarte).

--

[Jorge Uriarte Aretxaga]

>
> Una parte de mi me dice que debería hacerte caso y CONFIAR en el equipo,
> pero otra parte de mi (la que ha sufrido infinidad de reuniones de horas y
> horas para discutir las historias de usuario y al final llegar poco más o
> menos a lo mismo que teníamos al principio) me dice que no es rentable.
>

¿Discutir la estimación o discutir las historias?

> más fácil de aclarar y acordar los detalles fundamentales del QUÉ se hace
> entre dos personas expertas y con visión de conjunto que con un grupo
> heterogéneo de varias personas, y no porque sean menos capaces sino porque
> son personas y la comunicación se dificulta cuando hay mucha gente a
> comunicar.
>

De nuevo... ¿hablamos del QUÉ? El owner puede contar con perfiles
técnicos para la discusión, definición, posibilidades tecnológicas,
implicaciones a alto nivel, idoneidad de la plataforma para los
objetivos, lo que sea...

Pero pensaba que hablábamos de ESTIMAR... y eso no es QUÉ, en mi opinión...

> Creo que los detalles finos no deberían (condicional simple) modificar la
> estimación, salvo que ésta no se haya trabajado suficientemente o que,
> durante la preparación del sprint, surja algo realmente significativo que
> quizás nos debería llevar a plantearnos el "scope" de la historia.

La estimación en complejidad varía porque nos equivocamos, claro,
aunque en mi parte considero un waste actualizarla, salvo en casos en
que sea muuuuy grande el desfase.
Otra cosa es la estimación en tareas. Ahí, prefiero que los cambios
*surjan*, aparezcan nuevas tareas, crezcan los ETCs reconocidos por
los miembros del equipo...

_
Jorge

[Jorge Uriarte Aretxaga]

> Ahora mismo somo 4 humanoides + PO + algún invitado * 5horas = 30horas. Se
> acerca mucho al trabajo de una semana de una persona, que me parece una
> auténtica locura... Aunque sería como dedicarle una hora y media al día a
> planificar, que tampoco es tanto :P

Entonces... ¿es una locura, o tampoco es tanto? ;) ;) ;)

> Quiero añadir que nosotros somos una empresa pequeña en la que todos somos
> arte y parte

Y esto debería ser uno de los objetivos de todo equipo, conseguir que
todos nos sintamos arte y parte del proyecto, así que supongo que vais
por buen camino :D

_
Jorge

[jorge]

2010/3/2 Jorge Uriarte Aretxaga <jorge....@gailen.es>

> Ahora mismo somo 4 humanoides + PO + algún invitado * 5horas = 30horas. Se

> acerca mucho al trabajo de una semana de una persona, que me parece una
> auténtica locura... Aunque sería como dedicarle una hora y media al día a
> planificar, que tampoco es tanto :P

Entonces... ¿es una locura, o tampoco es tanto? ;) ;) ;)

Visto como una reunión de 5 horas me parece mucho.

Visto como 30 y pico horas me parece mucho.

Visto como una hora al día ya me parece menos.

Pero 18 horas me parece mucho mejor en todos los aspectos ;)

 

> Quiero añadir que nosotros somos una empresa pequeña en la que todos somos
> arte y parte

Y esto debería ser uno de los objetivos de todo equipo, conseguir que
todos nos sintamos arte y parte del proyecto, así que supongo que vais
por buen camino :D

Con esto me refería a que no somos una empresa de servicios, sino que construimos nuestro propio proyecto... Por contextualizar :P  

 

[Juan Carlos Quijano Abad]

Buenos días,

Partes de la base erronea de que las estimacioens se hacen sobre las historias de usuario, cuando la mayoría de las veces se realizan sobre "humo". Es decir sobre lo que entiendes de lo que te está transmitiendo el cliente. O sobre un diagrama de gantt de tareas. O sobre un listado de módulos. Lo de las historias de usuario aún no he tenido el gusto de verlas actuar, aunque sé que algunos los utilizan.

Partiendo de esta base, en mi caso las estimaciones las hago yo junto con el responsable comercial. Para intentar encontrar el equilibrio entre mis intereses (no pillarme los dedos y tener un buen margen en el plazo) y sus intereses (hacerlo en el menor tiempo/coste posible). Son estimaciones basadas en la piel, a causa de mi desconocimiento en técnicas de estimación, y la experiencia de estimaciones anteriores.

Yo realizo dos estimaciones. Una de primera instancia para preparar el presupuesto con el que vamos a presentarnos a la oferta, y otra cuando se va creando la segmentación del desarrollo en módulos. Y despues llegamos a la estimación buena que es la que hago cada sprint con el equipo. Pero solamente cuando puedo utilizar Scrum. Con Kanban esa tercera estimación no la realizo. Y en ASM o CMMI no existe ese concepto... :(

Indudablemente como solo sé hacerlo de una forma, es la que mejor me sale. Me quedo a la espera de aprender en este post de esas técnicas que mejoren mi forma de estimar.

"¿Habéis pensado alguna vez cuánto dinero cuesta una reunión de 7 personas durante dos horas? ;-)"

Hay "pequeño Padawan", cuantos costes ocultos vas a ir descubriendo en la gestión de los proyectos... ;) (hay muchos, muchos más)

--
Un saludo
Juan Quijano

--
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.

--
Un saludo
Juan Quijano

[harr...@gmail.com]

Muy explicativo. Has medido la precision de tus estimaciones? Vamos, me refiero a las desviaciones en tiempo y esfuerzo, dejando al margen cambios de alcance durante los sprints, si se puede..

Un saludo,
Harald

Enviado desde mi BlackBerry® de Vodafone

---

From: Juan Carlos Quijano Abad <juancarl...@gmail.com>

Date: Wed, 3 Mar 2010 07:52:42 +0100

To: <agile...@googlegroups.com>

Subject: Re: [agile-spain] Quién estima las historias

[Juan Carlos Quijano Abad]

Buenos días,

Realmente no. cuando trabaje en unos proyectos en CMMI allí si que se miraba la precisión de las estimaciones. Pero en ASM y en SCRUM no las estoy midiendo más que con el resultado final. Si cumplimos o no el plazo.

Si consigo mantener Agile en mi empresa, se me plantea la duda de si tiene sentido medir dicha precisión ya que, como bien dices, los cambios de alcance son constantes en este tipo de proyectos (por eso utilizamos Agile) y las estimaciones son papel mojado de un sprint a otro.

Pero supongo que es el camino obligado para una mejora de los procesos.

--
Un saludo
Juan Quijano

[Ángel Medinilla]

Para mi es más que suficiente que las historias las estimen el dueño del producto y el líder tecnológico (no hablo del scrummaster ni tampoco hablo del arquitecto).

=8-(
 

[Ángel Medinilla]

Las estimaciones son eso: ESTIMACIONES, no juramentos. Medir la precisión de las estimaciones es confundir la herramienta con el objeto. El objetivo del proyecto no es acertar en las estimaciones: eso conlleva que todo el mundo sobrecargue cada estimación en la vana esperanza de que si nos "acolchonamos" en todo a saco, al final podremos cuadrar cada estimación. Lo cual no ocurre, por cierto, y por el camino doblamos plazaos y costes, perdemos competitividad y además no APRENDEMOS de las estimaciones y sus desviaciones, que es lo importante, ya que todas las estimaciones están en realidad ofuscadas.

Estimar muy bien no es "acertar" siempre. Estimar muy bien significa que unas las estimas por arriba, otras por abajo y, en media, estimas tantas por arriba como por abajo y el proyecto cuadra. Y eso no es precisión.

Estimar muy mal es estimar siempre por arriba o siempre por abajo. Eso es estimar muy mal y, con todos los respetos, ser un poco torpe: si estimas siempre por abajo, SUBE tus estimaciones. Pero claro, para eso debes observar tus estimaciones, aprender de ellas. Si es a eso a lo que llamábais analizar la precisión de las estimaciones... Bueno, en ese caso se trata solamente de una palabra mal elegida para mi gusto ;)



----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com

2010/3/3 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[Ángel Medinilla]

"¿Habéis pensado alguna vez cuánto dinero cuesta una reunión de 7 personas durante dos horas? ;-)"

Hay "pequeño Padawan", cuantos costes ocultos vas a ir descubriendo en la gestión de los proyectos... ;) (hay muchos, muchos más)

Hay costes y hay inversiones.

Para mi, dos horas al principio del sprint para que todo el equipo tenga una visión conjunta de lo que vamos a construir es imprescindible, y siempre paga.

Hace poco, con un cliente, realizábamos una estimación de una historia. El lider del equipo, el senior y la persona que tenía que desarrollarla estimaron 18. Un junior estimó 1. Cuando discutieron la estimación, el Junior dijo "pero si en el proyecto en el que estuve el mes pasado desarrollamos una librería que hace eso exáctamente, lo único que hay que hacer es importarla".

¿Cuanto ahorró ese equipo gracias a esa reunión?
 

[Ángel Medinilla]

Para mí no hay duda. Si puedo elegir, prefiero que estime el equipo.

+100% a Jorge. Que por cierto, es la postura defendida por *todos* los firmantes del Manifiesto, hasta donde yo se. 

[jorge]

+1 a estimar en equipo y que la reunión de planning es una inversión.

Pero c****, se puede mejorar ;)

2010/3/3 Ángel Medinilla <angel.m...@gmail.com>

 

Para mí no hay duda. Si puedo elegir, prefiero que estime el equipo.

+100% a Jorge. Que por cierto, es la postura defendida por *todos* los firmantes del Manifiesto, hasta donde yo se. 

[Ángel Medinilla]

 

2010/3/3 jorge <jorge...@gmail.com>

+1 a estimar en equipo y que la reunión de planning es una inversión.

Pero c****, se puede mejorar ;)

Siempre. ;)

No conozco vuestro caso en profundidad, pero por lo que cuentas puede ser un tema de dsciplina de reuniones y falta de un enfoque iterativo.

Un formato que nos suele funcionar bien es:

.- Moderación de la reunión por alguien reconocido como moderador.  Hay mucho material por ahí sobre esto.

.- Limitación del tiempo a 4 horas (para empezar - supondría una mejora del 20%). Limitación ESTRICTA, a las cuatro horas todo el mundo a la p*ta calle a rascar teclas, y si el sprint sufre, que sufra. Así la próxima vez lo tomaremos más en serio.

.- Iteración 1: 15 minutos. Hay que bosquejar toda la aplicación que vamos a desarrollar en el Sprint (TODA) en grandes épicas, estimadas y priorizadas (tìpicamente cuatro - siete épicas, dependiendo de tamaño de equipo y longitud de sprint). Cuando se acaba, se acaba. Las estimaciones serán groseras y arbitrarias.

.- Iteración 2: 45 minutos. Hay que divididir cada épica en historias. Estimadas. La suma de estas estimaciones sustituye a la anterior estimación de la épica. El moderador debe vigilar que no nos peguemos 20 minutos discutiendo la historia1, eso ya ser hará en la iteración 3.

.- Iteración 3: 1 horas. Refinamiento de las historias.

.- Iteración 4: 2 horas. División de las historias en tareas.

[German DZ]

Tal vez la estimación no te sirva para sabe si vas a entregar a tiempo o no, tampoco te sirve para que la gente sea más productiva, ni para tener más testeado el resultado. Las estimaciones sirven para conocer tu organización.

Desde la gestión, me interesa conocer que tan bien estima o no mi equipo. Puede ser un factor clave a la hora de cerrar negocios y puede ser lo que marque la diferencia entre cerrar negocios que terminan en ganancias o en pérdidas.

CMMI, claro que te va a pedir que estimes, y que lo hagas metódicamente. Si sos Agile, no veo porque no querrías hacerlo también.

Hacer que todos participen de la estimación es una forma de que la gente vaya aprendiendo, tal vez yo pueda estimar muy bien, pero si los demás no aprenden la organización depende demasiado de mi y eso es malo, muy malo porque en invierno me gusta irme de vacaciones a hacer snowboarding, en verano submarinismo, en primavera me gusta recorrer ciudades y en otoño también; así que mejor que la organización pueda vivir sin mi la mayor parte del tiempo.. además soy mortal.

2010/3/3 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[Juanjo Falcon]

+1 para Jorge

El pb. es que para eso tienes que tener al cliente (product owner) bien instruido y no suele ser lo normal.

En cuyo caso no queda otra que hacerlo en petit comite con el product owner por un lado, y luego hacerlo en interno con el equipo. Y como siempre a más intermediarios más pérdida de información.

Juanjo Falcon

[Harald Messemer]

Habitualmente pido a la gente que estime el tiempo que piensa necesitar para una tarea y que despues compare lo que ha tardado para identificar mejoras en la estimación y estimar mejor. Así la teoria, en la práctica cuesta por razones múltiples que se traducen en el argumento "no he tenido tiempo".

En este sentido, esfuerzo como indicador para comparar, se pueden cambiar por otro indicador como los user story points y medir despues de cada iteración si se consiguen los puntos previstos o más o menos. Gracias por la respuesta.

Un saludo,
Harald

2010/3/3 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[Harald Messemer]

Asi es, la palabra "precisión" te parece haber ofuscado. Por lo demás, se trataba de lo que dices: estimar, comparar con la realidad y ser mejor.

Un saludo,
Harald

2010/3/3 Ángel Medinilla <angel.m...@gmail.com>

[Ángel Medinilla]

 

2010/3/4 Harald Messemer <harr...@gmail.com>

Asi es, la palabra "precisión" te parece haber ofuscado.

Jejeje... Yo usaba ofuscación en el sentido de ocultación, encriptación... Y tu percibes ofuscación en mis palabras en el sentido de obstinación o vehemencia, lamento que se hayan percibido de tal forma, no era mi intención ;)

Siguiendo con los juegos de palabras,  el término "precisión" es impreciso en este marco... :D

Un saludo,

Ángel.

[Harald Messemer]

:))) El otro día alguien utilizaba "ofuscar" como sinonimo de "confundir". Como no soy de aquí utilizo palabras nuevas probandolas. Suele ir más rápido que consultar la real academia. En este sentido, disculpa la ofuscación.

Un saludo,
Harald

2010/3/4 Ángel Medinilla <angel.m...@gmail.com>

[Jordi Salvat i Alabart]

Si tienes problemas de rentabilidad del proceso de estimación: has
probado planning poker? Una vez que te acostumbras (y no cuesta
mucho), es realmente muy rápido, y cada vez que lo hago me doy cuenta
de que yo solito me habría equivocado en alguna tarea en por lo menos
el 200 o 300%.

Cuidado: hablo de la estimación, no de la definición de las historias,
que sigue siendo cosa del Product Owner con la ayuda que necesite.

--
Salut,

Jordi.