Release Dates and Cost of Delay - Part II

095870902-handwriting-text-forecasting-c.jpeg

In my first article on this topic, I discussed how we can use the Cost of Delay to prioritize our backlog and how we can use the Burndown and Burnup charts in Azure DevOps to predict the release date of a software version.

This article will follow our team’s completion of version 3.0.0 of the product and discuss some points along the way.

The team prioritized the backlog for version 3.0.0, using the Cost of Delay CD3 field to aid us. Based on Product Owner feedback, I made some changes as depicted in the backlog shown below.

Image01.png

In the last article, the team was not able to ensure all the PBIs met the Definition of Ready. That has now been accomplished and I have updated the boards to show all the PBIs for version 3.0.0 in the Ready for Planning column.

image02.png

The team provided estimates for two previously unknown PBIs. The charts reflect this fact, displaying it as a scope increase. It is normal and expected for the scope to change in an agile project, but we still need to understand the consequences of these changes. At this point, no PBIs have been completed.

image03.png

Below we see that a good amount of activity has occurred. This activity is represented from a Burnup and Burndown perspective. Next, I will explain these charts in detail and offer some of my personal thoughts.

image04.png

Both charts show the same data from different perspectives. I prefer the Burndown chart because it more effectively shows the completed PBIs and the scope together.

  • Completed – the percentage of the release that is Done.

  • Average burnup – the velocity.

  • Items not estimated – the number of PBIs not estimated. Of course, we need to have our PBIs estimated. In the first article, you can see an example of two items that were not estimated.

  • Total scope increase – the amount of increase in scope since the project began. I will cover this in greater detail later.

  • Effort remaining – the number of story points remaining for the release.

  • Gold line – the trend of scope change for the release.

  • Gray line – the trend of completed work for the release.

Using this information, we can keep our eye on changing scope, velocity and estimated completion dates.

Chart Configuration

The screenshot below shows the configuration I used for the chart.

image05.png

I used a custom field, Version, for the version number of the product. This is how we identify the PBIs for a given release. I added this to the chart’s filter for version 3.0.0.

I configured the charts to Sum in the Effort field, which I am using for Story Points.

I configured the Time Period as a date range. You can also use sprints here. If you do so, you need to pre-populate the sprints that comprise your “release.” I prefer not to pre-populate sprints, so I used a range of dates instead.

Adding Scope

On 5/28, the product owner decided to add two PBIs to the release. I updated the Version field to reflect the fact that these items will be in release 3.0.0. This added 4 story points of work to the release.

image06.png

You can see the scope increase below.

image07.png

The Total Scope Increase has also changed.

image08.png

Release Completion

The charts below depict the team’s progress and completion of the release. The charts show a completion date of 6/3/2019.

image09.png

The charts below show the team’s completion of the release.

image10.png

Closing Thoughts

These two articles have shown how to use Cost of Delay to prioritize a backlog. In addition, we saw how to track scope change and predict release dates.

Although this example used Azure DevOps, most other agile tools support this type of reporting. Even if your tool does not have these features or you are using a manual process, it is easy to develop these reports in a spreadsheet.