Release Dates and Cost of Delay


The purpose of this article is to explore how we can use Azure DevOps to improve backlog grooming and sprint planning. We will also use the Burndown and Burnup dashboard widgets to predict release dates.

These techniques can be used with other Agile platforms as well. Most popular Agile tools have the capability to implement what I demonstrate in this article.

Backlog Grooming

It can be challenging for teams to maintain a properly groomed backlog. Poorly groomed backlogs are a major impediment to sprint planning.

In my experience, getting backlog stories ready for sprint planning is at the heart of the challenge. Backlog grooming and prioritization is often informal. In this article, I use a formal Definition of Ready and the concept of Cost of Delay to help prioritize my backlog.

Cost of Delay

Cost of Delay is a technique to calculate the value of a feature as compared to its cost. This factor is used to help prioritize a backlog. An excellent article entitled Breaking Down Cost Of Delay: Everything You Need To Know In a Simple Guide explains this well, and I recommend that you read it.

The factor is known as “CD3”, or Cost of Delay Divided by Duration. It is the value of a feature divided by the cost. I use the following fields in my product backlog items (PBIs) in Azure DevOps:

  • Effort – the size of the PBI in story points

  • Business Value – the value of the PBI in story points

  • CD3Business Value / Effort, where Business Value is the value part of the CD3 calculation and Effort is the cost

We will be using CD3 to help prioritize our backlog.

Definition of Ready

Definition of Ready is like the concept of Definition of Done. The team defines the attributes that make a story Ready for sprint planning. Our Definition of Ready is:

  • The team understands the story well enough to develop estimated hour-long tasks in sprint planning.

  • The Effort, Business Value, and CD3 values have been defined.

We will only consider stories that meet this Definition of Ready in Sprint Planning.

Release Dates

In our example, we want to predict when we can release our software product to end users. We know our delivery will take multiple sprints. We also know that only a portion of the backlog will be our minimal viable product (MVP).

I have added a field entitled Version that is used to indicate the version of our software product. We will use this field to track our progress toward completing the PBIs of a given version.

Sports Store Application

I will be using a simplified e-commerce application as an example for this article. This is an application I often use to experiment with Agile and DevOps techniques. The application is shown below.


I will be using a set of user stories entered as PBIs that implement this website in our example.

The screenshot below shows our backlog of PBIs. I configured the column options to include the columns you see. Business Value, Effort, and CD3 are used to define our Cost of Delay values. Version is used to identify the version we wish to track – in this example, 3.0.0.

The Board Column is used to identify our Definition of Ready.

Backlog 1.png

I configured the backlog board as shown below. I added a column entitled Ready for Planning. When our PBIs meet our Definition of Ready, we will drag the cards into that column.

I also split the Committed column into Doing and Done. The PBIs in the Committed/Doing column are currently being worked on in an active sprint. When a story has met all aspects of our Definition of Done except approval from the product owner, it is moved into the Committed/Done column. When the product owner accepts the story, it is moved into the Done column.

Board 1.png

The Burnup and Burndown widgets have been configured to include the PBIs in Version 3.0.0 for the date range from 5/22/2019 to 6/8/2019. Eleven PBIs are associated with this version, but none have been assigned a business value or been estimated.

Next, we will get as many PBIs to meet our Definition of Ready as possible.

widget 1.png

I have moved the PBIs that meet our Definition of Ready into the Ready for Planning column. Two PBIs remain in the New column because they do not meet our Definition of Ready. Please note that I have configured the cards to show the Version, Effort, Business Value, and CD3 values.

board 2.png

The backlog is shown below prioritized by CD3. We can also see the PBIs that meet our Definition of Ready in the Board Column. These items will be considered for sprint 1 when we do our sprint planning.

backlog 2.png

Our widgets now show that we have 19 story points of work. Two items remain unestimated. The first column in the Burndown chart reflects the original scope of work.

widget 2.png

The next article will show the results of our sprint planning and completion of some PBIs. We will also see what happens when we add the scope.