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 😕
Prácticas básicas
Historias de usuario
Esquematización de elementos de trabajo
Descomposición
Prototipado como medio de especificación
Prácticas de estimación y priorización
Estimación colaborativa
Talleres de requisitos
Priorización de elementos de trabajo
Prácticas centradas en el usuario
Principios de orientación al usuario
Técnica de Buyer Persona
Técnica de Value Proposition Canvas
Técnica User Journey
Cierre
¿Por dónde empiezo?
You don't have access to this class
Keep learning! Join and start boosting your career
Contributions 17
Questions 3
Esta clase me pareció un poco pobre.
Hay bastantes metodologías para estimar las historias de usuario y no hizo mención de ninguna:
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.
Esta clase me pareció bastante floja… hay mas técnicas de estimación colaborativa y usar ejemplos seria más conveniente.
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
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.
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 ?
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.
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.
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:
Want to see more contributions, questions and answers from the community?