Si no tienen las cartas físicas del poker plannig, también existe una Apps para utilizar.
Scrum Poker Cards (Agile) en PlayStore
Introducción a las metodologías ágiles y Scrum
¿Qué son las metodologías ágiles?
12 principios ágiles
Qué es Scrum
Cuáles son los componentes de Scrum
Comprender los roles en Scrum
El equipo de Scrum y sus roles
Conforma tu equipo de Scrum
Qué hace el Product Owner o Dueño del Producto
El rol del Scrum Master
Equipo de desarrollo en Scrum
Preparar los artefactos a utilizar en Scrum
Qué es el Backlog, las Épicas y las Historias de Usuario
¿Cómo crear Historias de Usuario?
Cómo estimar Historias de Usuario
¿Cómo empezar? Prioridades y Backlog del Sprint
Cómo medir el avance de un proyecto Scrum
Entender y realizar las ceremonias
Qué es el Sprint en un proyecto Scrum
Qué es el Sprint Planning
Daily stand-up. Seguimiento de un proyecto Scrum
Cómo refinar Historias de Usuario
Sprint Review y Retrospectiva del Sprint
Crecer usando Scrum
Escalabilidad de equipos en Scrum
Qué son las comunidades de práctica
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Para estimar Historias de Usuario en un proyecto Scrum se deben tener en cuenta 4 elementos:
Complejidad de la historia. Junto con el equipo se debe definir qué tan difícil es implementar la historia.
Cantidad de trabajo requerido. Representa el esfuerzo que debe invertir el equipo para llevar a cabo la historia.
Conocimientos necesarios. Habilidades técnicas, de diseño y de negocio, entre otras, para completar la historia.
Incertidumbre. Acciones que se requieren para ejecutar la Historia de Usuario, aunque no se tenga claro el tiempo o esfuerzo real.
El proceso de estimación de las Historias de Usuario se hace a través de puntos. Estos puntos no están relacionadas con una escala de medición, no representan horas o días de trabajo, sino un estimado empírico con base en la experiencia del equipo.
El planning poker es una herramienta que sirve para que el equipo de un proyecto Scrum participe en la estimación de las Historias de Usuario.
Existen cartas físicas de planning poker pero, en caso de no tenerlas, también se puede hacer uso de aplicaciones como Scrum Poker Cards, disponible en PlayStore.
Los puntos para hacer la estimación se pueden establecer tomando como referencia diferentes escalas:
La idea de usar estas escalas en lugar de números consecutivos es minimizar el tiempo que se puede perder en discusiones triviales o que no permitan dar continuidad al proyecto.
Al final del proceso de estimación, se obtendrá el valor total de puntos de todas las Historias de Usuario y eso va a reflejar:
Durante el primer sprint es posible identificar la velocidad del equipo y con base en los resultados, será más fácil estimar los próximos sprints.
Contribución creada con los aportes de: María Alejandra Correa Rojas, Cristian Palacios Beltran y Alex Camacho
Aportes 126
Preguntas 39
Si no tienen las cartas físicas del poker plannig, también existe una Apps para utilizar.
Scrum Poker Cards (Agile) en PlayStore
Felicidades al equipo Platzi ya que el ejemplo en este video abarca todo lo teórico en estimar el tiempo de historias de usuario, sería de mucha ayuda para nosotros los estudiantes ver más de esté método de ejemplos y pienso que daría mucho más valor a cada uno de los cursos. Tal como lo han hecho con esta clase.
Para poder estimar historias de usuario tenemos que tener en cuenta:
El estimado lo vamos a tomar como puntos, los puntos no son horas de trabajo, no commits, etc es un estimado empírico en base a la experiencia del proyecto.
Poker de planeación, esta herramienta nos va a servir para estimar las historias de usuarios. Podemos usar diferentes escalas, ejemplo:
La idea de no usar números consecutivos es para reducir las discusiones
Al final del sprint vamos a tener el valor total de puntos y eso nos va a dar el valor de velocidad del equipo.
La velocidad es el total de puntos completados por el equipo durante las historias de usuario.
La capacidad es el total de historias de usuario que se pueden completar en un sprint futuro.
jajajajaj me gusto mucho la parte del juego , fue demasiado didactico y aprendi mucho mas asi de grafico el ejemplo en la practica .
Les recomiendo la siguiente pagina donde podrán interactuar con el equipo virtualmente, muy intuitiva y muy util para equipos remotos
https://planningpokeronline.com/
Los puntos de una HU son un número que representa:
Complejidad de la HU.
Cantidad de trabajo requerido.
Conocimientos necesarios.
Incertidumbre.
Los puntos no están relacionados con ninguna escala de medición (no son horas, líneas de código, cantidad de commits), son un estimado empírico en base a la experiencia del equipo.
Planning Poker
Es una técnica en la que cada miembro del equipo tendrá unas cartas en las cuales cada miembro del equipo y da un número que cree que tiene de esfuerzo hacer la HU.
**Escala: **se utiliza Fibonacci modificado (1, 2, 3, 5, 8, 13, 20, 40. infinito, y ?)
**Velocidad del equipo: **total de puntos de las HU completadas por el equipo durante un sprint.
Capacidad: Total de HU que se pueden completar en un sprint futuro.
Les comparto este artículo que me permitió escribir mejores hostorias de usuario 😃
https://www.stormotion.io/blog/how-to-write-a-good-user-story-with-examples-templates/
No me queda claro como homologar tiempos con valores subgetivos…
Para mi 5 puede ser una semana, para alguien puede representar 5 horas, para alguien 5 puede representar 5 semanas…
No es más ágil si usamos una escala ya homologada y entendida por todos?
saludos
Para estimar la historia debemos tener en cuenta 4 elementos:
Complejidad de la historia: Junto con el equipo debemos definir que tal dificíl es implementar esta historia.
Cantidad de trabajo requerido: El esfuerzo del equipo para llevar acabo la historia.
Conocimientos necesarios: Habilidades técnicas, de diseño, de negocio, etc. para llevar a cabo la finalidad de la historia.
Incertidumbre: Acciones que debemos realizar para llevar acabo la historia de usuario, pero no conocemos su tiempo y esfuerzo real.
El estimado de las historias de usuario lo vamos a conocer como PUNTOS, estos puntos no están relacionadas con ninguna escala de medición (son un estimado empirico con base a la experiencia del equipo)
Lo usamos para estimar las historias de usuario, aquí cada miembro del equipo va tener cartas en dónde van a poder dar un estimado (de 0 a 10) en dónde van a opinar según su experiencia cuánto va a tomar hacer esta historia (tiempo y esfuerzo). Esto no da el valor en PUNTOS que cada historia va a tener.
Al finalizar nuestro ejercicio vamos a tener el valor de la velocidad y la capacidad del equipo.
Scrum Poker Cards (Agile) en PlayStore.
waaaaoo es la primera clase que veo con una interpretación de un caso real de trabajo, bastante entretenida y clara la forma como muestran la aplicación del poker planning.
ESTIMAR HISTORIAS DE USUARIO.
Se requiere saber:
En base al ejemplo del juego, puede darse el caso que no se llegue a acuerdo , que se aplicará en ese caso???
En mis experiencias pasadas lo venía trabajando de la siguiente manera en mis equipos de trabajo:
Sumatoria de la estimación de:
- Subtareas
- Trabajo administrativo (del código, las personas, documentos, gestión, etc.)
- Documentación
- Investigación o aprendizaje
- Fase de análisis
- Fase de desarrollo
- Fase de pruebas
- Fase de correcciones
- Soporte
- Imprevistos o emergencias
- Reuniones y comunicación
- Revisión de código
- Sumarle un 20% del total, en caso de
Estimar historias de Usuario
Puntos de una historia son un número que representa varias cosas:
Los valores de los puntos no tienen conexión con ninguna unidad de medida
específica. Los puntos son un estimado empírico en base a la experiencia.
Se usa poker de planeación: Es una herramienta que sirve para que todo el equipo
participe en la estimación de las historias.
Por acá podemos simular un sesión como la de la clase, en caso que no tengamos cartas fisicas, o por si sucediera una pandemia y tuvieramos que votar desde casa!😎🐰💚
https://scrum-poker.org/
Los puntos no son una unidad especifica, días de trabajo o commits, sino que es un estimado empírico en base a la experiencia del equipo.
Hacer este tipo de dinámicas es bastante importante ya que puedes ver que tan unido y dispuesto está el equipo para el trabajo en conjunto.
.
Si un equipo encuentra desafiante una actividad colaborativa como planificar el póquer, ¿qué probabilidades hay de que se enfrenten a las demandas colaborativas del próximo sprint?
Los puntos de una historia son un número que representa varias cosas:
ahh no mms tambien son actores, excelente ejemplo!!!😄😄
Tambien existe esta página web que hace lo mismo
El “Poker Planning” revela muy bien que tan acorde esta el equipo en si, es una herramienta para potenciar la relación interna
No me esperaba la dramatización del final, gracias profe. Siento que fue un plus gigante para entender la dinámica.
En qué evento se realiza la planeación del sprint y la discusión de las horas?
ESTIMAR HISTORIAS DE USUARIO
Los puntos de una historia son un número que representa varias cosas:
Los valores de los puntos no tienen conexion con niguna unidad de medida especifica.
Ejemplo
Esta es una herramienta que sirve para que todo el equipo participe en la estimación de las historias.
Puedes utilizar distintas escalas:
Fibonacci modificado (1,2,3,5,8,13,20,40,100, infinito y ?)
2n (1,2,4,8,16,32)
Velocidad:
Es el total de puntos de las historias de usuario completados por el equipo durante un sprint
Capacidad
Total de historias de usuario que se pueden completar en un sprint futuro
Los puntos asignados a una historia representan varias cosas como:
Los valores de los puntos NO tienen conexión con ninguna unidad de medida específica.
¿Cómo se definen los puntos de una historia? Existen cartas físicas de Poker Planning, en caso de no tenerlas, también existen aplicaciones que podemos utilizar como lo puede ser el Scrum Poker Cards que está en la PlayStore.
El Poker Planning es una herramienta que sirve para que todo el equipo participe en la estimación de las historias. Los puntos están definidos en dos escalas que son:
Dentro de la estimación de las historias de usuario tenemos otros dos conceptos importantes.
¿Podría ser una baraja de Uno para que después de la junta nos echemos una ronda? jajaja
Hola buenas a todos(as);
Existe varios sitios con un planning poker online gratuito que pueden usar con sus equipos 😉.
Ej:
A mitad de camino creo que les podrá ayudar mucho!
Más allá del contenido per sé del video, quiero destacar el que hayan hecho una “simulación”, pienso que igual es importante ver como aplicar los conceptos y dinámica en la realidad
Se ve genial el poker de planeación, espero jugarlo algún día 😃
Me encantó el ejemplo práctico. A veces el tema no queda claro con solo teoría, y el ejemplo disipa muchas de las dudas (por ejemplo lo del póker de planeación)
Los puntos de una historia representa:
Complejidad de la historia
Cantidad de trabajo requerido
Conocimiento necesarios
Incertidumbre
*Poker de planeación
*no son horas de trabajo es un estudio empírico de la estimación del tiempo por el equipo
Excelente explicación utilizando dramatización!! Más cursos que usen esta técnica!!!
Estimación de historias de usuario con Planning Poker:
Una técnica colaborativa, sencilla, divertida y efectiva de poder estimar historias de usuario es la de Planning Poker. En ella todos los miembros del Equipo de Desarrollo participan activa y colaborativamente para calcular el esfuerzo de cada item del Product Backlog.
Qué es el Planning Poker : Planning Poker es una técnica de estimación puesta en marcha por primera vez por James Grenning en un equipo Ágil utilizando XP en 2002.
Desde luego no tiene relación alguna con el Poker. Se utiliza una baraja de cartas con una distribución de números muy parecida a la secuencia de Fibonacci (0, 1/2, 1, 2, 3, 5, 8, 13, etc). Existen valores muy grandes como 20 o 40, usados para estimar historias de usuarios muy grandes, cuando en la sesión aparezcan estos valores, la historia de usuario debería ser partida en sub-historias más pequeñas.
Se utiliza en Scrum, pero puede ser aplicado en otros contextos. Favorece la participación y comunicación, esto último indispensable en Scrum. Además de que los miembros del equipo aprendan unos de otros, y del producto que están desarrollando.
**
Beneficios**
El principal beneficio es la colaboración y comunicación dentro del equipo de desarrollo, a la hora de estimar tareas (algo bastante tedioso, sobre todo cuando te piden que lo hagas rápido). Tener distintos puntos de vista acerca de algo es mejor que se si hace de manera solitaria.
Poder estimar colaborativamente ayuda a detectar riesgos, que se pueden ir solventando antes de comenzar la historia de usuario.
Estimar de manera realista es difícil según el producto y contexto, por lo que estimar entre varias personas nos acerca al máximo a la realidad, evitando márgenes de error muy grandes que afecten al desarrollo de producto.
Estimar Historias de Usuario
Poker Planning
Herramienta para que el equipo participe en la estimación del tiempo de las historias, se usan escalas como la secuencia de Fibonacci modificada o Potencia de 2 para minimizar el tiempo de discusiones al aplicar números consecutivos.
Se mostró cómo estimar Historias de Usuario (HU). Para el ¿cuándo, en qué momento deberían estimarse las historias de usuario?.. Hay toda una discusión al respecto que de momento se podría resumir en lo siguiente:
Para estimar la historia debemos tener en cuenta 4 elementos:
El estimado de las historias de usuario lo vamos a conocer como PUNTOS, estos puntos no están relacionadas con ninguna escala de medición (son un estimado empirico con base a la experiencia del equipo)
Lo usamos para estimar las historias de usuario, aquí cada miembro del equipo va tener cartas en dónde van a poder dar un estimado (de 0 a 10) en dónde van a opinar según su experiencia cuánto va a tomar hacer esta historia (tiempo y esfuerzo). Esto no da el valor en PUNTOS que cada historia va a tener.
**Al finalizar nuestro ejercicio vamos a tener el valor de la velocidad y la capacidad del equipo **
Para poder planificar los sprints y saber que historias de usuario se podrán abordar durante los mismos, es necesario hacer una estimación. Esta estimación se realiza mediante un sistema de puntuación, donde cada miembro del equipo le asigna una puntaje teniendo en cuenta los siguientes criterios:
Complejidad de la historia: Que tal difícil es implementar la historia.
Cantidad de trabajo requerido: El esfuerzo del equipo para completar la historia.
Conocimientos necesarios: Habilidades técnicas (de diseño, negocio, frameworks, etc). que el equipo posee o debe adquirir para llevar a cabo la historia.
Incertidumbre: Posibles imprevistos o acciones que se deben realizar realizar, pero no se conoce su tiempo y esfuerzo real.
La herramienta más habitual para hacer la estimación es el Planning Poker y consiste en que cada miembro del equipo (teniendo en cuenta los criterios anteriormente mencionados) le asigna un puntaje dentro de una escala determinada. Dependiendo de la variante de Planning Poker usada, la escala puede contener los siguientes valores:
El objetivo de usar una escala con números no consecutivos es para reducir las discusiones al estimar historias medianas o grandes, por ejemplo, si el equipo no se pone de acuerdo si asignarle un 12, 13 o 14, con la escala Fibonacci simplemente se asigna 13.
Es importante aclarar que estos puntos no están relacionadas con ninguna escala de medición, es decir, no equivalen a tiempo de trabajo, líneas de código ni presupuesto, sino que son un estimado empírico con base a la experiencia del equipo.
Un ejemplo de dinámica a seguir para la estimación puede ser:
Al final del proceso de estimación se conocerá el total de puntos de las historias de usuario que se incluirán en el sprint, de ahí se puede obtener
Es mejor usar el fibonacci modificado
Genial ese ejemplo basado en la realidad, ojalá viera mas en platzi cosas de este estilo sobre todo en curso que son de pura teoría.
Me encanto la simulacion del Poker, principalmente porque he tomado los cursos de algunos profesores que estan ahi 😄
WHAT?! jajajaja menudo sitcom (es broma)
Interesante ejercicio el de las cartas para llegar a un acuerdo de la calificación sobre una historia de usuario donde los integrantes de un equipo pueden tener diversos puntos de vista técnicos y tal vez no técnicos. Me gustó mucho esta parte.
Hago una pequeña pausa en mi revisión de este curso para felicitar como muchos otros, por la explicación final. Master!
Buenisimo ejemplo de la ejecución del Poker Planning.
En donde trabajo usamos esta herramienta para la estimación de User Stories, buenisimo!
Excelente aporte sobre el ejemplo del juego Planning poker en la estimación de HU para nosotros.
Ejemplo de Planing Poker en Scrum
Que bonito, como decidieron en equipo jj
Buen día
No conocía esta metodología y me parece una herramienta práctica y ágil a la hora de tomar decisiones y saber cuanto tiempo se puede demorar una actividad.
Gracias
Cómo estimar Historias de Usuario: Se requieren 4 elementos
la metodologia de scrum para desdarrollo de software es bastantge interesante ademas de optimizar el sistemas al momemto de crear
RESUMEN: Para estimar el valor de esfuerzo y tiempo que va a requerir una historia se reune al equipo de desarrollo para estimar con una determinada escala (Fibonacci, 2 ^ n), para que cada desarrollador de una puntuación de la historia en juego y asi poder determinar con todo el equipo el esfuerzo y tiempo que va a ser necesario para completarla.
Este es un link a un pdf para que puedan imprimir las cartas fisicas, espero les sirva :3
https://www.autentia.com/wp-content/uploads/2019/10/PlanningPoker_Descarga.pdf
Lo has clavao !! buen curso !!
si lo he manejado y es muy bueno, para discusiones. es muy bueno
Excelente que vaya acompañado de un dramatizado. Es la primera vez que esta dinámica me ayuda a entender un concepto de ingeniería. Muchas gracias!!!
En el minuto 1 el profe dice que una caja de texto estático es menos trabajo que 100 etiquetas de texto estático. Pero con un for loop, ambas son muy sencillas 😎
Buena dinamica
Me encanto la dinámica del Poker Planning!
Saludos a los profes!
Gracias
Estimar historias de usuario
a. Complejidad: Depende de la complejidad de la tarea fácil o alta.
b. Cantidad: la cantidad de trabajo o procesos.
c. Conocimientos: lo requerido para su desarrollo en conocimientos.
d. Incertidumbre: Condiciones que están fuera de los pronósticos.
Las cartas ayudan a votación y definir lo largo de la historia y se define el valor total y velocidad del equipo.
(2.4.6.8.1.) o (1.2.3.5.7.9.13)
Muy genial la actividad, queda bastante claro
que buena clase, no solo teoría!!
Excelente clase, me encanto!!!
Ese ejemplo final me gusto estuvo chévere
Buen día a todos! También me gustó mucho el ejemplo final 😃
¡Me encanto la simulación al final!
Mis apuntes:
Estimando
Estimado empírico en base a la experiencia de equipo
Los puntos representan varias cosas:
Planning Poker
Escala: 1, 2, 3, 5, 8, 13, 20, 40, 100, 00, y ?
Obtendremos un valor total de puntos: Valor de la velocidad del equipo
Velocidad: Total de puntos de las historias de usuario completados por el equipo durante un sprint (pasado)
Capacidad: Total de historias de usuario que se puede completar en un sprint futuro (futuro)
Estoy aquí por el Curso de Diseño Web con CSS Grid y Flexbox
Curso de Diseño Web con CSS Grid y Flexbox
¿Empezarían con historias grandes o historias pequeñas?
Me gusto muchísimo esta clase, ojalá y más clases sean así, con ejemplos prácticos de la vida real
Excelente ejemplo
Poker Jira Herramienta par aplicabilidad de SCRUM
En un sprint se pueden utilizar las dos escalas? o solamente se debe escoger una sola?
Realmente me gustó lo interactivo del ejemplo final.
El planning poker es como un brainstorming
Ejemplo de Planning Poker
Me encanta la serie de Fibonacci 😄
cual es la guia oficial de scrum ? o cual es libro maestro donde se describe todo scrum ?
Se podría detallar un poco más la estimación ya que no me queda claro el concepto. Como lo aplico al Sprint, creo que es subjetivo y para cada sprint se va a aprendiendo como se le funciona al equipo.
Se estima en Puntos != horas != días los puntos es un estimado puesto de forma empírica.
Complejidad
Cantidad de trabajo
Conocimientos necesarios
Incertidumbre
Poker de planeación
Se puede utilizar un fibonacci modificado o un numero en 2 en base n
Velocidad [Es el total de putos de las historias de usuario completados por el equipo durante un sprint]
Capacidad [Total de historias de usuario que se pueden completar en un sprint futuro]
Ejemplo de planning poker
Otro elemento útil es tener un Pivote, se hace seleccionando una historia de baja o alta complejidad (en algunos casos se seleccionan dos pivotes), se puntea con alguno de los valores mínimos o máximos y para puntear las otras se comparan con este pivote.
En el proceso de estimación, el Producto Owner aclara las historias de usuario a in de que el Scrum Martes y el Equipo Scrum hagan una estimación sobre el esfuerzo necesario para desarrollar la funcionalidad descrita en cada HU.
Al final es un tema de democracia.
Al principio pensé que la mayoría decidiría la puntuación final, pero que genial que se escuche a los miembros que creen que debería tener otro puntaje asignado.
Creo que es valioso que incluso no se define desde la primera votación sino que le permiten a los miembros argumentar porque dieron un número de puntos y luego volver a votar sobre la argumentación.
Me parece muy interesante. Entiendo que cuando un equipo comienza con esta metodología le va a costar un poco arrancar, pero cuando esté bien “engrasada la maquinaria” funcionará muy bien
Parece lo más divertido de trabajar con Scrum jajaja
muy bueno el ejemplo
Puntos es un estimado empírico en base a la experiencia del equipo
Es Interesante utilizar un juego para hacer la estimación, además se aclaran varios puntos.
ESTIMAR HISTORIAS DE USUARIO
Componentes:
Complejidad de la historia
Cantidad de trabajo requerido
Conocimiento necesarios
Incertidumbre
Los puntos no son horas de trabajo, no son lineas de codigo, no son días de trabajo o cantidad de comits
Son puntos empíricos en base a la experiencia del equipo.
Poker Planning
Escala fibonacci
1 2 3 5 8 13 20 40 100 infinito ?
1 2 4 8 16 32…
Para poder minimizar el tiempo en que podemos perder en discusiones
Velocidad del equipo
Es el total de puntos de las historias de usuario completados por el equipo durante un sprint
Capacidad del equipo
Total de historias de usuario que se pueden completar en un sprint futuro
El ejemplo del juego es muy interesante por que revela que antes de hacer la estimación, el equipo debe tener muy clara la información del la historia a evaluar, antes del ejercicio se deben resolver todas las dudas y luego si se inicia la estimación.
GRACIAS POR EL EJEMPLO FINAL
De las diferencias grandes de este curso con el de Scrum 2018 son este tipo de ejemplos, muy valiosos para garantizar el aprendizaje.
Excelente ejemplo Gerardo Romero!
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
o inicia sesión.