No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Reg铆strate

Comienza en:

6D
4H
46M
49S

Estimaci贸n colaborativa

5/12
Recursos

Aportes 12

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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 馃槙

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/

think out of the box?

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 鈥淓SFUERZO鈥 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.

excelente contenido