Y yo buscando de todos lados cuanto debería tener en tiempo cada punto... Con esta explicación entiendo que el enfoque es justamente desligar el tiempo y enfocar en el trabajo into el desarrollo como parámetro de productividad. Gracias por aclararme la duda!
Excelente Video, y excelente consideración con respecto a las estimaciones y el valor que se agrega al proyecto con los 'Story Points'; estimar en horas es incluso una tropicalización del manifiesto que impide explotar al máximo la metodología e impide determinar el valor que cada Sprint ha sumado al avance del proyecto.
¡Excelentes vídeos! Gracias por explicar porque se utiliza Fibonacci, eso no lo tenía claro. También el uso de una historia pivote, eso me pareció bastante interesante y útil para que todos los miembros del equipo puedan definir puntos.
De acuerdo con el uso de Story Points. El uso de una historia base me parece un elemento importantísimo para lograr entendimientos comunes entre el equipo.
Hola @kott, consulta... queremos mejorar cómo estamos estimando los SP. Actualmente, definimos cuántos puntos significa el trabajo de 1 día, por ejemplo 10 SP por día, y calculamos cuántos días tiene el sprint (10 días hábiles) entonces cada desarrollador puede tomar 100 SP por sprint, pero entiendo que esto no es correcto. Deberíamos determinar los SP que terminamos por Sprint como equipo y esos serían SP a alcanzar en el próximo sprint, pero ¿Cómo distribuir los SP por persona bajo este escenario? otra duda, ¿En la estimación se debe considerar el QA y tiempo de publicación tambien?
Hola Anahi, los story points no se relacionan al tiempo (como bien comentas). Los factores son complejidad, riesgo, dependencias, desconocidos, repetitividad, esfuerzo. Siendo por ejemplo 13 la funcionalidad mas "grande" (en cuanto a esos factores) que un solo dev/Qa puede entregar en un sprint. Si son 5 devs/qas podrias iniciar un sprint pretendiendo 65 puntos (13x5). No es relevante distribuir los puntos por persona, el equipo (todo) logra o no logra los objetivos del sprint. Responidendo a tu última pregunta, Si. La estimación incluye el esfuerzo/complejidad/dependencias/etc que se requiere desde que es una Idea hasta que se termina (cumple la DOD), eso incluye todas las fases de desarrollo/pruebas
buen video amigo, pero me queda una duda y es que si tengo un proyecto con una fecha inicial y una fecha de termino, con puntos de historia como puedo estimar el tiempo dedicado a cada sprint para coincidir con la fecha de termino del proyecto?, es decir como se cuanto tiempo demoro en cada sprint.
Hola Rober! Al principio se hace mediante un estimado muy rudo, y conforme avanzan los sprints tendrás la velocidad promedio del equipo, una vez que se tenga este dato podrás ajustar el estimado inicial. En agilidad se trata de ser sincero y transparente, en waterfall cuando das una fecha final de un proyecto lo más probable es que solo se trata de adivinar, acá vas a hacer algo similar con la diferencia de que en los primeros sprints una vez que hayas aprendido la capacidad de producción del equipo, vas a ajustar y a dar una fecha más real. Si la fecha final no es negociable, entonces al 2ndo o 3er sprint sabrás junto al equipo como limitar el scope para ver que alcanzan a terminar para la fecha especifica, dando prioridad a lo de más valor.
Las historias de usuario épicas se dividen ? y si se dividen por ejemplo en 3 historias ¿qué ID tendrían, siendo que los id no se deben repetir con el resto ya enumerado ?
Yo me confundo a la hora de estimar porque un desarrollador puede decir que le toma 1 punto hacer la funcionalidad, pero al QA le puede tomar más tiempo probar esa funcionalidad ya sea por talacha o por otra cosa. No sé si allí se suman los puntos o se hace un promedio. Se debe estimar tanto el desarrollo como las pruebas, y el diseño de la vista (en caso de que este lo requiera)?
Hola Michelle! Es una pregunta muy común. La respuesta es que las pruebas son parte de la historia. Yo te recomiendo considerar todo lo necesario para tener lista la funcionalidad para ir a producción dentro de la historia. (Incluido Desarrollo front, back y pruebas).
@@kott Hola!! gracias por tu comentario, buen punto lo que comentas, pero entonces la estimación la defines primero con desarrollo y luego QA te define el tiempo que tarddará en la prueba y sumas los puntos de desarrollo y QA? Gralmente QA la hace el equipo de BA, entonces , ¿Incluyes a QA en los daily? Gracias por tus comentarios
@@veronicaespinosaposeros2516 Es correcto, estimas los puntos totales (dev+qa) de la historia. Pareciera que tienen QAs/BAs fuera del equipo scrum? regularmente dentro del equipo scrum tienes al Product Owner, al Scrum Master y al equipo de desarrollo (Este equipo de desarrollo incluye todos los roles que necesitas para producir la historia de principio a fin. Por ejemplo 4 developers, 2 QAs y un UX). Si esto no es posible, entonces si invitaría a la persona que la haga de QA no solo al daily sino también al resto de los eventos scrum, incluso a los groomings
@@kott gracias por tu tiempo en responder. Si, en el equipo hay BA'S y QA, pero como ellos no desarrollan les doy seguimiento por separado, es decir, el daily por separado y la estimación de puntos sólo con los desarrolladores, no sé si este bien, son mis primeros pininos
Los BAs la hacen de product owners? Yo trataría de considerar a los QAs parte del equipo scrum. Al final son parte del proceso de la generación de valor, y sus tiempos también afectan y se debería considerar al estimar la capacidad cada sprint. Los BAs te sirve tenerlos en todas las reuniones scrum para que resuelvan las dudas del equipo. (Asumiendo que ellos la hagan de product owners ósea que tomen requerimientos de los stakeholders y escriban las historias y manejen el backlog)
Alguien me puede ayudar con esta duda? por favorrr ... Cómo podemos estimar tareas de research cuando hay mucha incertidumbre sobre cuantos story points puede llegar a tomar? Por ejemplo: una tarea de research que podría parecer simple pero que luego termine siendo algo mucho más complejo. Mil gracias!
Excelente video, pero me surgió una duda ¿si los desarrolladores no entienden un elemento del product backlog a quien deben recurrir? al SM (que es el que elimina impedimentos) o al PO (que es el que hace el Product backlog)
Pasale a tu scrum master esta presentación para que tu equipo comience a usar story points esta misma semana! Descarga gratis la presentación utilizada en este link: scrumexpress.com/guia-para-estimar-en-story-points-puntos-de-historia/
Todos explican lo mismo, pero no nos enseñan como calcular o escoger los puntos requerido para una tarea. Claro, eso lo elige el equipo, pero como sabemos que son los puntos correctos, cuando los puntos no significan horas? Significa esfuerzo, ok. Como yo calculo o defino el esfuerzo? Por ejemplo... Si quiero construir una pared de concreto, que normalmente me toma 1 dia, que como puedo definir 1 dia de trabajo en puntos? seran 2 puntos o seran 55 o 89? Como selecciono el correcto?
Que pena, pero como desarrollador senior, actualmente activo, esto se me hace una total y absoluta chorrada. el concepto es totalmente ambiguo y subjetivo.
Hola, hay estudios en equipos que demuestran que la planeación de capacidad es más acertada con esta técnica. Pero el valor mayor se da al platicar sobre el requerimiento, no tanto en dar el valor exacto a la estimación. Saludos gracias por comentar
Muy bueno Héctor, y soy Licenciada y si entendi...😁
uf, man eres todo un master , muchísimas gracias 😮
Y yo buscando de todos lados cuanto debería tener en tiempo cada punto... Con esta explicación entiendo que el enfoque es justamente desligar el tiempo y enfocar en el trabajo into el desarrollo como parámetro de productividad. Gracias por aclararme la duda!
Excelente informacion explicada en un tiempo corto. Informacion concisa y al grano. Saludos!
A la orden
Gran comunicador, cool
Sencilla explicación, los tips son de mucha ayuda 😁
Muchas gracias Paola!
Excelente video, muy bien explicado para entender del tema
Muchas gracias por tu comentario! Te gustaría que hablaramos de algún otro tema? un abrazo
Muy enriquecedor!
¡Gracias Durman!
excelente contenido
Gracias!
Gracias muy buen video. No conocia ese metodo de story points, Me ha resultado muy util para un trabajo que estoy haciendo
Excelente!
Nice! Me gusto mucho la manera en como lo explicas, que cool que hagas este tipo de contenidos.
Animate, tu también podrías hacer algo similar
Me encantaría hacer algo
Muy buenos videos!! gracias por compartir esa info :)
Gracias a ti por tu comentario, algún video que te gustaría ver estimado?
Excelente Video, y excelente consideración con respecto a las estimaciones y el valor que se agrega al proyecto con los 'Story Points'; estimar en horas es incluso una tropicalización del manifiesto que impide explotar al máximo la metodología e impide determinar el valor que cada Sprint ha sumado al avance del proyecto.
Gracias Erick por tu comentario! Saludos!
excelente video mi estimado y muy buena definición de las STORY POINTS
Muchas gracias por tu comentario! Te gustaría que hablaramos de algún otro tema? un abrazo
Excelente. Gracias!
Gracias a ti!
esta genial!!
Muchas gracias!
GRACIIIIIIASSSSSS
¡Excelentes vídeos! Gracias por explicar porque se utiliza Fibonacci, eso no lo tenía claro.
También el uso de una historia pivote, eso me pareció bastante interesante y útil para que todos los miembros del equipo puedan definir puntos.
Gracias a ti Zaithel por el comentario! ¿Tienes algún tema en especial que te gustaría que tratáramos? Saludos!
@@kott sí por favor.
La parte de métricas, no entiendo del todo los burndown charts.
Se lo agradecería muchísimo. 🙏
Excelentes videos amigo. Sigue así
Muchas gracias! Algún tema que te gustaría estimado Leonardo?
De acuerdo con el uso de Story Points. El uso de una historia base me parece un elemento importantísimo para lograr entendimientos comunes entre el equipo.
Muchas gracias!
Interesante video Héctor, contenido muy claro acerca de los Story Points. Tomaré en cuenta tus consejos y los aplicaré en mis futuros proyectos 🙌👍💯💯💯💯
Excelente muchas gracias por comentar Junior!
Muchas gracias por compartir tu experiencia, una duda , ¿Cómo puedo saber cuando estaría completando una tarea de "x" puntos de historia un Developer?
Hola MrNesoft. Las historias estan completas cuando cumplen su "Definiton of Done", saludos
Hola @kott, consulta... queremos mejorar cómo estamos estimando los SP. Actualmente, definimos cuántos puntos significa el trabajo de 1 día, por ejemplo 10 SP por día, y calculamos cuántos días tiene el sprint (10 días hábiles) entonces cada desarrollador puede tomar 100 SP por sprint, pero entiendo que esto no es correcto. Deberíamos determinar los SP que terminamos por Sprint como equipo y esos serían SP a alcanzar en el próximo sprint, pero ¿Cómo distribuir los SP por persona bajo este escenario? otra duda, ¿En la estimación se debe considerar el QA y tiempo de publicación tambien?
Hola Anahi, los story points no se relacionan al tiempo (como bien comentas). Los factores son complejidad, riesgo, dependencias, desconocidos, repetitividad, esfuerzo. Siendo por ejemplo 13 la funcionalidad mas "grande" (en cuanto a esos factores) que un solo dev/Qa puede entregar en un sprint. Si son 5 devs/qas podrias iniciar un sprint pretendiendo 65 puntos (13x5). No es relevante distribuir los puntos por persona, el equipo (todo) logra o no logra los objetivos del sprint. Responidendo a tu última pregunta, Si. La estimación incluye el esfuerzo/complejidad/dependencias/etc que se requiere desde que es una Idea hasta que se termina (cumple la DOD), eso incluye todas las fases de desarrollo/pruebas
@@kott muchas gracias por tu respuesta! 🙌🙌
buen video amigo, pero me queda una duda y es que si tengo un proyecto con una fecha inicial y una fecha de termino, con puntos de historia como puedo estimar el tiempo dedicado a cada sprint para coincidir con la fecha de termino del proyecto?, es decir como se cuanto tiempo demoro en cada sprint.
Hola Rober! Al principio se hace mediante un estimado muy rudo, y conforme avanzan los sprints tendrás la velocidad promedio del equipo, una vez que se tenga este dato podrás ajustar el estimado inicial. En agilidad se trata de ser sincero y transparente, en waterfall cuando das una fecha final de un proyecto lo más probable es que solo se trata de adivinar, acá vas a hacer algo similar con la diferencia de que en los primeros sprints una vez que hayas aprendido la capacidad de producción del equipo, vas a ajustar y a dar una fecha más real. Si la fecha final no es negociable, entonces al 2ndo o 3er sprint sabrás junto al equipo como limitar el scope para ver que alcanzan a terminar para la fecha especifica, dando prioridad a lo de más valor.
@@kott Hola, gracias por responder, me podrias explicar a que te refieres con el "estimado rudo"?, que tecnicas podria utilizar para ello.
Nooooo que enredo
Las historias de usuario épicas se dividen ? y si se dividen por ejemplo en 3 historias ¿qué ID tendrían, siendo que los id no se deben repetir con el resto ya enumerado ?
Yo me confundo a la hora de estimar porque un desarrollador puede decir que le toma 1 punto hacer la funcionalidad, pero al QA le puede tomar más tiempo probar esa funcionalidad ya sea por talacha o por otra cosa. No sé si allí se suman los puntos o se hace un promedio. Se debe estimar tanto el desarrollo como las pruebas, y el diseño de la vista (en caso de que este lo requiera)?
Hola Michelle! Es una pregunta muy común. La respuesta es que las pruebas son parte de la historia. Yo te recomiendo considerar todo lo necesario para tener lista la funcionalidad para ir a producción dentro de la historia. (Incluido Desarrollo front, back y pruebas).
@@kott Hola!! gracias por tu comentario, buen punto lo que comentas, pero entonces la estimación la defines primero con desarrollo y luego QA te define el tiempo que tarddará en la prueba y sumas los puntos de desarrollo y QA? Gralmente QA la hace el equipo de BA, entonces , ¿Incluyes a QA en los daily? Gracias por tus comentarios
@@veronicaespinosaposeros2516 Es correcto, estimas los puntos totales (dev+qa) de la historia. Pareciera que tienen QAs/BAs fuera del equipo scrum? regularmente dentro del equipo scrum tienes al Product Owner, al Scrum Master y al equipo de desarrollo (Este equipo de desarrollo incluye todos los roles que necesitas para producir la historia de principio a fin. Por ejemplo 4 developers, 2 QAs y un UX). Si esto no es posible, entonces si invitaría a la persona que la haga de QA no solo al daily sino también al resto de los eventos scrum, incluso a los groomings
@@kott gracias por tu tiempo en responder. Si, en el equipo hay BA'S y QA, pero como ellos no desarrollan les doy seguimiento por separado, es decir, el daily por separado y la estimación de puntos sólo con los desarrolladores, no sé si este bien, son mis primeros pininos
Los BAs la hacen de product owners? Yo trataría de considerar a los QAs parte del equipo scrum. Al final son parte del proceso de la generación de valor, y sus tiempos también afectan y se debería considerar al estimar la capacidad cada sprint. Los BAs te sirve tenerlos en todas las reuniones scrum para que resuelvan las dudas del equipo. (Asumiendo que ellos la hagan de product owners ósea que tomen requerimientos de los stakeholders y escriban las historias y manejen el backlog)
Alguien me puede ayudar con esta duda? por favorrr ... Cómo podemos estimar tareas de research cuando hay mucha incertidumbre sobre cuantos story points puede llegar a tomar? Por ejemplo: una tarea de research que podría parecer simple pero que luego termine siendo algo mucho más complejo.
Mil gracias!
Hola Nahuel, responderé tu pregunta en vivo este Sabado a las 5 pm! Saludos! th-cam.com/video/zCO2qCve8go/w-d-xo.html
@@kott sos un grande Héctor, muchas gracias!! 🥳🥳
Excelente video, pero me surgió una duda ¿si los desarrolladores no entienden un elemento del product backlog a quien deben recurrir? al SM (que es el que elimina impedimentos) o al PO (que es el que hace el Product backlog)
Al Product Owner estimado
Pasale a tu scrum master esta presentación para que tu equipo comience a usar story points esta misma semana! Descarga gratis la presentación utilizada en este link: scrumexpress.com/guia-para-estimar-en-story-points-puntos-de-historia/
puedes poner un ejemplo real?
Ejemplos de aplicación por favor, mucha teoría y poca práctica.
Todos explican lo mismo, pero no nos enseñan como calcular o escoger los puntos requerido para una tarea. Claro, eso lo elige el equipo, pero como sabemos que son los puntos correctos, cuando los puntos no significan horas? Significa esfuerzo, ok. Como yo calculo o defino el esfuerzo? Por ejemplo... Si quiero construir una pared de concreto, que normalmente me toma 1 dia, que como puedo definir 1 dia de trabajo en puntos? seran 2 puntos o seran 55 o 89? Como selecciono el correcto?
desde el momento que menciono que es un forma de medida relativa,. ahi se fue todo a la chinga.. no tiene sentido buscarle logica a un desproposito.
Que pena, pero como desarrollador senior, actualmente activo, esto se me hace una total y absoluta chorrada. el concepto es totalmente ambiguo y subjetivo.
Hola, hay estudios en equipos que demuestran que la planeación de capacidad es más acertada con esta técnica. Pero el valor mayor se da al platicar sobre el requerimiento, no tanto en dar el valor exacto a la estimación. Saludos gracias por comentar
en qué rango están los story points?