When will we be finished?

I’m a firm believer that all work should have an agreed end date, but end dates are always a bone of contention and cause endless confusion and wasted arguments and disagreements. These usually hover around the “when will we be finished?” question and, more to the point, no properly defined (empirical) way of working it out.

That in mind I thought I’d lay down the process we use to arrive at our end date. I will also attempt to do this without using the word scrum or agile, not because I don’t like or agree with them, but because those words tend to create predefined thoughts and have a life of their own (unfortunately).

 

So first the basics: In a nutshell we work in iterations, releasing something (hopefully of value) every 2 weeks based on a prioritized backlog. The backlog is constantly updated as stories are added / removed / completed.

Now for the fun. In order to calculate an end date with reasonable empirical accuracy you need the following: remaining effort and an average effort per sprint / day the team is capable of.

Effort Scale

Effort is difficult to define but key to the entire process. Everyone should agree and understand what is meant when we say “X amount of effort”. What you must realize is that it does not matter what unit of measure you use to define your “effort” as long as:

  • it is consistently used across all stories
  • it is understood by everyone
  • something of effort X closely matches another thing of effort X,  for small values of X. 
  • the units should increase roughly exponentially. This is to allow for indication of greater uncertainty with significantly higher numbers. Some people use the Fibonacci sequence (1, 2, 3, 5, 8, 13 …). Also remember to allow for zero effort.

We struggled to settle on our effort scale but eventually had to settle on a time relative scale (for various reasons):

  • Very Easy (1 point) – roughly a day to complete
  • Easy (2 points) – between a day and 2
  • Medium (4 points)  – roughly half a sprint
  • Hard (7 points) – roughly a full sprint
  • Epic (20 points) – unknown or way more than a sprint

and of course 0 points for quickies.

Effort per story

Assigning effort to stories is an exercise the entire team should do but failing that at least the majority of the team. Stories should also be continuously rechecked to see if the effort is still correct, especially stories with high effort assigned to them.

The process we use is as follows:

  1. Discuss the story
  2. Vote on an effort, if there’s dispute, use the highest of the choices, if there’s huge uncertainty, assign the highest effort.
  3. Rinse and repeat

Remember also to compare stories of similar effort. Another way or form of checksumming is to, during planning, assign tasks to the story (as in what you’re going to do to achieve the story) and then assign a rough hour estimate to do the tasks. Sum up the hours for the story and an equivalent effort story should probably have a similar amount of hours, although this is only really useful for well understood stories.

Average Effort Per Iteration

Calculating the effort per iteration (sometimes called the velocity) is a matter of adding all effort units (points in our case) for all completed stories for a sprint. It’s important to only tally up completed stories or the whole process is pointless. Average effort is just the sum of the effort for X number of iterations divided by X. Obviously the more data you have the better. What we also do is remove the highest and lowest values (as anomalies) from the calculation, to account for those strange iterations (over Christmas, Easter etc.)

Remaining Effort

Remaining effort is simply the sum of all effort that has not been completed.

The Formula

Calculating the end date then becomes the following:

By Day: date today + (remaining effort / average velocity / number of work days in iteration) divided by 5 and then multiplied 7 to account for weekends = your end date

By Iteration: current iteration number + (remaining effort / average velocity)  rounded up to whole number = final iteration of work, end of iteration is end date

and that’s it, you’ve predicted a future date based on historical data using a reasonably empirical method. You can improve the accuracy of this estimation by doing the following on a regular basis:

  • Re-evaluate the backlog from an effort point of view, focusing particularly on high effort stories.
  • Recalculate your average velocity at the end of each sprint and factor it in.
  • Factor in holidays and leave into your calculation.

Comments or suggestions welcome

3 Comments

Kevin ShineApril 12th, 2012 at 15:59

I fully agree with the principle of 1st do some size based estimation, and then provide an initial estimate of work that can be done by a certain date. This is excellent for giving the project estimated end date, but then I think the team must do a full task and hour break down before they start the sprint. This provides extra reassurance that you can commit to the sprint. If you find you have too many hours of work then remove a story and adjust the committed to effort. I guess your formula can then be applied and adjusted accordingly.

Enter the cone of uncertainty. Your formula gets more accurate the closer you get to the end of the project. So end dates will probably move around a bit in the beginning of the project (A hard concept for some to grasp). Basically we are saying we can give you a more accurate end date after 3 or 4 sprints.

Committing to the final end date in the beginning is still the problem we are faced with. It will probably change yes?

Rick TonoliApril 13th, 2012 at 15:36

My feelings on end dates is this: moving end dates are bad, they should be set and features stripped off to meet it. That said, in most cases this is not a workable reality. You reach a point where you CAN’T strip features off to meet a date, and then the date must move right? That’s the reality here.

The problem is that if date can move then what’s constraining the project? You can extend it forever until you either fail or by luck you release. So in the end you need a fixed end date.

This is what I think might work: at the initiation of the project attempt to define a decent backlog of features and “predict” an end date on some hypothetical average velocity, but know that it will move (either way). Then, after 3-4 sprints (or whenever you feel comfortable you can predict velocity) you re-estimate the date based on the current backlog and velocity. Of course the problem is what if your backlog is NOT accurate; so during the same 3-4 sprints groom the backlog (continuously) and make sure the product is well defined (from a feature point of view AND a effort point of view) after these sprints. Once that’s done (well defined backlog, stable average velocity) you can then, with some certainty, predict an end date.

In the end though it is just a prediction, the key is you want to add as much empirical evidence as possibly in to eliminate uncertainty but, in reality, you’re still doing a lot of guessing/gut feel and stakeholders need to understand this.

Dave TapsonMay 8th, 2012 at 10:38

A simple solution, as the best ones are.
Depends pretty much entirely on disciplined/consistent use of your chosen unit of effort?

Leave a comment

Your comment