Quite a few customers are jumping on the ‘Agile’ bandwagon these days, choosing an Agile methodology for specific projects, or for repetitive releases of their product. A challenge they are facing is how to manage and report Agile projects when the processes and templates provided by their PMO have been developed for Waterfall projects. And of course, that content is what their stakeholders are used to receiving and discussing.
In Waterfall projects there often are Status Reports which list the tasks in the current work packages and their status. The tasks come from an agreed, project-wide Work Breakdown Structure.
In an Agile Scrum, there is no previously broken down, far-reaching Work Breakdown Structure. The team works from a ‘Product Backlog’, or prioritized list of functionality, which they have agreed with the product owner. They then commit to deliver a certain portion of functionality during a 30-day Sprint. Since the team organizes itself on how to deliver this functionality, and checkpoints daily on their progress and problems, the content of the work is very fluid. They cannot commit in advance to finishing this or that task in this or that timeframe. All they can commit is to deliver finished, working functions by the end of the 30 days. At the end of the Sprint, a “Sprint Review” takes place. So how could one issue weekly status reports, when Scrum offers no Work Breakdown Structure? Just the daily checkpoints and the review of the Scrum at the end of the 30 days?
I am sure there are a variety of creative workarounds Project Managers (ie, Scrum Masters) are using. One of the more successful approaches I have seen entails using the ‘Product Backlog’ as the basis for a status report. The Scrum Master can list the requirements or functionality in the Product Backlog as if they were work packages. Then, they discuss how close to completion these various functionality items are. Sometimes there will be a requirement in the Product Backlog which is not easy to visualize as a work item, such as “User Friendly Interface”. In this case, verbs can be added to give the stakeholders an idea of what the project team is doing, such as “Test Interface with 4 different types of users”. This ‘hybrid reporting’ will then allow the Scrum Master to perform another very important responsibility: protect their project team from distractions and interruptions during the Sprint.