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

2 Metrics to Predicting Agile Delivery Dates

DZone's Guide to

2 Metrics to Predicting Agile Delivery Dates

· Agile Zone
Free Resource

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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)?

code_cracking

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.

Velocity

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.

Average Cycle Time

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!

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}