
However, these are planned dates, and they do not determine the first and last sprints shown on the report. The Start date and Release date configured for the version are shown on the bottom of the report as the Planned start date and Planned end date. Why don't the dates for the first/last sprints on my report match the Start date/Release date configured for my version? The following questions and answers cover the other key functions of the Release Burndown report: Also, the sprint bar will show green/blue sections, like the bars for completed sprints.įor example, in the chart above, if your team had already completed more than 9 story points in the current sprint, then the work completed in Beta 6, Beta 7, and the current sprint (rather than Beta 4) would be used to calculate the velocity. In this case, the current sprint (and the actual work completed) is used as one of the three sprints used to calculate the velocity. The exception is when you have already completed more work in the current sprint than the work that was predicted to be completed. In the example above, the current sprint bar shows grey sections (like the bars for the predicted sprints) to represent this. The current sprint is usually not counted when calculating the team's velocity. Is my current sprint counted when calculating my team's velocity?
#Version one taskboard burndown plus
That is, 1 sprint of 9 story points, plus one final sprint of 1 story point. Predicting the remaining sprints: At a velocity of 9 story points per sprint, it will take 2 more sprints (including the current sprint) to complete the work for the version: 10 story points. This averages out to a velocity of 9 story points per sprint, rounding to nearest story point. Īssessing the outstanding work: In this example, 10 story points remain for the version at the start of the current sprint.Ĭalculating the velocity: 28 story points were completed in the last three sprints (Beta 5, Beta 6 and Beta 7). * not the same as the velocity described in the Velocity Chart. Scope change is not considered when calculating the velocity*, but is included in the total work remaining. Predicted sprints are calculated based on your team's velocity* (amount of work completed in the last three sprints), and the total work remaining in your backlog. Light blue section + dark blue section = total work in the version, that is remaining at the end of the sprint.īars with grey sections = predicted sprints (see below). Light green section + light blue section = total work in the version, that was originally estimated at the start of the sprint. Light blue section = work that is remaining in the version, out of the total work estimated for the version at the start of the sprint.ĭark blue section = work that was added during the sprint, but not originally included (i.e. To find out this information, click the bar to view the details. If a bar is completely light green, you won't be able to tell how much of the work completed was originally estimated or not. Light green section = work completed during the sprint.

You will be able to choose from versions that are in projects configured for your board (via the board's filter) Select the relevant version from the Release Burndown drop-down. Viewing the Release Burndown reportĬlick Projects in the navigation bar and select the relevant projectĬlick Reports then select Release Burndown However, the Release Burndown report is optimized for scrum teams that work in sprints - which makes tracking much easier. If you have used the Version Report before, you will notice some similarities. Predict how many sprints it will take to complete the work for a version, based on past sprints and changes during the sprints. See how work added and removed during the sprint has affected your team's overall progress See how quickly your team is working through the backlog, Here are some of the ways that you could use a Release Burndown report: The report will show data based on the estimation statistic that your board is using. In Jira Software, there is no 'release' entity-a version is equivalent to a release (hence, the term 'version' will be used instead of 'release' in this document). The Release Burndown report shows you how your team is progressing against the work for a release.
