• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

¿Cuándo debemos mover un ticket en Kanban?

Una pregunta común en torno a Kanban es: ¿Qué hago con un ticket que está en la columna testing pero necesita trabajo de desarrollo porque he encontrado un bug?

La respuesta es muy sencilla. En el método Kanban, los tickets están en la columna que mejor refleja el estado dominante en el que se encuentra. En el caso anterior, el ticket se quedaría en la columna de testing hasta que el desarrollo esté resuelto.

Es importante recordar que en el método Kanban organizamos el trabajo y permitimos que las personas se autoorganicen alrededor del mismo. De esa manera, los desarrolladores no trabajan exclusivamente en la columna desarrollo y los testers en la columna testing.

Lo que ocurre es que el equipo, durante el Daily Meeting de Kanban, analiza el tablero que visualiza el trabajo en curso e identifica cuáles son los impedimentos que impiden que el trabajo fluya y deciden cuál va a ser su plan durante 24 horas para hacer avanzar el trabajo.

¿Y cómo se toman estas decisiones? Pues en base a dos criterios:

  1. El primero es el valor de los elementos que pueblan nuestro tablero, que estarán reflejados en una clase de servicio. La clase de servio indica el cost of delay, que actúa como indicador económico del valor del ticket.
  2. El Segundo es el lead time. Trabajando con la asunción de que cuanto más tiempo tardemos en entregar, menos retorno obtenemos, buscamos siempre elementos de alto valor y a la vez reducir el Lead Time.

De esta manera, el sistema Kanban es un espacio de autoorganización que permite la mejora de los procesos de una manera muy eficiente.

Acerca de Jerónimo Palacios Vela

Mi misión es ayudar a mejorar la profesión del desarrollo de software. Soy Professional Scrum Trainer de Scrum.org, Accredited Kanban Trainer de Lean Kanban y facilitador de LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby

Recibe actualizaciones en tu inbox

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad