Agile delivery projection, transparency and an agile mindset


I recently had a question about how we track agile delivery in the team I currently work in. Let's all agree up front there is some rigidity to agile delivery and project work that we all do in the digital & technology space. Usually a project goes like so, there is a product vision, we agree the features we want to deliver for a first release (MVP) and then build on it iteratively from there. This creates a sense of scope, we then try to estimate a timeframe for this and from there we kick-off development.

In some of my previous posts I have explained details around Agile Estimation P1 and P2 which is up front estimations to gain an idea of release effort and time. However in this post we go into a bit more detail about real-time projection and transparency of teams.

The example I will use today is building a new front-end customer facing platform. This can take some time and the team have estimated up front potentially how long it might take them. Let's fast-forward to 5 sprints in and the product owner wants to know how much longer it is going to take us in comparison to our up-front estimates. Well there is an answer to that, and it all stems off good scrum practices.

The realtime burn up chart is the perfect answer, as long as the team are following the below routine practices:

  1. Agile Estimation team standard
  2. Backlog Grooming with the team
  3. Version tracking of first release scope
  4. Independent teams that estimate together

If followed in a routine fashion the team should end up with a report that looks something like this:


This report uses real-time velocity to present a view of "How much longer is this going to take?" and how and when should we plan pre go-live activities. 

People then ask me, "but is that Agile? and Isn't this just waterfall? my answer is not really. Waterfall delivery to me is an upfront specification of requirements that has a set scope and set delivery time. In this view it is still up to the team to define scope, requirements and time all based on their delivery methods throughout the process and this report will be able to help the team identify if we pivot scope or change the way we are working we may be able to move the deadline closer or further away.

That my friends to me is a true agile delivery team, one that adapts to change, is transparent to their business, respond to change over following a plan and reflect on how to become more effective and adjust behaviour accordingly, all following an agile mindset.