How to estimate a project budget using story points?

Question

Current workflow in our company:

• I create Given/When/Then scenarios or User stories
• Developers estimate Scenarios/User stories in hours, by giving minimum and maximum amount of time for 1 scenario/feature
• Client approves/declines the budget
• I create a sprint backlog with the given estimate

I understand that relative sizing works better than hours sizing and that's why I would like to move to story points.But how is it possible to give a budget estimation for the client, using story points?

How to meet proper budget, but at the same time use story points for estimating the project?

Answer 1

TL;DR

For agile projects, a basic formula for estimating budget is:

(totalStoryPoints / velocity * teamHoursPerSprint) + nonLaborCosts = budgetEstimate

The results should be reported as an estimated range using statistical confidence intervals or a "high, low, average" method.

Estimate Budget Using Iterations

The "secret" to estimating agile budgets is to estimate the number of iterations needed to clear the backlog or reach a release milestone. For example:

1. Estimate your initial project backlog in story points.
2. Sum all the story points; that's your numerator.
3. Use the mean of your historical or guesstimated velocity as your denominator.
4. Divide your story points by your velocity to get the number of sprints you expect will be needed.
5. Multiply the number of sprints by 40 hours per week per team member to get your labor cost.
6. Add capital costs, equipment costs, maintenance costs, training costs, or other items that might be charged against the project.
7. Report the final total as a range with formal or informal confidence intervals.

This method gives a reasonable picture of the planned budget while still computing the Project Backlog in story points. This method doesn't rely on any awkward or misleading points ↔ hours conversions.

Basic Example Without Statistics

Assume you have 20 user stories in your backlog, and a Scrum Team of 6 people including the Scrum Master and Product Owner. Each story is estimated at 5 story points, and your historical average velocity is 10 story points per sprint.

1. Total story points in Product Backlog.

   20 stories @ 5 points each = 100 story points

2. Estimated iterations (a.k.a. "sprints").

   100 storyPoints / averageVelocity = 10 sprints

3. Average labor cost per two-week iteration.

   • labor cost per week for 6-person team: $3,200
   • labor cost per sprint for six-person team: $6,400
   • labor cost for project: $6,400 per sprint * 10 sprints = $64,000

4. Other non-labor costs (we'll call it $50k for this exercise).

   • Servers and workstations.
   • Software licenses.
   • Monthly service fees for the planned project duration.
   • Et cetera.

5. Estimated project total.

   $104,000

6. Reported budget range, without rigorous math and using sensible fudge factors.

   • Reasonable low end (80%): $104k * 0.80 = $83,200
   • Actual computed budget (100%): $104k * 1.00 = $104,000
   • Acceptable high end (120%): $104k * 1.20 = $124,800

In your project plan, you report your computed budget as the budget forecast (a.k.a. your planning value), the low end as your "stretch goal", and your high end as the point beyond which management will consider the project out of tolerance. This gives a reasonable picture of the planned costs while still computing the Project Backlog and delivery schedule from story points.

Answer 2

I will start by saying that doing Scrum in a consulting environment is a real challenge. With Scrum we are continually looking for feedback from the Product Owner and Stakeholders and adjust our backlog of work to reflect it. This makes it hard to give an up-front, fixed estimate. The aim of Scrum is to achieve the maximum business value by delivering what the customer needs. This is not always compatible with a fixed scope.

Having said that, it is possible to use story points to provide a project estimate. What you do is have the team do story point estimates on all the stories in scope for the project. Then you use the team's velocity to guess at how many sprints it will take to complete the project. Knowing the cost per sprint, you can then calculate the project cost.

Please be aware that it is unlikely you will get an accurate project cost estimate for all but the shortest of projects. In development there are technical and requirement unknowns that generate estimation errors that increase the longer the project you are estimating on. We call this the 'cone of uncertainty', where our certainty of the accuracy of an estimate decreases with project duration.

A Scrum team will often continually revise their estimate for a project. As each sprint is completed the team can recalculate their velocity and revise the backlog (and backlog estimates). With this approach their estimates get better over time, but this is of no use if you are forced to give an estimate before work has even started.

Answer 3

I have been using story points for many years and find them to be a far more effective estimation approach than using absolute time. That said you need to know their limitations. Just because a backlog exists does not mean a team and go through and with even moderate accuracy size it.

A team must have enough information about a story to relate it to something they have done on the past. Simply having a one line description of a story(As a Administrator of System X I need to be able...) normally does not provide a team enough information to size the story unless it is something very simple.

Backlog grooming and sizing is a continuous process where the team, product owner, stakeholders, etc. discuss the whats and hows of the story. Epics and stories are being split and/or spawning new stories while the sizes are being further refined. The point is attempting to come up with a project level estimate using by sizing all the stories up front is just thinly veiled Big Up Front Planning.

You are much better off looking at your project history and finding 2 or 3 projects that are similar in nature to give you a range of time and cost. Then determine if the value you are trying to achieve with the project is cost justified. You can further validate that decision by doing a limited implementation of some key pieces over a handful of sprints. That gives you real information to go off of versus speculation. Reliable information is not free. You don't get more reliable information by doing more detailed estimation. You get more reliable information by actually beginning implementation which of course costs money. You can continue with that approach and if at any point you determine it is no longer worth the remaining investment you kill the project. Too many businesses assume once a project starts it must be completed. Killing projects when they no longer provide the necessary value is a healthy thing and should be considered a win not a failure. Most businesses assume they can plan away the majority of the risk before they spend any of the investment. Guess what? That just isn't reality. It's like asking a stock broker to guarantee an ROI on a stock before you buy it.

I understand the quandary with the consulting world and it is a fundamental problem with the way most companies do business with vendors/consultants. Again, they want a guarantee on something that is extremely difficult to predict with both accuracy and precision yet you are forced to do it because it is the only way to get the business. It is dysfunctional because the company bidding out the business thinks they have limited their risk by forcing the bidder to lock in on price and scope. The reality is the risk has not truly been mitigated. The company winning the bid more often than not knows they have underbid it and will try to make it up along the way via a variety of different methods. The point is the project is set up for failure from the outset. Neither side normally wins in that situation.