¿How to ESTIMATE in STORY POINTS? - Steps to start estimating in points and be more agile
HTML-код
- Опубликовано: 6 июн 2020
- 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... 
Наука
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!
GRACIIIIIIASSSSSS
uf, man eres todo un master , muchísimas gracias 😮
Excelente informacion explicada en un tiempo corto. Informacion concisa y al grano. Saludos!
A la orden
Excelente. Gracias!
Gracias a ti!
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!
Muy bueno Héctor, y soy Licenciada y si entendi...😁
Gracias muy buen video. No conocia ese metodo de story points, Me ha resultado muy util para un trabajo que estoy haciendo
Excelente!
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 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
esta genial!!
Muchas gracias!
Excelentes videos amigo. Sigue así
Muchas gracias! Algún tema que te gustaría estimado Leonardo?
Muy enriquecedor!
¡Gracias Durman!
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!
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
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
¡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. 🙏
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!
excelente contenido
Gracias!
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/
Gran comunicador, cool
Sencilla explicación, los tips son de mucha ayuda 😁
Muchas gracias Paola!
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 ?
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
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
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
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! ruclips.net/video/zCO2qCve8go/видео.html
@@kott sos un grande Héctor, muchas gracias!! 🥳🥳
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?
puedes poner un ejemplo real?
Ejemplos de aplicación por favor, mucha teoría y poca práctica.
en qué rango están los story points?