Ayer asistí al décimo Meetup del grupo AgileUY que se realizó en las oficinas de CASE UY HQ. Muy buen ambiente creado por la creciente comunidad ágil de Uruguay.
Backlog Improvement Process, Scrum Guide 2013
La segunda charla, Backlog Improvement Process, dictada por Carolina Graffe y Jorge Fernandez, trató sobre la relativamente nueva actividad llamada “Product Backlog refinement” que aparece explícitamente en la Scrum Guide de Ken Schwaber y Jeff Sutherland de Julio del 2013 y que dice así:
“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Higher ordered Product Backlog items (PBIs) are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.”
Al final de la charla y del ejercicio propuesto se dio una buena discusión que intento resumir en este post como aspectos positivos de esta actividad:
- Es una oportunidad de comunicación e interacción, ya que el equipo Scrum se reúne, quizás con algunos stackeholders, para hablar del proyecto
- Los PBIs para el próximo sprint se aclaran y detallan alcanzando su estado de “listos”
- El Product Owner (PO) tiene tiempo para reflexionar sobre el conjunto de PBIs listos y de pensar en estrategias para tratar en la próxima Sprint Planning
- Si bien esta ceremonia consume algo de tiempo, se gana en claridad de las PBIs y las plannings pueden ser mas efectivas, al evitar discusiones o intentar buscar información sobre algún PBI que esté poco claro durante la misma
- De igual manera se puede eliminar el posible retrabajo durante el sprint por PBIs mal o poco definidas
- Todo el equipo Scrum se prepara mejor para el próximo sprint, compartiendo una visión y objetivos y eso es positivo ya que baja los riegos y la incertidumbre
Están todos invitados a comentar abajo si algo se me escapó y podemos completar estas ideas.
PD 2023: ¡mucho ha cambiado desde el 2013!
