Agregaria que 1 o 2 veces x sprint (dependiendo la duración) se revise el burndown chart para concientizar al equipo de lo que falta por hacer hacia el cierre del sprint
@kott4 жыл бұрын
De acuerdo Irasema! el burndown chart ayuda a que el equipo ajuste de ser necesario el scope o de plano le meta turbo si sienten que no llegan. Saludos!
@lc23364 жыл бұрын
Me parece genial, gracias por compartir tus conocimientos.
@kott4 жыл бұрын
Gracias a ti por tu comentario. ¿Algún tema en el que estés interesada en especial?
@_alejandroalanis4 жыл бұрын
Excelente formato, nuevo lo digo, esta genial concíso, enfocado y práctico.
@kott4 жыл бұрын
Gracias Alejandro! El próximo video traerá un material de apoyo muy completo, espero les agrade
@diegocarrillo55024 жыл бұрын
Totalmente de acuerdo con todo lo que comentas en el video, sobre todo en qué la daily es para el equipo, no para que PO y SM digan estatus!, saludos
@kott4 жыл бұрын
Si pasa en todos lados que el product y SM también dan su status y pues no es para ellos! Saludos Diego!
@Noirstarkel184 жыл бұрын
Justamente miraba un curso de CHEF DevOps, me agradó el ejemplo que aportas. Es fundamental escuchar la perspectiva del equipo ante el requerimiento, otro tema, es hacer un buen uso de las herramientas. Eh visto desde el uso de trello, GitLAB, jira, Azure DevOps hasta utilizar Git Kraken para indicar los avances por ramas, pienso que este tema lo podrías abordar perfectamente.
@kott4 жыл бұрын
Totalmente de acuerdo! Gracias, cuenta con ese tema! Saludos!
@carolinaamaya-baz40854 жыл бұрын
Podrías hacer un vídeo de como manejar todo lo que se va al parking lot, gracias
@kott4 жыл бұрын
Hola Carolina! Te lo puedo comentar por aquí porque es muy sencillo. Solamente se trata de tener post-its durante el daily scrum y anotar en un post-it cada tema que requiera una discusión a profundidad. Al termino del daily los que necesiten quedarse a platicar los temas del "parking lot" (osea los temas pendientes anotados en los post-its) se quedan y arreglan lo pendiente. He trabajado con algunos equipos que incluso designan un area para stand-ups y otra para parking lot items. Espero te sirva! te mando saludos!
@dannyanicamamasgo64824 жыл бұрын
Excelente Video, Que tips puedo aplicar a los daily scrum a traves de meetings, ya que todos nosotros hacemos home office? muchas gracias
@kott4 жыл бұрын
Hola Danny! Haré un video de tips y consejos de scrum en general a distancia/remoto! Muchas gracias por la idea
@jimmygonzalez72854 жыл бұрын
Hola! a qué hora recomienda hacer esta reunión? Si aparece un blocker durande el día, luego del daily scrum, hay que esperar hasta el siguiente día para hacerlo saber? Espero sus comentarios. Gracias!
@kott4 жыл бұрын
Hola Jimmy, mira yo en los equipos con los que he trabajado, regularmente lo tengo antes de medio dia y funciona bien, si hay algún blocker después del stand-up no es necesario esperar al otro día, siempre se puede acudir al scrum master para que intente destrabar de manera inmediata. En cuanto a lo que dice la guía de scrum.. No especifica una hora determinada, sin embargo las preguntas esatn formuladas de manera que da a entender que la idea es tenerlo en la mañana. "Que hice ayer", "Que haré hoy".. Espero que te sirva mi respuesta! Al final lo mejor siempre será lo que le funcione a tu equipo y se adapte mejor a su contexto. Saludos!
@veronicaespinosaposeros25164 жыл бұрын
Hola, llegué a un proyecto con mucho retraso y sin visibilidad para los directores, los dailys los hacía en la mañana frente a un tablero donde los desarrolladores movían sus tareas (pendientes por hacer, en proceso, hecho) con esto yo daba estatus del proyecto y elaboraba el burndown chart. Me parece bueno lo que comentas ,es mejor trabajar por objetivos, pero ¿cómo trabajas con el estatus de avance del proyecto?, ¿Un aproximado y porcentaje?... El daily también lo use con el área de BA, ¿qué opinas? Gracias por compartir tus conocimientos y por tus comentarios. Saludos
@kott4 жыл бұрын
Invita a tus stakeholders y managers a los sprint reviews. Ahí el equipo les presenta avances a los jefes en forma de features funcionales. Y entonces reciben feedback de como van respecto a la visión del producto y pueden discutir cuando viene el siguiente release y que sigue de trabajar para el equipo. Usa los sprint reviews para mostrar avances. Ten un roadmap estimado por Q no por sprint y ve viendo cómo vas respecto a este roadmap. El burndown chart también es buena herramienta para ver cómo van respecto al sprint. Scrum funciona mejor cuando al “proyecto” lo tratas como “producto”. Lee sobre OKRs es la moda ahorita para medir “valor entregado” para el negocio, a ninguna compañía le va importar más el feature que el business value, ayuda a tus managers a cambiar el chip del antiguo reporting.
@veronicaespinosaposeros25164 жыл бұрын
@@kott wowww! Muchas gracias!! Seguiré tus recomendaciones
@robertocamacho88074 жыл бұрын
Todo bien con el mensaje. Solo un poco más de soltura...
@kott4 жыл бұрын
Gracias Roberto por tu comentario! Espero cada video salga más natural que el anterior, saludos!