No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Estimación de Historias de Usuario en Scrum

12/21
Recursos

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.

Qué es el póker de planeación o planning poker

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:

  • Una de las más usadas es Fibonacci modificada (1, 2, 3, 4, 8, 13, 20, 40, 100, ∞ y ? → representa incertidumbre)
  • 2X (1, 2, 4, 8, 16, 32)

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:

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

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 146

Preguntas 45

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

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:

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

jajajajaj me gusto mucho la parte del juego , fue demasiado didactico y aprendi mucho mas asi de grafico el ejemplo en la practica .

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/

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.

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.

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

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:

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

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

En base al ejemplo del juego, puede darse el caso que no se llegue a acuerdo , que se aplicará en ese caso???

¿Podría ser una baraja de Uno para que después de la junta nos echemos una ronda? jajaja

No me esperaba la dramatización del final, gracias profe. Siento que fue un plus gigante para entender la dinámica.

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.

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/

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.

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

ahh no mms tambien son actores, excelente ejemplo!!!😄😄

Tambien existe esta página web que hace lo mismo

https://scrumpoker.online/

El “Poker Planning” revela muy bien que tan acorde esta el equipo en si, es una herramienta para potenciar la relación interna

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:

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

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

En el resumen, la escala de Fibonacci muestra que se utiliza el 4 para calificar, sin embargo en la lección se utiliza el 5
En la empresa en la que trabajo, la definición de "terminado" se da cuando se cumple con: * Las pruebas de certificación sean funcionales o no funcionales han finalizado y se tienen las evidencias cargadas en confluence. * Se deben haber realizado las pruebas de aceptación con los usuario (pueden ser usuarios adicionales) y/o Product Owner para luego poder solicitárselas formalmente vía correo. * Se deben tener las aprobaciones de los Usuarios y/o Product Owners a las pruebas relacionadas con la historia correspondiente. * En caso existan consideraciones como bugs en next version o escenarios abortados, también debe haber una conformidad de ello con el sustento respectivo. * El código queda congelado en la rama de tipo release en bitbucket. * Se debe tener el conforme de las pruebas de código estático y buenas prácticas. * En caso aplique: Se deben tener los sign off de escaneos de seguridad si está asociado a pases que lo ameriten. Con ello podemos decir que la Historia de Usuario ha sido "terminada" y se actualiza su estado en Jira.

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

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.

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

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.

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

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

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.

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.

Me ha pasado que en equipos, nos ponemos de acuerdo para lanzar las HU lo más alto posible jajjaja que tiempos, igual sacabamos todo el trabajo pero era un equipo muy unido.
Buenas noches, cordial saludo. Por qué los comentarios son tan antiguos? tienen 4 o 5 años.
El objetivo de la valoración de la historia de usuario, es poder minimizar el tiempo en discusiones, cuando en esta escala de hay diferencias importantes de un punto a otro, es más sencillo identificar valoración, en lugar de usar números continuos 1,2,3…..n por ejemplo si en la historia de usuario un miembro del equipo indica que su valor es 8, otro puede indicar que es 9, la diferencia es muy poca, mientras que si se utiliza una escala como fibonacci hay gran diferencia entre 8 y el próximo que es 13.  ¿Por qué es necesario estimar? para obtener la velocidad en la que el equipo desarrollará la historia de usuario. La capacidad historias a completar, es decir, la cantidad se decide en base a la experiencia del equipo de desarrollo y a los sprints anteriores.
Que gran clase, me gusto mucho el ejemplo final.
Estimar por casos de prueba no es lo más recomendable en Scrum. La estimación debería basarse en la historia de usuario, considerando la complejidad, el trabajo, los conocimientos necesarios y la incertidumbre, como se explicó en la clase. Los casos de prueba son importantes para validar los requisitos, pero no reflejan directamente el esfuerzo del equipo ni la carga de trabajo. Es mejor utilizar técnicas como el planning poker para obtener un consenso sobre los puntos de estimación basados en la experiencia del equipo.
Super!
Todos los cursos deberían tener ejemplos de esta índole ... mejora en un x1000 la calida del curso que tengan una clase muy enfocada a la práctica .. Felicidades!!
A la hora de **estimar se hace desde un punto de vista personal o de equipo?**. Por ejemplo si yo voy a ejecutar una tarea es posible que me tome mayor esfuerzo que a otra persona con mayor experiencia. Sin embargo, la tarea no está asignada a alguien al comienzo del Sprint
Muy claro el ejemplo para entender la metodología.
Muy buena clase. Interesantísimo!
Para facilitar la dinamica de Scrum Poker se debe tener claro las definiciones y criterios de aceptación de cada historia de usuario así como también atender a todas las dudas que el equipo de desarrollo tenga de las mismas.
Ejemplo adecuado del juego Planning poker **(Fibonacci modificada** )en la estimación de HU
Este tema es muy importante como para que solo diga el video esta es la aplicacion, entonces imaginense que asi se hace. Deberian mostrar un ejemplo desde el aplicativo de ejemplo. Mucha teoria poco de practicidad que es realmente la base del curso
Pero, pues quedé en la duda, de cuando en tiempo se va a traducir. Qué le digo al dueño del proyecto, cuánto nos vamos a demorar haciendo un trabajo? no puedo decirle "ah nos vamos a demorar 5 puntos" . me ayudan a entender. por favor.

cual es la guia oficial de scrum ? o cual es libro maestro donde se describe todo scrum ?

Me gusta mucho que después de cada teoría da ejemplos y, por ende, la recreación al final fue de gran ayuda para entender. Pienso que lo mejor para todo esto es ponerlo en práctica, pero por el momento he entendido un poco mejor la teoría.

El ejemplo me pareció genial. Excelente clase.

Buen ejercicio del juego.

Excelente video!! Gracias

Excelente clase, me encantó el ejemplo actuado, deberían aplicar más esto en el resto de sus programas

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.

me encantó el ejemplo actuado

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

  1. Complejidad de la historia
  2. Cantidad de trabajo
  3. Conocimientos necesarios
  4. Incertidumbre
Muy buena clase con el ejemplo incluído, excelente porque de esta manera queda super claro lo explicado en el módulo de historias de usuario.

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.

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:

  • 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