Estimación colaborativa

Esta clase me pareció un poco pobre.
Hay bastantes metodologías para estimar las historias de usuario y no hizo mención de ninguna:

• Poker Estimation
• RICE estimation
• MoSCoW Analysis
• Kano Model
• Opportunity model
• Cost of Delay
  Entre otras 😕

Información valiosa que esperaba encontrar en este capitulo:

Poker explanation:
https://www.youtube.com/watch?v=TxSzo3lwwWQ&t=59s

RICE:
https://www.youtube.com/watch?v=miI6KvwFHLI

MoSCoW:
https://www.youtube.com/watch?v=NJ2JM_PKXjk

Kano Model:
https://www.youtube.com/watch?v=Z3Zw6LPggQQ

TAM Model:
https://www.youtube.com/watch?v=M_RMTC2YmXY

Me gustó esa definición. Estimación colaborativa es la forma en la que yo puedo mostrar mi visión a los miembros del equipo y conocer, igualmente, lo que otros están viendo.

La técnica del juicio de expertos : Es la mas utilizada pero lamentablemente este experto no ejecuta todo lo del proyecto y su estimación queda por muy debajo de la realidad.

Utilizando un metodo tradicional es como ver un cubo y ver una sola cara.

Lo mas importante aca es hacerle ver a los demas que yo estoy viendo

Considerar los escenarios mas probables relacionados a complejidad

Porque cuando estamos haciendo estimación y planeación , normalmente se hace una planeación muy subjetiva y optimista. Todo puede ser factible dentro de una linea tiempo y los equipos pueden aprovechar su experiencia.

Hablar de Factibilidad

A nivel de negocio muchos temas puedes ser posible y tu como PO tu responsabilidad principal para poder cumplir el valor de negocio es escuchar y entender a tu equipo tecnico , se recomienda provocar conversaciones relacionadas a factibilidad ¿Que tanto de lo que tenemos en nuestro Backlog es posible ? y ¿como lo podemos hacer una realidad ?

Sesgos de estimación

Un sesgo muy común es hacer estimaciones muy optimistas

Otro sesgo cuando consideramos el desarrollo y no consideramos la pruebas por lo que pasa que existen desarrollos muy sencillos pero para realizar las pruebas es muy complejo y viceversa.

Otro sesgo del multiproyecto , consideramos y estimamos como si estuvieramos haciendo un proyecto a la vez . Estimamos sin que tuvieramos otras cosas que realizar.

Cuando se tiene tanto el COMO como el QUE quiere decir que tu equipo esta entiendo el desarrollo del proyecto.

Esta clase me pareció bastante floja… hay mas técnicas de estimación colaborativa y usar ejemplos seria más conveniente.

Un reto en las estimaciones, además de no tener presentes a las personas que construirán las cosas, es también tener equipos demasiado numerosos, la comunicación se complica. Este es un recurso muy interesante señalando el tema del tamaño de los equipos: https://internet80.com/blog/el-tamano-del-equipo-scrum/

Muy importante que un product owner sepa que las estimaciones en las estimaciones se debe tener en cuenta la factibilidad, los sesgos y las cosas que podrían salir mal, además de que no se trabaja un proyecto a la vez

Hola, mi ejercicio:

Para verlo mejor utilizar x1.5

El Poker en Scrum:

Para estimar existen muchisimas tecnicas que podemos usar, sin embargo, en los equipos que participo, suelo sugerir emplear el Planning Poker, pero, en que consiste?

Consiste en una sesion de trabajo, en el marco del Sprint Planning, en donde el equipo de desarrollo realiza una estimacion de “ESFUERZO” ojo NO DE HORAS, a traves de la representacion de la secuencia Fibonacci.

Esta estimacion se realiza mediante el empleo de un mazo de cartas con que se juega poker, (en fomato digital hay un monton de herramientas, al finalizar dejo el liink) las cuales se le suma una carta que indique cafe y otra carta que indique interrogacion.

Ahora bien, en la primera vuelta, se toma la Historia de Usuario se lee, y en una primera votacion, los involucrados, ponderan la HU con un numero de la carta, los numeros que se suelen usar son 1,2,3,5,8,13,20,40,100.

Siendo 1 el muy facil y 100 realmente dificil, en esta primera vuelta, se consulta al numero mas bajo y al numero mas alto el porque de su votacion, luego se realiza una segunda votacion y de ahi sale el numero estimado de esfuerzo de la Historia de Usuario.

Para el Primer Sprint se emplea o se rcomienda arrancar con 30 puntos de esfuerzo, esto va a depender del tamaño de la celula y la madurez del equipo, sin embargo, se puede tomar numero como base, para posteriores sprints poder calibrar y aumentar o disminuir la velocidad del team.