Estimating when my project will be done

Question

Suppose my project has 150 story points of work remaining to be done. Over the last 10 iterations the team has achieved the following velocities of 16, 12, 13, 5, 14, 7, 6, 12, 16, and 14. Assume two-week iterations and a team of four developers. When would you estimate that the project might be done?

Answer 1

Just because you have 150 story points in your backlog now does not mean that work captures the work necessary from your stakeholders' perspectives. Every iteration, you should be evaluating what has been done and what remains, adjusting what remains. You may add work, remove work, or determine that there's no work left to do that's the cost of another iteration and end the effort.

You can use a burndown chart at the Product Backlog level to estimate when the Product Backlog will be finished. By using Yesterday's Weather (often the rolling average of the last three completed iterations), you can draw the burndown line and forecast when it will reach 0. After every iteration, you can recalculate the burndown line and revise your forecast.

In your examples, if your velocities are in order and 12, 16, and 14 are your most recent iterations, your average velocity would be 14. So your burndown trend would indicate that your current backlog would be completed after 11 iterations. This is a very high-level forecast with a lot of error - changes to the backlog, a change in capacity for one or more iterations, any process improvements or changes carried out by the team, and even continuing to learn about the problem space will influence the completion. You can continue to revise this after every iteration to refine the forecast, but the same errors will apply until the work is actually done.

Answer 2

Project Scheduling isn't a science, but an art.

So it's not enough to provide you with a simple equation - which I'm sure you could also do using a calculator - you also have to "understand" your project.

E.g.: In your example case, one would need to know why iterations 4, 6 and 7 had low velocities.

Was it because new team members were added and their training took long? Was it during a holiday period where a lot of people were absent?

So, is your team now up to speed, or are you planning on hiring & training more people? Are there more holiday periods coming up? Maybe winter is approaching and you have to count on 20% and more absentees due to winter-woes. (Let's ignore the pandemic, to keep things "simple".)

Or maybe, with experience you got better at sizing the story points.

Or maybe this was expected due to the complexity of the tasks - or the other stories were known in advance to be the easy ones to implement.

Since you're almost finished, maybe the integration stories are trivial, or maybe they are long and intricate.

The final stages surely include rigorous testing which may or may not take extended amounts of time, based on how well the testing has gone until now.

So, while the mathematical answer would that you have about 4 weeks left, there's no way to tell by just looking at numbers.

Answer 3

In Scrum, a project is done when the client tells you that the product you delivered is good enough or when they don't want the product anymore. That can be when all the tasks currently on the backlog have been completed, but it can also be earlier or later.

If your organisation wants to hear a predicted end-date, you can calculate that based on the amount of work left on the backlog and the average velocity of the team over the last sprints.

If I take all 10 last iterations, or the last 5, I calculate an average velocity of about 11 points. With 150 points of known work, that would need 13 iterations to be completed. But if the customer comes with a change in scope, those numbers are no longer relevant.

Answer 4

TL;DR

To perform agile release planning, or to calculate the estimated number of Sprints needed to complete a set of items from the Product Backlog, requires you to calculate your team's velocity as a per-iteration value or range. That value/range is then used to determine how many complete iterations (rounded up) are likely to be needed.

Calculate a Velocity

Setting aside the use of rolling estimation windows or controlling for variances, the calculation you're looking for to determine average velocity is pretty straightforward.

pts_completed_each_sprint =
  [16, 12, 13, 5, 14, 7, 6, 12, 16, 14]

total_sprints =
  pts_completed_each_sprint.count #=> 10

average_velocity =
  pts_completed_each_sprint.sum / total_sprints.to_f #=> 11.5

You might also consider:

• Using a sliding window of n Sprints (rather than all Sprints) to calculate your current velocity.
• Calculating velocity as a statistical range rather than as a single value.
• Calculating your geometric mean rather than your average velocity (in this case, 10.70 rather than 11.5).
• The benefits of rounding velocity or remaining Sprints, to prevent communicating artificial precision about estimates.

Calculate Sprints for Current Backlog

Given that you have a Product Backlog with an estimated 150 points of effort remaining, the underlying question is how many Sprints would it take to drain the current Product Backlog. That calculation is really just taking your average or mean velocity, and then dividing your remaining Product Backlog by that number to estimate the number of Sprints required to complete all outstanding Product Backlog Items. For example:

average_velocity    = 11.5
pts_left_in_backlog = 150
estimated_sprints   =
  (pts_left_in_backlog.to_f / average_velocity).ceil #=> 14

This approach says that you're likely to need 14 Sprints to complete the remaining work currently defined in the Product Backlog. Note that this is only an estimate based on:

1. the validity of the level-of-effort estimates for remaining Product Backlog Items, and
2. your team's average velocity.

This approach makes no guarantees about upper or lower bounds, nor does it remove the need to continuously re-plan and re-estimate each Sprint. In fact, any approach that attempts to guarantee 100% of planned scope within a fixed number of iterations (especially this close to the mouth of the Cone of Uncertainty) is not only non-agile, it's also simply likely to be wrong.

Treat this estimate as a planning value, and then constantly review and refine it as you get closer to your target release date. The empirical control process is essential to Scrum, so leverage that!

See Also

My related answer regarding agile release planning may also help you develop the calculations and estimates you need to continuously evaluate your remaining project burndown.

Answer 5

Things to bear in mind when you are asked when something will be "complete":

• The items at the bottom of the backlog are generally the least important, so knowing when they will be done is much less important than knowing when earlier items will be done.
• A healthy backlog grows - it doesn't just shrink.
• Being done is not in itself a desirable state to be in because it suggests there is no more opportunity for improvement, no more value that can be added to the product.

Answer 6

Work out the average from your reliable sprints, try to remove outliers.

Divide the 150/avg velocity

Consider the uncertainty, ie does the team get disrupted, resources moved in or out.

Based on the uncertainty adjust your estimate to add contingency between 0-25%

Consideration:

If you have historical data for the same team use this to see how many points the projects was, how many sprints did is actually take....

If you have 100 points for historical projects, and your team velocity is 20 it should take you 5 sprints if you notice that over multiple sprints you are taking 15% longer compared to your estimate either adjust your velocity or depending on politics etc you may just want to add a contingency to upward reporting.

Hope this is of some help. someone above has mentioned that meditation is an art and he is right as you gain experience you will adapt your processes as necessary.

This is all based on experience but every situation is unique, find something that makes sense and adapt.

Answer 7

A good rule of thumb is to drop the highest and lowest numbers and average the remaining. In your case you'd drop the 5 and one of the 16s and get a smoothed average velocity of 11.75, meaning you'll complete 150 more story points in about 13 more sprints.

While the average is useful, I'd highly recommend communicating projections to your product owner in a graph instead.

First, draw 3 lines from the origin point showing projections of your team's progress, one with your team always moving at its slowest (5 velocity), one with the average, and one with the team always moving at its fastest speed (16).

Then, draw a line from (x=0, y=current backlog commitment) showing the change in the commitment over time. Since POs tend to want to add things and devs tend to find new wrinkles in the project, this line generally trends upward.

Now you've got some lines that (hopefully) intersect which demonstrate the earliest possible, likely, and latest possible completion times for the release.