(The following is an edited excerpt from my upcoming book: “The Product Owner Role Explained”.)
When an initiative starts, there’s always interest in knowing when it will be completed. Certainly the Management team would want to know and the Product Owner himself may need estimates for Roadmap planning or coordinating with other parts of the organization. Under the Scrum methodology estimates for an entire initiative aren’t provided up front so how can the probable completion date be determined?
An easy, quick and low effort technique is to create an Initiative Burndown Chart which tracks the number of remaining backlog items from sprint to sprint. It provides a clear visual showing progress and the sprint in which all work is likely to be completed.
Creating the chart is best done using a spreadsheet although given its simplicity, it could also be done on a whiteboard or poster-board hanging in the Scrum Team’s regular meeting area. Start with a three column table with Sprint #, Sprint Start Date, and Remaining Backlog Item Count. Then create a bar chart that plots the number of remaining items for each sprint. A chart like the following can be created:
Updating the chart is a matter of counting the remaining backlog items after Sprint Planning. Why after this meeting? Because by the time that meeting is over, the Developers would have given feedback on the Product Backlog at a Story Time meeting and during Sprint Planning and any new items would be defined at least by title. The key with using this technique is to update it in a consistent way, either always right after Sprint Planning or at the end of that day.
Notice that the chart has a dotted straight line running from the highest bar and projected downwards until it reaches zero. This trendline represents the likely sprint in which all initiative work will be complete. In the above example, the Scrum Team had worked for six sprints and probably needs three more to be completely done. Assuming they finish all the work in Sprint 9, the predicted completion date would be by Sprint 10 or August 14.
Of course the Product Backlog isn’t static and so the number of backlog items can increase over time. When this occurs, as illustrated in the following, the trendline is redrawn from the new highest bar towards zero. This bump in backlog item count has changed the date when all work is likely to be completed and so the predicted completion date coincides with Sprint 11, or August 28th.
The predictive power of this chart isn’t perfect as it doesn’t take in account the size of the backlog items but since a Product Owner doesn’t want the Scrum Team to spend a couple of sprints only estimating backlog items, that may not even be fully defined yet, it’s a good alternative to guessing.
Besides the obvious benefits of predicting when an initiative will be completed, the chart can also be a great motivator. When a Scrum Team is starting a 40+ backlog item initiative, it may feel like an insurmountable mountain of work lies ahead and so showing progress from sprint to sprint will give them a sense of where they’re at in the whole effort and may even inspire them to get it done quicker.
© 2013 William Patrick Swisher