Consider this scenario:

Backlog: 100 story points, project budget $100,000 (based on past team velocity/cost of delivering 1 SP per $1000 time spent). Stories are based on product development.

Week 1: Budget spent $10,000, 0 SP delivered Intensive UX design activities, refining the backlog, development setup

Week 2: Budget spent $10,000, 10 SP delivered Development starts, refining the backlog

Week 3: Budget spent $7,500, 10 SP delivered Development continues, refining the backlog

Week 4: Budget spent $12,500, 10 SP delivered Development continues, refining the backlog, intensive stakeholder workshop activities around later epics (approx. $5,000)

Cost to date is $40,000, we've delivered 30 story points. How do you forecast the cost to deliver the remaining 70 story points?

Applying a straight calculation: current project costs $1,333 per SP delivered so 70SP x $1,333 = $93,333 to go, meaning $133,333 total cost. But this doesn't account for the fact the UX design and workshops required early in the project have completed and the development team is delivering faster than anticipated.

Is there a common, recognised method to forecast remaining cost for Scrum development projects that accounts for surrounding design and analysis activities?

2 Answers 2


This is a tricky question to answer, usually the cost of a scrum team is sunk regardless of the value delivered at the end of each sprint. i.e. if the team were to achieve nothing then you'd still incur salary & overhead costs.

If you apportion costs over the sprint cycles and manage Story points separately it would make more sense.

Linking Costs to Story points would appear to be beyond Scrum.

But this doesn't account for the fact the UX design and workshops required early in the project have completed and the development team is delivering faster than anticipated.

Agreed. But then you have to account for implementation costs and post implementation support too, if the dev team is delivering faster then expected, this is great, it means you'll have more time to consider and prepare for putting your software live. Again this supports the view that Story Points should not be linked directly to Costs. The PO or Project Manager (if you have one) will have to constantly monitor the teams delivery to ensure that they have completed enough work to meet the definition of done in time for pre-implementation activities to be completed.

  • Thanks but it doesn't help me come up with a model for forecasting remaining project costs. If you abandon story points as a basis for remaining effort then how to you forecast remaining development effort?
    – Dave
    Aug 8, 2017 at 23:36
  • 1
    In Agile we tend not to forecast remaining project costs, The client usually has a set budget, if dev effort isn't fast enough then we have to drop some functionality. ... take a read of this ronjeffries.com/xprog/articles/the-noestimates-movement ... the #NoEstimates movement suggests that you really shouldn't be trying to do what your trying to do. (Not always possible, but worth trying)
    – Andy L
    Aug 9, 2017 at 10:41
  • 1
    Appreciate the comment and the link, as an agency that's going to be a challenge but we're trying!
    – Dave
    Aug 10, 2017 at 2:39

As with all estimates I think you should provide a range and some confidence numbers as well.

For example:

Using your previous formula of 1000$/sp your most probable remaining amount would be 70 000$. On top of that you can make the estimate that since at the moment you're delivering with the cost of 1333$/sp the current worst case scenario is 93 333$ to go. Then you can also provide a happy case scenario in which you will speed things up and in the future per sp cost drops to eg. 750$ and your remaining cost would be 52 500$.

Given these costs you could make an estimate that you have 60% confidence on hitting the 70 000$ and maybe 15% for both ends of the budget (with some percentage for very bad or very good scenarios). Here's a picture:

5%        15%       60%       15%      5%

<52k      52 500    70 000    93 000   >93k

Whenever estimating speed, velocity, costs, etc. in the future, using "yesterday's weather" is a pretty good starting point. And also when you're giving estimates on something you should always aim for giving a range along with some probabilities.

  • Hi, does the 60%, 15%, 5% have a basis in stats or they're just guesses? I'm really looking for a model I can apply without guessing. (Realising that we are dealing with probabilities)
    – Dave
    Aug 8, 2017 at 23:38
  • Well it's roughly a bell curve so yes, it has basis in stats. You could tweak the percentages to your suiting if you have some basis on those. For example you could drop the >93k because you have had a lot of design meetings and have solved key issues etc. but it should work as a base.
    – vvmann
    Aug 9, 2017 at 12:23
  • And taking into account the answer and comments in @Andy L:s answer this is a really lightweight model that you can use to satisfy the needs of external stakeholders while focusing on improving your Scrum implementation and making the organisation more agile. But be sure to emphasize that these are estimates and not promises and should be taken as a prediction and not as an actual truth of what's going to happen!
    – vvmann
    Aug 9, 2017 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.