# Simulating a Project by Resampling Velocity

This content is syndicated from Mike Cohn's Blog - Succeeding With Agile® by Mike Cohn. To view the original post in full, click here.

I normally write about a new technique only after I’ve used it for a couple of years and have found it successful in a couple of different contexts. In this post I want to share something just such a technique. It’s a statistical technique called “resampling” that I’ve become quite fond of for making predictions about future velocity. Resampling is based on the idea that things we’ll observe in the future will be similar to the things we’ve observed in the past. In the examples we’ll look at we’re saying that the velocities a team will see in the future will be similar to ones that occurred in the past. Resampling works by imagining we’ve put all old sample velocities into a bag. If we have past velocities of 18, 17, 18, 19, 22, and 20 imagine each of those written on separate slips of paper and dropped into a bag. Note that we’ll have two slips of paper with “18″ because our team here had that velocity twice. To predict future velocity we reach into the bag and pull out one piece of paper. What’s written on it is our prediction of velocity in the first sprint. To predict the team’s velocity in the second sprint, we reach into the bag and pull out another slip of paper. But, before we do that, it’s important that we put the first slip of paper back into the bag. This is called “resampling with replacement.” We want to replace because for any given sprint the team is equally likely to get any of their past velocities. Suppose we’re trying to predict how much work a given team can complete in a coming ten-sprint period. We would resample (with replacement) ten times. Each time we’d note the number we pulled from the bag. After we pull the tenth slip, we would sum the ten values we pulled and that is one possible result for this team over the coming ten-sprint period. It’s quite possible we could get lucky and pull the highest-valued slip (22) each of ten times. Or we could pull the worst-case slip, 17, each of the ten times. But these are unlikely. If we could in some way in the real world run the project hundreds or thousands of times, we would occasionally see the team repeat their highest (or lowest) velocity every sprint but it wouldn’t happen very often. Since we can’t run the project hundreds or thousands of times in the real world, we want to simulate doing so on a computer. We can then learn a great deal from the results. For example, suppose we are ready to start a project that will have ten sprints. It would be helpful to know things like:
• what is the average amount of work completed over those ten sprints?
• what percentage of the time does the team finish more than say 200 points of work?