# Cost estimation from agile story points

I am new to project management. I have been through a series of lectures. I am stuck with a problem and have no idea how to proceed with it. I would highly appreciate it if anybody could give me pointers. Below is the mentioned problem.

I need to calculate how much time will it take and cost us to complete a project with the below-mentioned data.

Total story points - 200. 5 people working but they are not 100% available. The initial estimation is 20 points per 2 weeks iteration. total planned iterations 10. Situation after 4 iterations:

Can anybody help me to know how much it will cost and how much time it will take?

Thanks

• You do realize that Story Points are an admission that Software Developers cannot do time estimates, right? Feb 13 at 4:12
• Anyway, it appears that you're averaging roughly 20 story points per iteration, just as you estimated. You've completed 78 story points in the first 4 iterations, very close to the 80 you would have expected. If there are 200 story points, your estimate is 200 / 20 points per iteration, or 10 iterations total. So the time estimate is 20 weeks in total, or 12 weeks remaining. Feb 13 at 4:16
• The effort appears to be roughly one person-day per story point, so the total estimated cost is 200 person-days. Feb 13 at 4:18

There's really no good way to do this.

The first problem is that story points and velocity are a relative measure that is highly sensitive to changes. Whether it's a team member taking a day off, learning something new about the work being done, process changes, permanent addition or removal of staff to the team, and other factors can all influence the team's velocity.

In this particular situation, the fact that people are not 100% available is a potential problem. Most Agile methodologies are built around a stable, long-lived team. Although people may take some time off from time to time, the expectation is that the people are fully dedicated to the effort. The idea of a stable team also leads to helping to compute the cost, since the paying customer funds the team for a number of iterations. Depending on the environment, they could even fund one iteration at a time, ending the effort once the cost of performing another iteration exceeds the maximum value that can be delivered or earned by maintaining the team and product.

In reality, though, it can be a desire to attempt to look ahead and get a rough idea of how long an effort will take and how much it will cost for the team to execute over that duration. It's important to realize that this type of forecasting is highly speculative since there are so many factors that can affect the performance of the team. In addition, doing work changes the work that must be done. Over time, the team may discover new work that is important as well as learning that some things they planned on doing are no longer necessary. The state of the backlog of work fluctuates frequently as stakeholders interact with working software.

If you're in a position where you still want to forecast, one good technique is the application of Yesterday's Weather. Yesterday's Weather is using the performance of the previous iteration to forecast the team's performance for the upcoming iteration. Although some people take the average of the past few iterations, others recommend only using the most recent iteration. For forecasting the next iteration, it is probably better to only use the most recent iteration, unless that one iteration is very atypical. For long-term forecasting, a rolling average of 3-5 iterations would probably be better to remove noise.

In this chart, I've added the ratio of story points to effort spent. If you have a stable team, this isn't necessary. However, if you have an unstable team and are putting in various amounts of effort, this may be a factor that you want to consider.

If the backlog started with 200 story points, you've completed 78 over 4 iterations. That means you have 122 story points left, assuming that you haven't added or removed anything from the backlog.

Over the course of the 4 iterations, you've had an average of about 20.75 people-days per iteration. You also complete about 0.94 points per person day. If you can project your capacity forward, you may be able to use this to figure out your range. It is probably best to compute a range using best-case and worst-case values, along with averages. Iteration 2 had the worst completion, with only 16 story points and 0.8 points per person-day. Iteration 3 was the best completion, with 24 story points and 1.04 points per person-day. It also seems like the historical data trends between 19 and 23 person-days.

Using this data, you can compute a number of possibilities. Maybe you trend closer to 19 person-days and 0.8 points per person-day, with an output of 15-16 story points, which would result in about 8 iterations left. Maybe you tend closer to 24 story points and 1.04 points per person-day, for about 24-25 points for about 5 iterations left. It could be somewhere closer to the average, with the team completing 18-19 points per iteration for 7 iterations left.

If you wanted to, you could get into more statistical analysis, but I'm not sure that kind of effort is needed in most cases. Just based on some quick, back-of-the-envelope calculations, I would present an estimate of about 5-8 iterations, with 7-8 being the most likely. Of course, this assumes no significant changes to the backlog of work, the team, and the team's way of working - any of these would likely have a measurable impact.

• Thank you so much.. It helped. Feb 15 at 4:05

## Based on assumptions and maths

Assuming that the team remains the same and its availability stays relatively constant, you could extrapolate the forecasted velocity to determine the cost as Robert explained in his comments:

• the average observed volatility is very near to the initial estimate:
• 20 story points per iteration make 200 / 20 = 10 iterations
• you can then extrapolate the costs, either by observing a workload per iteration or transforming the number of iterations in duration and look at the team cost per unit of time.

## But there’s a flaw: is it still agile?

You have an important hidden assumption: that the stories and the story points remain unchanged.

Agile welcomes changes and delay the details to the moment they are really needed. So existing stories might evolve, already estimated stories might be reestimated based on new knowledge, and new stories might be added. This means that your initial estimate will not stand to the end and your forecast cannot be accurate.

Velocity allows to plan at an acceptable level of confidence the near term future (3-4 iterations?). (Not to mention the consequences of bottlenecks if some specific skills are concentrated on a single team member, and the need for theses skills are un-evenly distributed across the iteration)

• Thank you so much for the clarification. it's clear ! Feb 15 at 4:06
• @ruchiverma Thank you for your feedback. If the answer is useful, don’t hesitate to upvote it. And if it answered the question you may select it Feb 15 at 19:13