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 **complexity** and **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 the Velocity of multiple iterations (*with a grain of salt*) as a predictor of what work can be ‘done‘ in future iterations (i.e. calculate the average).

*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!