Estimar historias de usuario

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:

• La complejidad de la historia, funcionalidad de la actividad
• Cantidad de trabajo requerido, tamaño de la actividad
• Conocimientos necesarios, aprendizaje para realizar la actividad
• Incertidumbre, factores externos que no controlamos

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:

• 1, 2, 3, 5, 8, 13 … infinito e incertidumbre
• 1, 2, 4, 8, 16, 32 …

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.

Entonces básicamente el primer sprint sirve para medir la velocidad del equipo y en base a este se van a poder estimar mejor los siguientes sprints.

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

Estimar historias de usuario

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)

Planning Poker o Poker de planeación:

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.

• El simbolo de infinito se usa para definir una incertidumbre debido a que el miembro del equipo no conoce cuanto tiempo pueda tomar completar esa historia.

Al finalizar nuestro ejercicio vamos a tener el valor de la velocidad y la capacidad del equipo.

Aplicación para hacer Planning Poker:

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:

• Complejidad de la historia.
• Cantidad de trabajo requerido
• Conocimientos necesarios
• Incertidumbre
  La estimación de historias de usuario se hace mediante puntos, que no están ligados con ninguna unidad de medida especifica. Para establecer estos puntos se puede hacer uso de Póker de planeación y así todos los miembros participen en la estimación.
  Se pueden manejar escalas como Fibonacci modificado, exponencial 2^n. Esto con el fin de quitar la discusión innecesaria y por lo tanto ahorrar la perdida de tiempo.
  Con esta estimación podemos calcular la:
• Velocidad del equipo, es en teoría la cantidad de puntos que un equipo puede realizar en un sprint.
• Capacidad que un estimado a futuro de cuantas historias puede completar en sprint futuros.

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:

• Complejidad de la historia
• Cantidad de trabajo requerido
• Conocimientos necesarios
  Incertidumbre

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:

• Complejidad de la historia
• Cantidad de trabajo requerido
• Conocimientos necesarios
• Incertidumbre

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?

Estimar historias de usuario

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.

• Velocidad: Son los puntos que el equipo puede completar durante el sprint y ha completado durante el sprint.
• Capacidad: Total de historias de usuarios que se pueden completar en un sprint futuro.

ESTIMAR HISTORIAS DE USUARIO

Los puntos de una historia son un número que representa varias cosas:

• Complejidad de la historia
• Cantidad de trabajo requerido
• Conocimientos necesarios
• incertidumbre

Los valores de los puntos no tienen conexion con niguna unidad de medida especifica.

Ejemplo

• Poker de planeación

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

Estimar historias de usuario

Los puntos asignados a una historia representan varias cosas como:

• Complejidad de la historia
• Cantidad de trabajo requerido
• Conocimientos necesarios
• Incertidumbre

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:

• Fibonacci modificado (1, 2, 3, 4, 8, 13, 20, 40, 100, ∞ y ?)
• $2^n$ (1, 2, 4, 8, 16, 32)

Dentro de la estimación de las historias de usuario tenemos otros dos conceptos importantes.

1. Velocidad. Es el total de puntos de las historias de usuario completados por el equipo durante un sprint.
2. Capacidad. Total de historias de usuario que se pueden completar en un sprint futuro.

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:

https://planningpokeronline.com/

A mitad de camino creo que les podrá ayudar mucho!

https://youtu.be/502ILHjX9EE

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

https://scrumpoker.online/

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.

Estimación de historias de usuario

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:

• Fibonacci modificada: Valores 1, 2, 3, 5, 8, 13, 20, 40, infinito (demasiado grande o compleja) e incertidumbre (no se sabe cuanto tiempo puede llegar a tomar).
• Potencias de 2: Valores 1, 2, 4, 8, 16, 32, 64, …

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:

1. Leer la historia de usuario
2. Abrir un espacio de preguntas y respuestas para aclarar dudas tanto técnicas como de lo que cuenta la historia.
3. Cada integrante piensa su estimación y se hace una puesta en común
4. Si los valores son variados los integrantes pueden argumentar su estimación
5. Se repite el paso 3, los valores estimados deberían converger.

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

• Velocidad: Puntos que el equipo puede llegar a completar durante el sprint.
• Capacidad: Puntos que en teoría el equipo puede completar.

Estimar Historias de Usuario

• Complejidad de la historia.
• Cantidad de trabajo requerido.
• Conocimientos necesarios.
• Incertidumbre.

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 !!

Estimar historias de usuario 💚

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)

Planning Poker o Poker de planeación: 🚀

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.

• El simbolo de infinito se usa para definir una incertidumbre debido a que el miembro del equipo no conoce cuanto tiempo pueda tomar completar esa historia.

**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.

https://beagilemyfriend.com/estimacion-planning-poker/

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:

• Lo ideal es que fuera en el Backlog Refinement, pero…
• Si sale una HU en ultimo momento, se podría hacer al final del Sprint Planning
• Una vez desarrollada una HU o asignada al Sprint Planning, ya no tiene sentido puntuarla
• A pesar de lo anterior, la estimación/puntuación de las HU no es propio de Scrum, por lo que no es obligatorio realizar esta actividad

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:

• Complejidad
• Cantidad de trabajo
• Conocimientos necesarios
• Incertidumbre

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

• Para estimar las historia de usuario debemos de basarnos en la complejidad, tamaño, conocimientos necesarios, incertidumbre.
• La estimación se da en puntos y no esta relacionado con algún sistema de medición.
• Para realizar la estimación en puntos se realiza el planing poker y se pueden usar la escala de finocacci (1,2,3,5,8,13,20…,∞ ,?) o la potencia de 2(2,4,8,16,32,…).
• El total de puntos de las historias durante un sprint nos dan la velocidad del equipo durante el sprint.
• La capacidad son el total de historias que el equipo puede realizar durante el sprint.

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