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é es una metodología ágil?
Aprendiendo los principios ágiles
Introducción a Scrum
Conociendo los componentes de Scrum
Comprender los roles en Scrum
El equipo Scrum
Forma tu equipo de Scrum
Presentando al Dueño del Producto o Product Owner
El rol del Scrum Master
La base del equipo de desarrollo
Preparar los artefactos a utilizar en Scrum
Las épicas y el backlog del producto
¿Qué nos cuentan las Historias de Usuario?
Estimar historias de usuario
¿Por dónde comenzar? Prioridades y backlog del sprint
Midiendo el avance del proyecto
Entender y realizar las ceremonias
¿Cuál es el ritmo del equipo? El sprint
Planeando el sprint
El seguimiento del proyecto: Daily stand-up
Refinando historias
Mostrando y aprendiendo: demos y retrospectivas
Crecer usando Scrum
Escalabilidad de equipos
La importancia de las comunidades de práctica
Aún no tienes acceso a esta clase
Crea una cuenta y continúa viendo este curso
Aportes 108
Preguntas 33
Si no tienen las cartas físicas del poker plannig, también existe una Apps para utilizar.
Scrum Poker Cards (Agile) en PlayStore
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.
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.
jajajajaj me gusto mucho la parte del juego , fue demasiado didactico y aprendi mucho mas asi de grafico el ejemplo en la practica .
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 recomiendo la siguiente pagina donde podrán interactuar con el equipo virtualmente, muy intuitiva y muy util para equipos remotos
https://planningpokeronline.com/
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.
En base al ejemplo del juego, puede darse el caso que no se llegue a acuerdo , que se aplicará en ese caso???
ESTIMAR HISTORIAS DE USUARIO.
Se requiere saber:
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.
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:
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
El “Poker Planning” revela muy bien que tan acorde esta el equipo en si, es una herramienta para potenciar la relación interna
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.
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?
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.
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.
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/
¿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
Tambien existe esta página web que hace lo mismo
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.
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
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.
Lo has clavao !! buen curso !!
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 **
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!!!
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.
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
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:
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!
Yo aconsejaría aquí como miembro del equipo de desarrollo: no tengan miedo a hablar y preguntar todo lo que tengan por dudas en sprint planning. Además, creo que valdría la pena que conocieran de antemano las historias que se van a dar en el planning, para llevar a acabo un tipo de investigación y reducir el nivel de incertidumbre.
Me encanto el poker de planeacion!
Excelente explicación con un equipo así, es divertido trabajar las historias de usuario.
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)
Se ve genial el poker de planeación, espero jugarlo algún día 😃
Que buen ejercicio el del final! Queda en resumen la clase
El play role que presentaron aquí como ejemplo me resulta muy esclarecedor, en especial por las votaciones 👍
Criterios al momento de estimar
Complejidad
Cantidad por ejemplo : crear 100 etiquetas h1 o crear una sola.
Conocimientos
Incertidumbre : depender de algo volátil como por ejemplo el clima
Los puntos no se rigen bajo cierta unidad de medida por ejemplo: cantidad de horas de trabajo, cantidad de commits, etc, sino bajo un conocimiento empírico.
Se puede usar:
Fibonacci modificado: 1,2,3,5,8,13,20,40, infinito (cuando parece que la US va a llevar mucho tiempo y ? (cuando realmente no se sabe cuánto va a llevar)
2ª : 2,4,8,16,32…
Esta decisión de qué puntos lleva tal US se hace en conjunto con el equipo de desarrollo. Por lo general, usando planning poker.
Cuando se terminan los estimativos, se llega a:
Velocidad: Cantidad total de puntos completados en un sprint, la cual mide la cantidad de trabajo.
Capacidad: Cantidad total de puntos en los que, en teoría, el equipo puede completar en el próximo sprint.
Interesante la shisotrias de usuario, pero mi consulta es. Este proceso se realiza con el cliente que solicita el proyecto o con quien seria el usuario final del requerimiento.
Buen ejemplo el de la recreación del juego
Hola gente! Les dejo acá una página para hacerlo online.
Saludos!
Planning Poker in Action
Los puntos de una historia son un número que representa varias cosas:
*- Complejidad de la historia
*- Cantidad de trabajo
*- Conocimientos necesarios
*- Incertidumbre
Los puntos no están relacionados con ninguna unidad de medición.
Poker de Planeación: Es una herramienta que sirve para que el equipo participe en la estimación de historia. Puede utilizar distintas escalas: fibonacci modificado, potencia de 2, etc.
Velocidad del equipo. Es el total de puntos de las historias de usuarios contemplados por el equipo durante el Sprint.
Capacidad. Total de historias de usuario que se pueden completar en un Sprint Futuro.
Esta muy bueno hahaha
Entonces, se debe hacer al momento de crear el Backlog y cuando se aniadan nuevas Stories.
Me queda una duda el item list = Storie?
PUNTOS (El estimado de historias de usuario = Puntos)
Los puntos no están relacionados a ninguna unidad de medida
No son horas de trabajo
No son líneas de código
No son cantidad de commits
No son días de trabajo
Es un estimado empírico en base a la experiencia del Team
Para poder estimar se requiere lo siguiente:
Poker de planeación
Cada miembro del equipo reciben cartas
Deben indicar el tiempo que estiman en culminar la historia
Estimar también el esfuerzo del Team para esa historia
Escalas usadas (Fibonacci modificado)
Velocidad
Total de puntos del Sprint completadas por el Team durante un Sprint
Capacidad
Total de puntos que el Team podría completar, calculado en base a la experiencia
Ejemplo de planning poker
Sistema de puntos para estimar historias de usuario
Capacidad y velocidad del equipo
Overview
¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.