Project A: Drafting a Product Backlog – Part A
With Project A we had a Project Backlog at the start. Somehow we forgot how to update it. However, it seems that it is never too late to revisit one and keep the project on track. One of the main reasons, why we are not able to track project and sprint backlogs is because no one understands why should we do so. Our organization is transitioning from a “no-process” development style to SCRUM project management. Hence, writing a backlog and tracking tasks in the sprint backlog is somewhat of an overhead and unchartered territory for most teams. Without a prioritized queue of work yet to be done in the project, we are all going in all the directions possible without knowing what to do and where we are going in the project. We need to start working based on a prioritized list of things rather than ad-hoc requests at the earliest.
It is widely recognized and accepted that project backlog and sprint backlogs are artifacts which the team owns. I also understand that eventually the team has to do this. After all, we will be a successful SCRUM team only when these artifacts are owned/ drafted by the team.
However, I am having a hard time overcoming the instincts to draft one myself and present it to the team. I feel and understand that the team needs to be mentored over a period of time on how to draft the project and sprint backlog. Maybe I can invite them on the discussion on whether the stories for the project and sprint backlog are complete and what does “done” for these items means. Also, get them to understand the motivation for priorities and delivering “value” first. As much as I hate it, I think I will need to draft the project backlog for now. However, lets give it a try and see if the team can draft the sprint backlog for the coming sprint or not.