Having a potentially shippable product every sprint lies in a heart of Agile, but in many organisations – especially the ones that don’t work in SaaS model – a product is not released to the market every sprint. Sometimes frequent delivery is not possible (i.e. in case some additional tasks like a translation of a documentation, legal approval, etc. have to be done at the end of the release) or it’s not even desired. What happens in such cases is that delivery to the market is organised in some more or less formal releases that are shipped every couple of months (internal releases can be still more frequent, though). Working with releases doesn’t require almost any extra efforts, but still, it usually involves some additional activities like release planning and requires for tracking progress on a release level.
Tracking and adapting to changes on a release level becomes particularly critical if release goals are directly or indirectly bound to some marketing or sales activities that require some up-front planning and synchronisation. Fortunately, tracking release progress is not a rocket-science and most software tool that are available on the market support this functionality. JIRA, the tool that I’m familiar with, provides you with 2 simple reports that you can use at easy.
Version Report shows your progress towards completion of a release (estimated work). It uses average velocity and estimated amount of work remaining to predict a forecasted release completion date (a date when all the estimated issues in the release are estimated to be completed). In addition, Version Report can be also used to monitor how a scope of the release has been changing since the start of the release which can be a useful tool for checking if release planning was valuable (great input for adaptation and team’s retrospectives).
Release Burndown report shows how you’re burning story points of all the estimated stories that were planned for the release. It uses average velocity and estimated amount of work remaining to present a predicted number of sprints that are required to complete the release. Release Burndown report presents information on per sprint basis and therefore it can be used to track how much work was added, completed and left remaining in/after each sprint.