Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

DZone's Guide to

# 2 Metrics to Predicting Agile Delivery Dates

· Agile Zone ·
Free Resource

Comment (0)

Save
{{ articles[0].views | formatCount}} Views

The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.

Your manager asks you to provide an estimate of when a certain feature can be delivered by your agile team.

Should you use Velocity (Scrum) or Cycle Time (Kanban/Lean)?

## First you must estimate!

Estimates help us to make “decisions, forecast and model the future“. However, estimates were never designed to provide anything concrete.

Relative estimates provide us our best bet at making predictions. This is because relative estimates are generally based on complexityand not actual hours.

Using actual hours in a software project with unknowns will always fail because of one simple fact:

Complexity doesn’t linearly scale!

Basically, this means that your task that was estimated as 10 hours might not take 10 times longer than your 1 hour task. But, your task that is 10 times more complex will scale more predictably once you know how complex your baseline ‘1’ task is.

## Scrum = Velocity

Teams using the Scrum framework use Velocity to help predict when they can deliver work.

A team’s Velocity is how much work that team completed in a specific iteration.

You can use Velocity of multiple iterations (with a grain of salt) as a predictor of what work can be ‘done‘ in future iterations.

Protip: Since your team should become better at estimating as time goes on, take the last 3 iterations for calculating your ‘Velocity averages’.

## Kanban/Lean = Cycle Time

In the Kanban world you don’t work in iterations, you literally ‘pull’ a new task as soon as you finish your current one. So without iterations, Velocity doesn’t really work here.

The same doesn’t apply for the reverse, as Cycle Time can be used in Scrum and Kanban/Lean teams.

Cycle Time is the time it takes from when the task is started to when it’s complete.

Would you like to know that your 3 point task will take ~4 hours to complete with +- 2 hours of accuracy?

By taking the average Cycle Time for tasks originally estimated the same relative estimate:

You can predict how long it will take to complete the next task with the same relative estimate.

The more tasks you do, the more refined your average cycle time becomes (as outliers will eventually become averaged out).

That’s because estimates are distributions.

For example, 3 tasks originally relatively estimated as 2 points each take 2, 1 and 3 hours respectively to complete. You can now use average cycle time to calculate another 2 point task will take approximately 2 hours to complete +- 1 hour. Easy!

## But my predictions never predict!

Remember, for both Velocity and Cycle Time, your ability to accurately predict increases over time as more unknowns become known.

So start developing!

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training

Topics:

Comment (0)

Save
{{ articles[0].views | formatCount}} Views

Opinions expressed by DZone contributors are their own.