¿How to ESTIMATE in STORY POINTS? - Steps to start estimating in points and be more agile

We'll explain why it is important to estimate in story points, and the steps your team needs to follow using points the sooner possible.
Find the slides or presentation used in this video in the following link:
scrumexpress.com/2020/06/08/s...

[@gloriafigueroa3958]

GRACIIIIIIASSSSSS

[@carceravi]

Excelente informacion explicada en un tiempo corto. Informacion concisa y al grano. Saludos!

[@kott]

A la orden

[@the_wizard_exe]

uf, man eres todo un master , muchísimas gracias 😮

[@gabrielaloamiolivaresmarti5798]

Muy bueno Héctor, y soy Licenciada y si entendi...😁

[@josueaderlycondevargas9609]

excelente video mi estimado y muy buena definición de las STORY POINTS

[@kott]

Muchas gracias por tu comentario! Te gustaría que hablaramos de algún otro tema? un abrazo

[@guipe7712]

Gracias muy buen video. No conocia ese metodo de story points, Me ha resultado muy util para un trabajo que estoy haciendo

[@kott]

Excelente!

[@juniorsuasnabar3261]

Interesante video Héctor, contenido muy claro acerca de los Story Points. Tomaré en cuenta tus consejos y los aplicaré en mis futuros proyectos 🙌👍💯💯💯💯

[@kott]

Excelente muchas gracias por comentar Junior!

[@rck.figueroa]

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.

[@kott]

Gracias Erick por tu comentario! Saludos!

[@williamchacon1823]

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.

[@kott]

Muchas gracias!

[@zaithelcardoza8394]

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

[@kott]

Gracias a ti Zaithel por el comentario! ¿Tienes algún tema en especial que te gustaría que tratáramos? Saludos!

[@zaithelcardoza8394]

@@kott sí por favor. La parte de métricas, no entiendo del todo los burndown charts. Se lo agradecería muchísimo. 🙏

[@jhonnybartolo2858]

Excelente video, muy bien explicado para entender del tema

[@kott]

Muchas gracias por tu comentario! Te gustaría que hablaramos de algún otro tema? un abrazo

[@monicacarena6174]

Excelente. Gracias!

[@kott]

Gracias a ti!

[@eriktorres9431]

Nice! Me gusto mucho la manera en como lo explicas, que cool que hagas este tipo de contenidos.

[@kott]

Animate, tu también podrías hacer algo similar

[@eriktorres9431]

Me encantaría hacer algo

[@guilloquiceno]

Muy buenos videos!! gracias por compartir esa info :)

[@kott]

Gracias a ti por tu comentario, algún video que te gustaría ver estimado?

[@durmanbarrantes1463]

Muy enriquecedor!

[@kott]

¡Gracias Durman!

[@aquel2007]

esta genial!!

[@kott]

Muchas gracias!

[@kott]

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/

[@leonardopaulleoncruz6042]

Excelentes videos amigo. Sigue así

[@kott]

Muchas gracias! Algún tema que te gustaría estimado Leonardo?

[@godofwarpx]

excelente contenido

[@kott]

Gracias!

[@idbluemirror9586]

Gran comunicador, cool

[@paolapena3472]

Sencilla explicación, los tips son de mucha ayuda 😁

[@kott]

Muchas gracias Paola!

[@sanchez3de4]

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 ?

[@user-vl8he1sg2n]

Nooooo que enredo

[@MrNesoft]

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?

[@kott]

Hola MrNesoft. Las historias estan completas cuando cumplen su "Definiton of Done", saludos

[@jssantoniio]

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)

[@kott]

Al Product Owner estimado

[@Deltahc]

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.

[@kott]

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.

[@Deltahc]

@@kott Hola, gracias por responder, me podrias explicar a que te refieres con el "estimado rudo"?, que tecnicas podria utilizar para ello.

[@ricarprieto]

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!

[@kott]

Hola Nahuel, responderé tu pregunta en vivo este Sabado a las 5 pm! Saludos! kzbin.info/www/bejne/sHSyY6R5q8prndE

[@ricarprieto]

@@kott sos un grande Héctor, muchas gracias!! 🥳🥳

[@michitamy]

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)?

[@kott]

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

[@veronicaespinosaposeros2516]

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

[@kott]

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

[@veronicaespinosaposeros2516]

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

[@kott]

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)

[@antoniodelrosario1755]

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?

[@joem7319]

puedes poner un ejemplo real?

[@leogame2762]

Ejemplos de aplicación por favor, mucha teoría y poca práctica.

[@ernestofavio6735]

en qué rango están los story points?