Despite a moment towards thinking of software as an experiment, running hypothesis based experiments and having a position of humility when developing software, many organisations, stakeholders, teams and project managers still fall into traditional predictive approaches and as a result, they want to know the date of when something will be delivered.

Traditional vs Agile

In traditional project management approaches, the scope is fixed with a lot of planning up front and then resource management is used to try and deliver the scope within the time set.

There is lot’s of evidence this does not work e.g. Brooks law and that planning up front doesn't deliver value, soon enough hence the rise of Agile frameworks and that when working with knowledge work, big upfront planning is very hard to do.

Open

So in Agile framework, the traditional triangle of constraints is turned upside down so that the scope is flexible but the resources and time are fixed which we can see through agile promoting small, stable and dedicated teams which are funded for longer periods.

Empirical Process Control

Scrum and other agile frameworks are built on empirical process control, basically, we look at what has happened in the past to predict the future and one of the ways Scrum uses empirical process control is a teams velocity.

Velocity

Most teams use relative estimation, for more details see: Relative Estimation using story points.

After sprint planning, the product development team have a sprint forecast or commitment which is the number of story points they think that they can deliver during the sprint.

Velocity will naturally fluctuate for various reasons such as holidays, sick leave, tasks more difficult than expected etc.

At the end of the sprint and after the review, items that are not done are returned to the top of the backlog for consideration for the next sprint.

In the diagram below you can see

• Committed Story Points - the number of story points the team thought they could do for the sprint

• Complete Story Points - the actual number of story points the team manage to get delivered.

Open

So how does this work in predicting when something will be delivered?

Predicting the date

In order to predict “when something will be done” we need to know the following

• Average sprint velocity - normally last 3 or 4 sprints

• Estimates from the product backlog

• Scope / Date

Average Velocity

To get the average velocity, most teams look at the last 3 sprints. From the diagram above we can see that the team did

• Sprint 12: 175 SP

• Sprint 13: 50 SP

• Sprint 14: 15

So for the teams average velocity its 175 + 50 +15 / 3 = 80 SP

Product Back Log (PBL)

Let’s presume that the team have already done some story mapping and created all the user stories required for a feature and we want to know when that feature is likely to go into production.

In the example below, we have created all the stories required for the new feature: Search Interface. We can see in the PBL below that there are a lot of stories for the feature with the total of 115 story points required to deliver the feature.

Two Planning Scenarios

There are 2 scenarios for planning

1. Fixed Date - here the only compromise is with scope

2. Fixed Scope - A date is predicted based on the product backlog estimates and teams velocity

Fixed Date

In this scanerio, we know

• The date that something has to go live

• The number of SP Required to deliver the new feature: Search Interface

The stakeholders have decided that the new search interface feature must go live on X date.

So we know that

• The Search Interface feature requires 115 story points in total

• The average velocity of the team is 80 story points in a 2-week sprint

• In order to complete the work, we need at least 2 sprints

Luckily, the date given by stakeholders is after 3 sprints, so the team will probably be able to deliver the feature in time

However, what happens if the date given by stakeholders doesn't allow the team enough time based on the velocity and estimations given.

In the scenario, our estimates and team velocity mean we will not be able to deliver everything in the scope required in time.

We know from the Agile triangle of constraints, that in a fixed date scenario, the only option here is to reduce the scope in order to try and deliver some of the features on time.

It has been proven from various Chaos Reports and studies that actually most features in software are not required or not used so a minimum viable product might be the solution here.

A Product Owner would have to go back to their backlog and work out what to prioritise based on what is not providing enough value and reduce the scope of the feature to deliver it based on the fixed date

Fixed Scope

In this scenario, we know

• The number of SP Required to deliver the new feature: Search Interface

The stakeholders would like to know when this will go live

So we know that

• The Search Interface feature requires 115 story points in total

• The average velocity of the team is 80 story points in a 2-week sprint

• In order to complete the work, we need at least 2 sprints

In this case, the Product Owner can communicate to stakeholders that it's estimated the team can deliver the Search Interface feature at the end of sprint 2.

Some teams will fall into a nasty habit of trying to plan everything up front to try and predict the date successfully, however, this is very difficult and also considered a waste.