A Scrum Master has been asked to maintain a product schedule. What type of information should be in this schedule? Should this be a prediction of what is to be achieved in each sprint or an overall Project Management schedule to include the activities to operationalize the product? Saving Changes...
It could be a high-level one with just one task or activity representing each sprint and an estimated number of sprints to complete a release.
Anything more than that is 100% fiction if the team is truly taking an adaptive approach as there is unlikely to be much clarity about work items beyond the current and at most the next sprint.
PMO Leader | Speaker & Mentor | Content Leader – PMOGA Latin America
Hub| Catholic University of UruguayMontevideo, Montevideo, Uruguay
un cronograma de producto en Scrum debe ser una herramienta dinámica que combine la planificación detallada de cada sprint con una visión general de las actividades necesarias para el éxito del proyecto. Esto permite al equipo adaptarse a los cambios y asegurar que se cumplan los objetivos del proyecto de manera efectiva. Saving Changes...
Your schedule should include a daily standup's (One or multiple project), Track the workload on every resources, Planned and committed user stories are on schedule from development and testing, Improve the SDLC process if any loopholes, Implement the feedbacks obtained from retro, Track the burndown and project velocity apart from that need to maintain a report on the planned story points vs delivered on each sprints Saving Changes...
I will offer the apparently radical position that the Scrum Master should refuse. The SM works with the Product Owner to ensure a Product Backlog is available and prioritized in rank order. That's the end of the SM's responsibility in that area. Once a velocity is established, anyone can look at the backlog, do the math, and figure out when a story they are interested in might be available. (For example, if the velocity is 6 stories per sprint, and the item is #24 on the list, the earliest possible delivery under current priorities is 4 sprints from now.)
...
1 reply by Kiron Bondale
Dec 04, 2024 3:59 PM
Kiron Bondale
...
This is one of the reasons why I favor Disciplined Agile and other agnostic toolkits over rigid frameworks. DA from the get-go has recognized that different stakeholders might want to see information presented in different ways to them, including schedule data.
I will offer the apparently radical position that the Scrum Master should refuse. The SM works with the Product Owner to ensure a Product Backlog is available and prioritized in rank order. That's the end of the SM's responsibility in that area. Once a velocity is established, anyone can look at the backlog, do the math, and figure out when a story they are interested in might be available. (For example, if the velocity is 6 stories per sprint, and the item is #24 on the list, the earliest possible delivery under current priorities is 4 sprints from now.)
This is one of the reasons why I favor Disciplined Agile and other agnostic toolkits over rigid frameworks. DA from the get-go has recognized that different stakeholders might want to see information presented in different ways to them, including schedule data.