Predicting Scope, Schedule, and Cost

Posted on Jul 16, 2014 | 0 comments

Predicting Scope, Schedule, and Cost

Every project has three key variables…

The three key variables that project managers must manage are typically scope, schedule, and cost. Businesses tend to create project plans that assign constant values for these variables at the project outset, therefore creating the illusion that projects have fixed scope, schedule, and cost. So before we continue, allow me to dispel a myth so we can start down the road to improvement.

Fixed scope, schedule, and cost is an insidious falsehood that undermines the entire project management institution and community.

Whether or not you openly admit it…

This is a true statement; and I must assume you understand and have seen the truth in your experiences on real projects. We propagate this lie despite the deleterious consequences. However, I believe that there are important sociocultural reasons why we do this, so don’t beat yourself up if you still live the lie. What is more important is the acknowledgement that in the real world scope, schedule, and cost are not fixed, and we must become excellent at predicting these things for business planning and management purposes, no matter what process we use.

Agile projects have a unique set of challenges in predicting scope, schedule, and cost that differ from traditional projects.

This is because Agile projects are managed differently…

Different in key ways that impact scope, schedule, and cost. Below are some excerpts of the relevant principles of the Agile manifesto.

Scope: “Welcome changing requirements, even late in development…”
Schedule: “Deliver working software frequently, from a couple of weeks to a couple of months…”

With constantly changing requirements…

We need a way to measure and predict the final scope of a project that not only allows, but welcomes change. Furthermore, we must deliver a working product on a shorter timescale than the 12+ months that is sometimes typical in the IT industry. Lastly, if our customers and executive sponsors are accustomed to infrequent product revisions, then it is quite likely that despite any incremental releases, we will still need to predict and communicate the future delivery dates of major product features that are in development for several months (or even years) at a time.

Okay, enough build up, how do we predict successfully?

I will share with you some tried and tested techniques that I have been applying very successfully at my clients for some time now. However, I must warn you in advance, these are advanced techniques that will take some time and patience to understand and apply, so be prepared to run experiments and learn from your mistakes.

Create a predictive model.

I have found that the best way to model Agile software product development is by first assigning a relative point scale to user stories, which we refer to as “Story Points.” Numerically speaking, using a fibonacci scale seems to yield the best predictions, so we will use that scale. It’s important that this step is done correctly, and that the story points are relative to other user stories, not a point of reference, like “1 point is equal to 1 day of development.” Instead, a 1-point story must be roughly equivalent in effort to any other 1-point story, and a third less effort than a 3-point story.

On Agile projects it is wasteful to break down long-term projects into fully defined user story backlogs because we expect detailed requirements to change, so we must also assign relative sizes to larger work items (I will use the term “feature”) that we haven’t broken into user stories yet. We can use the same fibonacci scale, but to avoid confusion, I recommend changing it to (10, 20, 30, 50, 80, 130) and giving it a different name, like “Feature Points.” Feature points should be relative to other features, so a 10-point feature is roughly equivalent in effort to any other 10-point feature, one third less than a 30-point feature, and has no implied relationship to story points, they are a different unit of measure.

Here is a visual to help you see how this model might look at the start of a large project.

Measure real progress.

Now that you have a model for the relationships between the various pieces of work, you need to measure actual progress in order to have a basis for making predictions. Since most Agile teams work in Sprints (or Iterations), we can measure the amount of work completed at the end of each sprint and update our model with actual progress.


Use Historical Data to Make Predictions.

We now have a lot of really useful information from our models that will allow us to make initial predictions. In the above diagram, the team completed “Dresser” and “Bedding” in Sprint 1. If our team is working in two week sprints and we have a measured velocity of 3 story points per sprint, then we can predict that “Carpeting” will be done in one more sprint (or 2 weeks calendar time).

Regularly Update the Model.

In the next sprint, the team completes the work on the Master Bedroom. Our predictive model suggested that only “Carpeting” would be complete in this time, but with so little historical information to make a prediction, it is very common that initial predictions will be less accurate. We will make them more accurate over time by updating our model with the new information, so let’s see what that looks like.


As you can now see, our team completed 3 points in the first sprint, and 5 points in the second sprint, for an average of 4 points per sprint.  Furthermore, we have completed all the work for the “Master Bedroom,” which took us 2 sprints. We now have additional information that allows us to make additional predictions about feature completion dates, because we have completed work on an entire feature, in this case, the “Master Bedroom.” We can now predict that the “Master Bathroom” will be completed in 1 more sprint (2 weeks from now), and that the “Family Room” will be completed in 2.5 sprints after that (7 weeks from now). These predictions are based on the relative sizes that we assigned to this work earlier. Our model also predicts that we will break up the “Master Bathroom” into 4 story points of work, and “Family Room” into 12 story points of work.

After each sprint, we must continue to update the model with real world data because that will make the future predictions more accurate over time. Initial predictions are going to be less accurate than predictions that have a significant amount of real world data behind them. In the long run, variations of team velocity and other environmental variations will begin to average out to a steady state and provide very good predictions. However, there are certain events that will disrupt or invalidate your model.

Issues and Challenges

This post is just an introduction to the process of using predictive models to forecast scope, schedule, and cost, and there are obviously many other factors to consider when using them. Not all product development teams remain constantly allocated. In many environments, individuals or even whole teams can be added or removed at any time, which can dramatically impact the productivity of the project (negatively, of course). Also, it is common during a project to discover new work or change the existing work that we laid out. In both of these cases you should continue to update the models accordingly and the new information will make your predictions even more accurate, but it may require you to track many more variables than I provided in this example here. Some additional variables might include predicted rate of turnover, predicted scope increases or decreases, velocity trends, etc.

In Conclusion

Predictive modeling can be a powerful tool for accurate forecasting and business planning, when applied correctly, and especially on Agile projects. However, these simple examples are designed to illustrate the concept without getting bogged down in hundreds of real world variables that need to be taken into account when using these on enterprise projects. I tend to create unique models for each of my clients that are tailored to their specific organizational constraints and allow them to make better business decisions. If you do try to apply these techniques in your environment, tell us about it in the comments below!

Leave a Reply

Your email address will not be published. Required fields are marked *